I had this weird antispam idea…
What if I know I won’t receive funds from these weird / large transactions?
Instead of changing protocol or miners, how about adding a filter to Lightwalletd.
Currently, the wallets get compact blocks using
GetBlockRange. I suggest we add a function
GetBlockRangeWithMaxCost which will filter out the transactions that would have cost more than a given fee (passed by the caller).
Blocks are trimmed out of all the output data except for the note commitments because of the need to maintain witnesses. That would eliminate trial decryption and the need to download epk and ciphertext.
We could also omit Orchard data if the client only supports Sapling.
It’s compatible with the old behavior, i.e. old wallets wouldn’t even notice the new API and it can be implemented without any change to
Of course it doesn’t solve anything related to the blockchain size but it should speed up synchronization by quite a lot.
Some variation of “I dont care about transactions with > N outputs” seems like a good short-term stopgap solution.
Spam filter cut down sync time of the latest 7 days by 50% (without modifications in lightwalletd).
Good stopgap solution.
Other blockchains (like Stellar) introduced “trustlines”; both parties have to first confirm they want to permit the transaction, and one-time establishment of the trustline costs the sender. The deficiency of Stellar’s trustlines was they didn’t have a flatrate fee for a wildcard of transactions sent from a specific address (analogous to buying a specific DNS domain vs. buying a wildcard domain…) -it got quite costly once you needed to push payments out from a specific address to multiple addresses. Like DNS, it should cost more for a wildcard trustline; but their thinking was to clip you each time you set one up for somebody to receive a transfer.
Perhaps a pruning setting in the node configuration parameters to control the thresholds of what gets retained…
Nodes have to keep everything because the data is encrypted and no one can tell what was spent.
So a pruned node on zcashd only worked for pre-NU5?
[If that’s the case, then yeah: a filter in the wallet…]
You can prune the raw block data but you can’t remove anything from the note commitment tree (roughly equivalent to the utxo db).