Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Minimize cross-chain nullifier-related privacy leaks with self-churn and zero-fee self-churns #11

gojomo opened this issue Jun 18, 2019 · 3 comments


Copy link

commented Jun 18, 2019

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.


This comment has been minimized.

Copy link

commented Jun 19, 2019

Thank you so much @gojomo. I've been monitoring your comments on Zcash #4007. At a minimum, we'll provide a warning to users on our website about this nullifier issue and provide instructions for how to self-churn.

We are going to consider implementing some of the ideas that you've suggested, but not until after the fork (given how close we are to the fork date).

I really like your idea of combining a self-churn with a local wipe of the pre-churn key. I think that would be a useful tool to have.

I appreciate you taking the time to think through these issues and offer solutions.


This comment has been minimized.

Copy link

commented Aug 15, 2019

Nullifier migration tool will be in ycash 2.0.6


This comment has been minimized.

Copy link

commented Aug 23, 2019

Tool available in 2.0.6

@denverbdr denverbdr closed this Aug 23, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.