<p><strong>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.</strong></p>

<hr>

<p>We address this exact question in <a href="https://z.cash/blog/transaction-linkability.html" rel="nofollow noreferrer">this blog post</a> (images from which I reproduce below).</p>

<p>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 <code>prevout</code> field referencing the first one, like would happen with t-addresses).</p>

<p>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 <strong>different</strong> t-address, you end up with transaction chain (b) below:</p>

<p><a href="https://i.sstatic.net/xWkHP.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/xWkHP.png" alt="Shielded addresses can de-link transparent addresses"></a></p>

<p>This "breaks" the link between Alice's and Carol's t-addresses (for <strong>this</strong> 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 <a href="https://z.cash/blog/shielded-ecosystem.html" rel="nofollow noreferrer">this blog post</a> for related ecosystem discussion).</p>

<p>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 <strong>ZEC values</strong> 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 <strong>no change</strong>:</p>

<p><a href="https://i.sstatic.net/UFeNh.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/UFeNh.png" alt="A shielded address might not protect against value linkability in some cases"></a></p>

<p>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].</p>

<p>The solution to this is <strike>pretty simple</strike>: 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.</p>

<p><strong>EDIT:</strong> 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!</p>

<p>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.</p>

<p><sub>[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 <em>could</em> 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 <code>vpub_new</code> values for their unshielding transactions from the set of <code>vpub_old</code> values that have been seen on the block chain. Rounding the values is effectively a social consensus mechanism for achieving this.</sub></p>

CC BY-SA 3.0
2017-06-22T01:34:33.537Z
Wooohoo, welcome @str4d! :)
Murch
CC BY-SA 3.0
2017-06-22T00:18:20.967Z
2018-04-04T16:09:51.640Z
2018-04-04T16:09:51.640Z
str4d
<p>Is it possible to "break" the traceability of the blockchain by sending ZEC between z-addr and t-addr? </p>

CC BY-SA 3.0
2017-02-01T23:29:16.127Z
@renlord Questions about "a cryptocurrency or technology derived directly from Bitcoin such as Namecoin or Litecoin" or about "distributed cryptocurrencies not derived directly from Bitcoin such as Ripple, Ethereum or NXT" are explicitly on-top on this site. Source of the quotes: http://bitcoin.stackexchange.com/help/on-topic
UTF-8
CC BY-SA 3.0
2017-02-01T23:31:00.173Z
Ok. I'll rescind my close vote.
rny
<privacy><traceability><zcash>
Zcash t-addr + z-addr transactions
Kugusha
# Zcash t-addr + z-addr transactions

(Asked by: username_0 on 2017-01-29)

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

**Tags:** privacy, traceability, zcash

> **Comments:**
> **username_1**: @renlord Questions about "a cryptocurrency or technology derived directly from Bitcoin such as Namecoin or Litecoin" or about "distributed cryptocurrencies not derived directly from Bitcoin such as Ripple, Ethereum or NXT" are explicitly on-top on this site. Source of the quotes: http://bitcoin.stackexchange.com/help/on-topic  
> **username_2**: Ok. I'll rescind my close vote.  

---

## 1 answers

### Answer by username_3 on 2017-06-22. Score: 4

**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](https://z.cash/blog/transaction-linkability.html) (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:

[![Shielded addresses can de-link transparent addresses](https://i.sstatic.net/xWkHP.png)](https://i.sstatic.net/xWkHP.png)

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](https://z.cash/blog/shielded-ecosystem.html) 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**:

[![A shielded address might not protect against value linkability in some cases](https://i.sstatic.net/UFeNh.png)](https://i.sstatic.net/UFeNh.png)

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.

> **Comments:**
> **username_4**: Wooohoo, welcome @username_3! :)  

---

