A Note About Unlinking Your YEC From Your ZEC

Last minute tips for increasing your security and privacy on both blockchains

Close-up of a chain link fence. Photo of by Feifei Peng on Unsplash

Introduction

After the Ycash/Zcash chain fork occurs very soon at block height 570,000, the private keys associated with your ZEC on the Zcash blockchain will also be associated with YEC on the Ycash blockchain. As a ZEC holder, if you choose to try to access your YEC, you may want to “unlink” your YEC and ZEC in certain ways for increased security and privacy.

(Before reading this post, you may want to read “A Zcash Holder’s Guide to Accessing Ycash.”)

Strategy #1: Move your ZEC to new addresses AFTER the fork.

Let’s say your ZEC is associated with a set of addresses that we’ll call Address Set M.

Steps for Strategy #1

1. Fork occurs at block height 570,000.
2. Wait 100 blocks, until block height 570,100.
3. Export the private keys associated with Address Set M
4. Transfer your ZEC to one or more new addresses, which we will call Address Set N.
5. Wait 100 blocks.
6. Import the private keys associated with Address Set M into your Ycash wallet.

By performing these steps, if your Ycash wallet is ever compromised, your ZEC in Address Set N is safe, because your Ycash wallet doesn’t have any private keys associated with Address Set N.

In order for this strategy to work, you must no longer receive ZEC to the addresses in Address Set M.

For a concrete example of how to implement this strategy, see this short Tweet stream from David Campbell (currently Chief Operating Officer of the Electric Coin Company) regarding best practices for accessing your YEC:

https://twitter.com/alchemyDC/status/1149766568907198464

Strategy #2: Move your ZEC to new addresses BEFORE the fork

As mentioned above, in order for Strategy #1 to work, you must no longer receive ZEC to the addresses in Address Set M. But what if this is not a viable option for you? For example, what if you’ve published a donation address that may continue to receive donations after the fork? Strategy #2 addresses this situation.

Strategy #2 is similar to Strategy #1, but instead of transferring your ZEC from Address Set M to Address Set N after the fork, you perform the transfer before the fork.

Steps for Strategy #2

1. Before block height 569,900 (100 blocks before the fork), transfer your ZEC in Address Set M to Address Set N.
2. Fork Occurs.
3. Wait 100 blocks, until block height 570,100.
4. Transfer your ZEC back to Address Set M.
5. Wait 100 blocks.
6. Export your ZEC private keys for Address Set N into YecWallet.

By performing these steps, if your Ycash wallet is ever compromised, your ZEC in Address Set M is safe, because your Ycash wallet doesn’t have any private keys associated with Address Set M. (Therefore, ZEC transferred subsequently to Address Set M will be safe in the event that your Ycash wallet is ever compromised.)

For this Strategy to work, you should retire Address Set N and refrain from ever sending ZEC to it.

The above two strategies result in your ZEC being associated with a different set of private keys than you YEC. Therefore, if one set private keys gets compromised one chain, the funds on the other chain are not affected. In this sense, your funds are no longer “linked” together across chains by a shared private keys.

However, if you are using transparent addresses in any way, these strategies do not address cross-chain tracing of transactions: Anyone looking at the blockchains will be able to trace how the funds moved, even across chains. In other words, even though your ZEC and YEC no longer share private keys, an observer can still trace the movement of your funds and correlate transactions on one chain with transactions on the other chain.

But what about purely shielded transactions? Can someone associate one of your shielded ZEC shielded transactions with one of your shielded YEC transactions. Interestingly, the answer is yes, but as explained below, Strategy #1 and Strategy #2 help break this link.

A Important Note For Zcash Shielded Pool Users Regarding Linked Nullifiers

In order to spend shielded ZEC, the spender must reveal a value called the “nullifer.” For more information on nullifiers, see the Electronic Coin Company’s fantastic tutorial entitled, “What are zk-SNARKs?”

Ordinarily, revealing this nullifier does not leak any privacy. The problem is that if you use the same private key to spend both ZEC and YEC, each transaction, even though they’re on different chains, reveal the same nullifier. Essentially, the shared nullifier leaks the information that the transaction on one chain was signed by the same private key as the transaction on the other chain.

Both Strategy #1 and Strategy #2 help shielded pool users avoid this problem. By sending the coins to your yourself on the Zcash blockchain, you essentially “burn” the nullifier on that chain.

Even if a user didn’t employ Strategy #1 or Strategy #2, the user can still address the shared nullifier issue by either sending all shielded ZEC to themselves or sending all shielded YEC to themselves. By doing this on either chain, the only correlation is to this self-churning transaction: Outsiders (even recipients of a shielded-spend) only notice that some of the same coins were active on both chains, with no ability to link amounts or destinations.

Furthermore, if you choose to self-churn shielded amounts on both chains, then any subsequent spends-to-others won’t even hint that funds-spent-to-them were ever active on the other chain.

We would like to thank @gojomo, @feministPLT, and @zooko for identifying and discussing the issue of shared nullifers. Any mistake in the discussion above should be attributed solely the Ycash Foundation. Comments and corrections are invited.