Skip to content

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

@gojomo

Description

@gojomo

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions