Because Z Cash hides all the things, there’s no way to prune empty addresses, or really any addresses for that matter. Would it be feasible to, say every 2 years or something, have everyone reveal the contents of their addresses and then have the system clear out every address that wasn’t revealed?
Afterward all of the revealed funds could be added up and subtracted from the expected circulation and whatever is missing could be reintroduced via mining rewards.
That would clear out dust, no longer used funds (lost private keys), and empty addresses. Also has a nice side effect of funding mining to some extent.
It seems like the loss to privacy would be very marginal given a long enough cycle.
No it’s an invasion of privacy not to mention theft? What are you thinking?
It mildly reduces privacy, there would just be a bunch of unlinkable addressed with certain amounts of funds in them, and it’s not “theft”, just potentially a design decision. The goal isn’t to confiscate coins it’s to do something about the variety of useless information building up on the blockchain. Do you have a better idea?
There is potentially a conflict of interest with miners, so that portion could be axed. Funding mining wasn’t the objective anyway.
I could very well be going on an oversimplified understanding of blockchains here… But, with a publicly auditable blockchain, shouldn’t it be possible to bring balances forward (something I learned to do in ledger exercises from high school business studies)? For example, every year (or four) a new genesis block (regenesis?) could be composed of all the addressess containing a balance, from which new synchronisations would only have to look to the last block of the previous cycle to confirm the chain of hashes.
Although, how this might work (or if it’s even possible) on a blockchain that isn’t publicly auditable is beyond me… Also, and I’m not sure if this is what you were aiming for, but is this idea of pruning addresses anything like revocation certificates for PGP keys that should no longer be used / trusted?
I’m not sure if it’s really practical either.
At some point prior to the new cycle, there would need to be a transaction for each address that’s still in use to reveal, so if there were a million addresses, and you could fit something like 2000 transactions per block, that would take 500 blocks, or about 3 days and 11 hours to accomplish. So people would want to put in their transactions prior to 4 days before the cutoff block-depth.
Would it take another trusted set-up phase to get everything transaction with zero-knowledge again? I would think it could just use the same parameters, but I’m not sure on that.
It’s not really like PGP keys. It’s just about clearing out information that isn’t important anymore. Bitcoin can do a pruning process because all transactions are public.
This is something we’ve considered: the ticket is Design a windowed or rolling epoch system to limit the size of the commitment tree and nullifier set · Issue #829 · zcash/zcash · GitHub , although it has very little detail. Please note that we have many tickets for speculative design changes for which it is quite undecided whether or not, or when, to implement them. We’re definitely aware of the usability and economic drawbacks of having notes expire. The privacy consequences would depend on whether epoch/cycle-crossing JoinSplits are distinguishable (I have argued that they shouldn’t be, which is technically possible but has other disadvantages), and whether epochs use rolling or fixed windows.
1 Like