Zcash is a cryptocurrency which provides a mechanism to obscure the source, destination, and amounts of transactions. These transactions are known as shielded transactions. The privacy of shielded transactions is achieved by using zk-SNARKs, which are a type of zero-knowledge proof [BSCG14].
The use of shielded transactions is optional. As with Bitcoin, Zcash coins are sent to addresses, which can be thought of as public keys. Only the owner of the corresponding private key can generate a new transaction to transfer the coins. In Zcash there are two classes of addresses: transparent and shielded. When a transaction occurs between transparent addresses the transfer is akin to Bitcoin transactions, where the parties involved and the amounts are fully visible. Only when a transaction occurs between two shielded addresses are Zcash’s privacy guarantees in full effect.
Generating shielded transactions comes at a significant computational cost, taking between thirty seconds and one minute to create on a modern desktop computer. Perhaps because of this, most Zcash transactions do not involve shielded addresses. In Section III we quantify this, finding that only about 3.5% of all Zcash coins are controlled by shielded addresses on average.
Many transactions involving shielded addresses exhibit a particular pattern: first, coins are sent from a transparent address to a shielded address. Soon after, an identical or nearly identical amount of coins are sent back to a transparent address. We call such transactions round-trip transactions and argue that the controlling party is likely the same for both transactions. In Section IV, we show that 31.5%111All statistics in this paper were calculated on the Zcash blockchain ending in block 196304, which was mined on October 4, 2017 of all coins sent to shielded addresses are likely involved in a round-trip transaction, potentially removing their unlinkability. Lastly, we discuss these results in Section V.
Zcash retains nearly all of the original Bitcoin functionality. Transactions between transparent addresses (also known as t-addrs) are essentially equivalent in form to Bitcoin transactions. In Bitcoin, coins are transferred by referencing the outputs of previous transactions and providing a digital signature that proves ownership of the address the coins were sent to. Since coins are only created as part of the block reward for miners, it is straightforward to audit the correctness of every transaction: simply trace back each transaction output, verifying digital signatures along way back to a block reward.
However, the radical simplicity of Bitcoin’s transparent ledger has significant privacy drawbacks. If an address is ever associated with a real-world identity it becomes trivial to trace the source and destination of all the user’s coins. This loss of privacy can be mitigated by never re-using the same address, although even the original Bitcoin whitepaper notes that linking will remain unavoidable [Nak09]. Several studies of the anonymitity of Bitcoin have been undertaken, showing that analysis can overcome even a dedicated effort at obfuscation [RH11, MPJ13]. Thus, when transferring between two t-addrs in Zcash, the transaction is fully linkable.
Unlike Bitcoin, Zcash uses a second type of address known as shielded addresses (also known as z-addrs). Transactions involving z-addrs are carried out in the JoinSplit structure, which is a new structure added to the Bitcoin transaction format. A JoinSplit contains three essential fields: the number of coins entering the shielded pool (known as vpub_old), the number of coins exiting the shielded pool (known as vpub_new), and a field holding a zero-knowledge proof attesting to the legitimacy of the transaction.
There are three different operations that a JoinSplit may perform (see Figure 1). The first is a shielding transaction, where coins are sent from a t-addr to a z-addr. This corresponds with a non-zero vpub_old. Thus, in shielding transactions the amount being sent to a z-addr is public, but the z-addr itself is not. The second operation is a de-shielding transaction, where coins are sent from a z-addr to a t-addr. This corresponds with a non-zero vpub_new. Likewise, the z-addr remains private but the amount is public. The final operation is a shielded transaction, where coins are transferred between two z-addrs. For shielded transactions both addresses are private, as well as the amounts.
Iii Shielded Transactions
The anonymity of z-addrs is the fundamental differentiator between Zcash and Bitcoin. We examine several metrics of this anonymity as it pertains to real-world usage of Zcash.
Iii-a Transaction metrics
Overall, 19.6% (259,220) of all Zcash transactions contained a JoinSplit operation, with 40.2% of blocks containing no transactions with JoinSplits (see Figure 2). Thus, 80.4% of all Zcash transactions are trivially linkable back at least one transaction.
Of the 19.6% of transactions that do contain a JoinSplit, we further classified the transactions into the types of JoinSplit operations being performed. Every JoinSplit may contain an unknown number of shielded transactions, so there is no way to place an upper bound on the number of shielded transactions. However, only 1.9% (5,450) of all JoinSplits have no shielding or deshielding portion, while 40.6% (116,743) of JoinSplits included a shielding operation and 57.5% (165,394) included a deshielding operation222No JoinSplit included both a shielding and a deshielding operation. It is unclear if the Zcash software allows this. This evidence supports our eventual hypothesis that most coins sent to z-addrs are sent back to t-addrs.
Iii-B Coin metrics
We also investigated the participation of coins in shielded transactions. As with Bitcoin and other cryptocurrencies, transactions are grouped into blocks, and miners must solve a difficult proof-of-work problem on the block and announce it to the network. Valid blocks reward the miner with a certain number of coins in what is known as the block reward. Thus, with each block the available supply grows slightly, until some fixed33321 million for Bitcoin and Zcash cap.
In Zcash, coins exist either in the transparent pool, where they are controlled by a t-addr, or the shielded pool, controlled by a z-addr. To determine the size of the shielded pool, the difference between vpub_old and vpub_new of each JoinSplit is calculated. This is the net differential into the shielded pool. The total pool size is kept as a running sum of the differential for each block. Our results (see Figure 3) show that the shielded pool only ever contains a relatively small percentage of the overall supply of Zcash coins444For coin totals, only the whole number portion of coins are reported. For the final block cataloged, the percentage of coins in the shielded pool was 4.3%. The average percentage per block was 3.5%.
Taken together, the previous results suggest an environment where transactions using z-addrs are infrequently used. In an environment where shielded transactions (i.e. z-addr to z-addr and fully private) are commonplace, it is reasonable to assume that many to most JoinSplits would contain no shielding or deshielding operation. However, out of the 287,587 JoinSplits cataloged, only 5,450 met these conditions. Furthermore, only a relatively small percentage of coins are ever present in the shielded pool. Together, these two conditions lead us to hypothesize that when coins are introduced to the shielded pool, they are soon returned back to the transparent pool.
Why are z-addr transactions so rare? We suggest that the reason is likely practical: most wallet programs do not support z-addrs. According to the Zcash community website555https://www.zcashcommunity.com/wallets/ accessed on November 1, 2017 no web-based wallets support z-addrs. In addition, all cryptocurrency exchanges that trade Zcash only accept t-addrs. For users that wish to take advantage of the privacy features afforded by z-addrs while still maintaining the practical utility of t-addrs, a simple solution would be to send coins to a z-addr, and then send them back to a t-addr. This would have the effect of removing the linkability of the transactions. However, because the amounts of the shielding and deshielding operations are public, these types of transactions may still be linkable.
Iv Round-trip Transactions
In this section we use the public amount of shielding and deshielding operations to build a candidate set of linkable transactions that pass through the shielded pool. The official Zcash website notes666https://z.cash/blog/transaction-linkability.html accessed on November 2, 2017 that such analysis is possible. However, we believe this study is the first to perform the analysis and show the prevalence of such transactions.
Let and be JoinSplits included in blocks of height and with . If there exists exactly one pair of transactions with , , and , then we say is a round-trip transaction (RTT).
RTTs are an ordered pair of transactions containing JoinSplits where the shielding amount in the first transaction is equal to the deshielding amount in the second transaction. In addition, the second transaction must appear in a later block than the first transaction. Lastly, we are only concerned about those pairs where there is exactly one pair that fits the criteria, e.g. ifshields coins, we are looking if there is exactly one JoinSplit in any later block that deshields coins.
We note that although there is strong circumstantial evidence that and in a RTT are linked, the conclusion is not definitive. Not all RTTs identified by our heuristic are actually linked; the match may be coincidental.
To detect RTTs, we first modified an existing Bitcoin blockchain parser to support Zcash. We then used this to build a relational database of the blockchain, linking blocks, transactions, and JoinSplits. Figure 4 gives the pseudocode for a query to find JoinSplits that meet the criteria for RTTs.
Our analysis found 10,075 transaction pairs that met our criteria (see Figure 5), transferring a total of 919,220 coins. The total number of all coins entering the shielded pool was 2,911,734. Thus, we determined that 31.5% of all coins entering the shielded pool were involved in a RTT.
We could not conclusively determine that all RTTs are linked transactions. However, there is strong circumstantial evidence that the false positive rate of our heuristic is low, and that most of the transactions are indeed linked. 96% (9673) of our matches involved transactions which appeared within two hours of each other on the blockchain. In addition, by the definition of RTTs, the amounts being shielded and unshielded are globally unique amongst the entire history of Zcash. Given the high divisibility777A Zcash coin can be divided out to 8 decimal places of Zcash coins, we believe that a single exact match of the shielding and deshielding amounts occurring within a few hours is strong evidence that the transactions are linked.
|block time||# RTT||coins|
|Top JoinSplits||# RTT||coins|
Large denomination transfers were particularly likely to be RTTs (see Figure 6). Of top 250 JoinSplits by shielding amount, 236 were part of a RTT. Upon further investigation888The t-addrs of Zcash miners are known it was discovered that many of these large JoinSplits were Zcash mining pools sending their block rewards to a z-addr before distributing the coins to the t-addrs of miners. In this case, miners may be under the impression that source of their coins is private since they are receiving their payout from the pool via a z-addr. However, because the pool is engaging in RTTs, we were able to determine the t-addrs of the pool’s members.
Iv-D Fee-adjusted RTTs
When creating a Zcash transaction, the sender may choose to offer a small amount of Zcash as an incentive for miners to include the transaction in a block. This is known as a fee. Although fees are not required, 98.6% of all non-coinbase999The first transaction in a block is the coinbase transaction, which specifies the receiver of the block reward. Coinbase transactions do not have fees Zcash transactions include a fee. Figure 7 shows the most common fees. The fee used most frequently was 0.0001 Zcash, which 46.4% of transactions used.
For RTTs, . However, if the party performs any shielded transactions (z-addr to z-addr) before transferring back to the transparent pool, the vpub fields may not match, since the shielded transactions may have also paid fees. We relax our definition of an RTT to where is some combination of common fees. We call such transactions fee-adjusted round trip transactions.
For fee-adjusted RTTs we considered only transactions appearing within 24 hours of each other. In addition, to limit false positives only the five most common fees were used. We first searched for 1-fee RTTs, which attempts to detect the following pattern: t-addr z-addr z-addr t-addr.
Figure 8 gives the results for -fee RTTs. A total of 388 such transaction pairs were found, accounting for a total of 6,058 coins. Given the apparent scarcity101010Recall that only 1.9% (5,450) JoinSplits have no shielding or deshielding operation of shielded transactions, it is unsurprising that relatively few were found.
We also searched for 2-fee RTTs, attempting to detect the following: t-addr z-addr z-addr z-addr t-addr. We considered combinations of the five most common fees, except for those which summed to a common fee (e.g. ). A total of 485 transaction pairs were found, accounting for a total of 4,411 coins.
V Discussion and Conclusion
Bitcoin’s transparent ledger allows the source and destination of coins to be traced by any third party. To prevent this linking, Zcash employs shielded transactions to obscure these details. However, only transfers between two z-addrs are truly private. Empirical evidence suggests that most usage of z-addrs involves shielding or deshielding operations, where the amount transferred is still public. We have shown that a third party can use this information to link entries and exits from the shielded pool. In our experiments we were able to identify 31.5% of all shielded pool coins as likely being involved in round-trip transactions.
When privacy features are optional, users often take the path of least resistance. Given the large computational costs of shielded transactions, they are relatively rare. Round-trip transactions may be an effort to “have the best of both worlds”, but if used incorrectly they do not deter a determined attacker from linking transactions. To be entirely sure that the source of coins cannot be traced, a user must perform a second, fully shielded transaction after receiving coins in a shielding operation. If they wish to return the coins to the transparent pool, they must also take care to leave some portion remaining in the shielded pool to avoid performing a RTT.
Lastly, we highlight a real-world case where RTTs can lead to a serious privacy loss. Many of the coins involved in RTTs come from mining pools distributing the block reward proportionally to users based on their contribution to the pool. Several of the popular Zcash pools perform an RTT before actually distributing the reward. It may be that the pool’s members do not wish for it to be known that they are engaged in mining. By virtue of receiving coins from a z-addr, they may believe that the source is obscured. However, by identifying RTTs, the true source of their coins is revealed, which may have serious repercussions.
Eli Ben-Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and Madars Virza. Zerocash: Decentralized Anonymous Payments from Bitcoin. Proceedings of the IEEE Symposium on Security and Privacy, pages 459-474, 2014.
Sarah Meiklejohn, Marjori Pomarole, Grant Jordan, Kirill Levchenko, Damon McCoy, Geoffrey Voelker, and Stefan Savage. A fistful of bitcoins: characterizing payments among men with no names. Proceedings of the 2013 conference on Internet measurement conference (IMC ’13), pages 127-140, 2013.
Satoshi Nakamoto. Bitcoin: a peer-to-peer electronic cash system, 2009. URL: http://www.bitcoin.org/bitcoin.pdf
Fergal Reid and Martin Harrigan. An analysis of anonymity in the Bitcoin system. 2011 IEEE Third International Conference on Privacy, Security, Risk and Trust and 2011 IEEE Third International Conference on Social Computing, pages 1318-1326, 2011.