-
Notifications
You must be signed in to change notification settings - Fork 11
Description
As mentioned in Zcash #4007, shielded spends on a chain-fork like Ycash will reveal the same nullifiers as on the 'parent' chain, causing a small privacy leak above-and-beyond what might also be revealed by things like correlated-amounts.
For example, consider a user who on Ycash sends some ZEC-that-became-Y-at-the-fork, via the Ycash chain, to one exchange, revealing a pre-fork nullifier. Later, that same user sends some of that pre-fork ZEC to another exchange or merchant. An observer who sees both of those receipts – perhaps because the receivers are both subject to security compromises, or legal demands, or are related-entities – will then know both spends came from the same keyholder.
A partial amelioration is suggested in a comment by Zooko: if on one or the other chain the user self-churns the funds, sort-of a same-pool funds-migration, then the 1st time the funds are sent to an outside party, nullifiers won't reveal any cross-chain correlation except that they were moved on both chains.
However, users might need to be reminded to do this, and the extra transaction fees involved could discourage the step. The Ycash client & consensus/miner rules could help, by: (1) offering an in-client 'churn' option, to break all nullifier-relationships with the 'parent' chain – and perhaps even prompting to run this at or soon after 1st launch; (2) waiving transaction-fees for all-shielded transactions that consume only pre-fork nullifiers. (And, it's much easier for Ycash to offer this than the parent chain, as the fork is already necessarily a consensus-change and self-aware of the relevant fork-height before which shared-nullifiers are problematic.)
While not necessary for the nullifier issue, the self-churn might even offer the option of moving funds to a new private key, and wipe all local record of the pre-churn key, to further minimize the risk of shared-keymatter ever leading to a future loss-of-funds on both chains.