Zcash t-addr + z-addr transactions

Question

Is it possible to "break" the traceability of the blockchain by sending ZEC between z-addr and t-addr?

Answer 1

tl;dr You should use rounded values of ZEC when unshielding, and even then you will have less privacy than if you only use z-addrs.

---

We address this exact question in this blog post (images from which I reproduce below).

Transactions using the Bitcoin-inherited t-addresses are obviously traceable. However, the zero-knowledge property associated with the use of z-addresses means that when you send ZEC to a z-address (creating a "note", the private equivalent of a TXO), and then use that note in a subsequent transaction, the two transactions are not directly linked on the block chain (that is, the second transaction does not contain a prevout field referencing the first one, like would happen with t-addresses).

This means that if you send ZEC from a t-address to a z-address (a "shielding" transaction) and then from the z-address to a different t-address, you end up with transaction chain (b) below:

This "breaks" the link between Alice's and Carol's t-addresses (for this transaction; other transparent payments could still link those addresses, so the same care should be taken as with Bitcoin). Considered more widely, you can imagine "islands" of t-address activity, separated from each other by murky z-address transaction "seas" (see this blog post for related ecosystem discussion).

Now for the caveat! The z-address hides all details (recipients, values, and memo fields) of the output notes in the shielding transaction, and the corresponding properties of the input notes in the unshielding transaction. But the ZEC values are still public, because they are visible in the transparent halves of the transactions! This means you can run into problems when you send the full balance of a t-address with no change:

The full value is visible in the first transaction, and then later a second transaction appears with an output value equal to the original input value minus two transaction fees. Timing data is also available (because the transactions are inherently ordered and timestamped in the block chain), meaning that it can be possible to statistically link the two transactions based on those values alone [0].

The solution to this is pretty simple: use "rounded" amounts when unshielding (with the change going back to the z-address). That way, there is no value link between the shielding and unshielding transactions.

EDIT: Note that the particular rounding strategy you use can itself leak information! For example, if you always round down to the nearest whole ZEC, and someone else always rounds down to the nearest 10 ZEC, then over time, your unshielding transactions will look markedly different to theirs, and someone who is looking for patterns in the block chain can start separating your unshielding transactions from the rest. In general, the larger and more standard the buckets you use are, the less information is leaked; additionally, you want everyone else to be using the same buckets as you too!

The upshot is, if you want to minimize the amount of information you leak, the simplest way to do so is to minimize your usage of t-addrs.

_{[0] It's a little more complex that this. The shielded part of an unshielding transaction still has the same two output notes as any other shielded transaction part (they just contain dummy notes for a z->t transaction), and those parts could be filled (ie. using a z-address to pay both z-addresses and t-addresses). So while matching values is a strong link, it is not a definitive link, and in fact can be intentionally subverted by wallets choosing vpub_new values for their unshielding transactions from the set of vpub_old values that have been seen on the block chain. Rounding the values is effectively a social consensus mechanism for achieving this.}