In the early days, Bitcoin was often touted as an inherently untraceable magic internet money. As time went on it became clear that due to transaction linkability, this was far from the case in practice. Identity can be inferred by looking at the ledger as a whole and deducing identities using known addresses. This technique has quickly evolved, giving way to a parade of new blockchain forensic companies eager to provide automated de-anonymization services to authorities and anyone else willing to pay for them. Those seeking to use Bitcoin privately, such as participants of darknet markets, have had to be especially careful not to expose anything that might link their identity to any public keys listed on those services. This makes privacy a luxury reserved for those willing to risk making a single identifying mistake.
To better understand how an identity could be determined, even if your wallet uses unique change addresses, this talk describes how de-anonymization works in detail:
Fungibility Requires Privacy
This vulnerability introduces another, more serious risk to Bitcoin itself. To preserve Bitcoin's fungibility, every coin must be indistinguishable from the next. If transactions are highly linkable, it means regulation could be introduced to restrict interactions with with "tainted" coins, damaging Bitcoin's fungibility. As a result, fungibility and privacy are strongly correlated and are crucial to ensure long lasting feasibility as a world currency.
As a weak measure aimed at mitigating this risk, we have discouraged the reuse of addresses to reduce linkability... but for many use-cases, that's not always possible. Many privacy coins have since come out, claiming to be the solution, often making many sacrifices in the process. The question is, do we need them? Or can Bitcoin Cash adopt privacy proposals that relegate these alt-coins to solutions without a problem?
While writing this I discovered that Bitcoin Cash has several unique advantages that make it ideal for many of the proposed solutions that have since been written off by Bitcoin Core developers. In this post I will go over several anonymity strengthening proposals, and clearly define many of their defining characteristics such as:
- Upgrade method
- Third Party Requirements
- Degree of Anonymity
- Ease of Wallet Upgrade
I also discuss proposals that are not anonymity solutions in themselves, but may help to make other techniques more useful by reducing their downsides.
Topics covered include:
- Stealth Addresses
- Cash Shuffle
- Payment Codes
- Deterministic Key Generation & Threshold Signatures
- Decentralized Exchanges / Atomic Swaps
- Zero Knowledge Proofs & ZK-SNARKs
- Extension Blocks
- SPV Anonymity
- P2P Network Anonymity: TOR, Dandelion, VPN
- Specific Client Implementation
Shouldn't We Be Focused on Scaling and 0-Conf Security?
"Whenever a system becomes completely defined, some damn fool discovers something which either abolishes the system or expands it beyond recognition."
While many in the community are currently focused on scalability, 0-conf security, and re-enabling opcodes, I thought it was a great time to start talking about one of our next major milestones in the evolution of a global cryptocurrency. In terms of priorities, Privacy is critical, even if only for its relationship to fungibility. Working now to understand the implications of the proposals in front of us may help move the ball forward, and secure Bitcoin Cash as the one coin to rule them all!
To the Shadows!
UPDATE: I've decided to make this post free since I think it's important to get a discussion going. Enjoy!
Note 1: For Brevity, I often say "Bitcoin" when talking about Bitcoin Cash. I will specify Bitcoin Segwit when it is required, otherwise, It's safe to assume I'm referring to Bitcoin Cash.
Note 2: While there is a LOT of information here please let me know if I'm leaving out any important details and I will happily update the article accordingly.
Note 3: The ratings on the below proposals are my best guesstimate. Being that many of these are still in the research phase, take them with a huge grain of salt.
Stealth (Reusable) Addresses
Anonymity: 2/5 Ease of Wallet Upgrade: 4/5 Protocol Change Required: No Trusted In Third Party Required: No Upgrade Method: External / No Fork Overhead: ~ 20% / 50 Bytes OP_RETURN data per Tx
The idea of Stealth Addresses have been around for a while, and were implemented in Dark Wallet by Amir Taaki, Cody Wilson and others in 2013. The name is a bit misleading as they don't do enough to change the underlying likability of transactions. They are relatively easy to implement and do provide some privacy advantages for the recipient. The key benefit is, you can publish a public address that will route funds to a new address every time without revealing the address to anyone but the payer and recipient.
It does this by asking the payer to generate a unique address in such a way that you (using some additional data which is attached to the transaction) can deduce the corresponding private key, and unlock the funds from the fresh new wallet address. While the sender can figure out where the coins went and track them when they leave, it does not leak information to onlookers about your incoming transactions to the public stealth address, or their balances.Since this technique requires a longer address that contains additional information, an early concern regarding stealth addresses was that, rolling out a new address type like was done with P2SH to facilitate support for this was logistically difficult.
Thanks to the extensibility of the new CashAddr format, a new address type can easily be created for supporting these addresses. Using this advantage, Chris Pacia made a great video showing how these might work with Bitcoin Cash. Since the receiver must scan the blockchain for valid Stealth Address data that gets stuffed into a Tx OP_RETURN, this technique has been known to exclude SPV wallets, or even requiring a 3rd party to do the scanning for you. Chris suggests he may have found a solution to the concerns surrounding stealth address balance discovery for SPV wallets by adding a flag to the bloom filter which can be used to reduce the address set that needs to be scanned. This would be a welcome discovery, removing one of the biggest concerns with employing this technique.
Since OP_RETURN was nerfed down to 40 bytes, Stealth Addresses were dead on arrival given they would at times require more than the allowed data as shown in Chris's demonstration.
Now with both BTC and Bitcoin Cash returning the OP_RETURN limit to 80 bytes, they are once again in play.
Anonymity: 4/5 Ease of Wallet Upgrade: 5/5 Protocol Change Required: No Third Party Server Required: Yes (for grouping participants) Trust In Third Party Required: No Overhead: Additional fees for each shuffled denomination, more records written to the blockchain, & Slower Tx Time Upgrade Method: External / No Fork
Cash shuffle is a protocol and server implementation that mix like amounts of BCH between participants. In the early Bitcoin days, CoinJoin was used to create coin mixing services to anonymize coins, but required the third party to facilitate the actual mixing of coins, leaving them vulnerable to theft by the service. Dash was one of the first to implement CoinJoin for their private send wallet function, using their masternodes in place of the 3rd party mixing service. In 2016, an improvement to the protocol called Coin Shuffle was introduced that did not require a 3rd party, reducing trust. When the BTC blocks became full and the fee market drove Tx prices higher, coin mixing services were forced to close their doors as the costs for doing many small transactions made the service prohibitively expensive.
Cash shuffle is a Coin Shuffle implementation for Bitcoin Cash which takes advantage of those nice big blocks that keep fees low. When it comes to trusting a 3rd party, it is only required to facilitate the grouping of participants, and a plugin has been released for Electron Cash. The server cannot identify you, and cannot steal your money like previous CoinJoin implementations since the Tx signing is all done on the client side. Many transaction fees will need to be paid to facilitate anonymization, but again this is a non-issue for Bitcoin Cash.Its worth noting that this method generally requires you premix your coins before transacting, as the shuffle process may take some time to group participants and shuffle the coins. Since it required no protocol changes, it is a practical way to introduce strong privacy without waiting for lower level privacy implementation to bear fruit.
Payment Codes - BIP47
Anonymity: 2/5 - 4/5 (depending on implementation) Ease of Wallet Upgrade: 3/5 Protocol Change Required: No Third Party Server Required: No (Except Samourai wallet) Upgrade Method: External / No Fork Overhead: A bit more than Stealth Addresses above
Payment Codes are similar to Stealth Addresses but involve a different set of trade-offs and features that may make them more practical for some use-cases. Payment Codes are completely non-interactive, meaning there is no need for any trusted third party servers. This technique was developed by Justus Ranvier in 2015 and were first implemented by Samurai Wallet (BTC only) which uses balance lookup servers. A few months ago, Stash Wallet was introduced on yours.org which has BIP47 implemented and supports Bitcoin Cash and Bitcoin Core. Stash is built on bitcoinj / bitcoincashj and is SPV based. It takes advantage of BIP32's deterministic addresses generated from a seed to avoid some of the OP_RETURN problems described in the Stealth Addresses section.
Observers will see typical Bitcoin transactions not knowing they all go to the same receiver, all while the receiver hasn’t published any of the addresses anywhere. The sender and receiver, however, can see their entire transaction history.
Update: Thanks to /u/ABlockInTheChain on reddit, we've learned of some new developments for Payment Codes. The Open Bitcoin Privacy Project is working on Version 3 of the protocol, which will effectively eliminate the one-time notification transaction overhead and will be fully compatible with mixing protocols, further enhancing privacy. Both Bitcoin Cash and Bitcoin Segwit are limited to only one OP_RETURN output, which has created a bottleneck for implementations of BIP47. Version 3 of Payment Codes will eliminate the use of OP_RETURN entirely, taking the bottleneck with it.
I would recommend checking out OBPP at the link above, they have a privacy report that rates the privacy of many of the common wallets on the market (from March of 2016 but still very interesting).
Deterministic Key Generation & Threshold Signatures
Anonymity: 3/5 Ease of Wallet Upgrade: 1/5 Protocol Change Required: No Third Party Server Required: No Upgrade Method: External / No Fork Overhead: ?
A major problem for crypto users has been the risk of getting Goxxed. When you transfer funds to an exchange, you entrust them with your p2p electronic cash. You transfer to a wallet whose private keys you do not control, and then you pray. This also has the side effect of disclosing your wallet balance with the exchange you transfer to.
"Imagine an exchange that doesn't know what you own".
Although details are hard to come by as these techniques have yet to be implemented in the wild, an explanation of how this might work was given in this talk by Jimmy Nguyen:
"Sorry Palantir, we're going to screw up your tracking."
All you see is a transfer, even the members don't know which members signed, unless you want them to. For more on this, we also have this talk by Craig Wright given at Bitkan’s “Shape the Future” Blockchain Global Summit – Tech Session in Hong Kong (September 21, 2017).
Decentralized Exchanges / Atomic Swaps
Another front in the movement toward end user privacy in the Bitcoin Cash world is the increasing popularity of decentralized exchanges. Soon, Bitcoin Cash will have the ability to have such a native decentralized exchange. Any time you use a regulated exchange, it must comply with privacy stripping KYM/AML laws. This introduces a huge point of de-anonymization. Working to create useful DEXs will be yet an important layer to help safeguard identity on Bitcoin Cash.
Andrew Stone also wrote a great piece on this on Medium.
Zero Knowledge Proofs
Anonymity: 5/5 Ease of Wallet Upgrade: 2/5 Protocol Change Required: Yes Third Party Server Required: No Upgrade Method: Hard Fork Overhead: Negligible
The "proof" part of Zero Knowledge Proof refers to the "Proof of Knowledge" required to verify possession of a private key. While zero knowledge proofs have a huge benefit in that they allow transactions to be encrypted on the blockchain, lead dev at Bitcoin ABC Amaury Séchet pointed out here on yours that there is a major security concern with integrating these proofs directly into the base layer. An attacker could potentially create more coins out of thin air, and nobody would even know about it. Everyone, even those who didn't use the feature, would see the value of their coins diminished. Even worse, a hypothetical attack could effectively wipe out the system's state for good. Such an event would be an unrecoverable disaster for the network.
ZK-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge)
ZK-SNARKs are a method for validating encrypted transactions that allow verification that a sender does indeed possess a private key, without revealing that key or requiring interaction between the prover and the verifier. This means that transaction data can be fully encrypted on the blockchain. The major downside associated with these is a trusted setup step, which may be improved upon with a newer technique called ZK-STARKs. These techniques pose great promise, but are still very much in the research stages of development, although ZK-SNARKs has been implemented by ZCash. ZK-SNARKs not only have great privacy implications, but also reduce the size of the proof data included in transactions and written to the blockchain making them desirable for scalability purposes too.
Anonymity: 5/5 Ease of Wallet Upgrade: 0/5 Protocol Change Required: Yes Third Party Server Required: No Upgrade Method: External / Requires Extension Blocks Overhead: Minimal. Largely positive since some data is removed from the chain, but range proofs make up the bulk of the overhead, making it much less than other low level solutions.
MimbleWimble is the name given to a hypothetical Bitcoin-like blockchain that was dead dropped by an anonymous entity on the dark web known only as Voldemort. Later, other wizards from the Harry Potter series would show up and contribute more to the proposal. MimbleWimble has some very exciting implications for both scaling and privacy since it allows much of the transaction data to be removed entirely from the blockchain, leaving only the block headers, the unspent outputs from each block, and some excess data containing combined signature information. MimbleWimble is what allows for Confidential Transactions since the data can be homomorphically encrypted on the blockchain. Since MimbleWimble removes Script data, it would impact Bitcoin's functionality dramatically, and will not be implemented directly in the base layer. This is why the goal, if Bitcoin Cash were to pursue this, would be to introduce MimbleWimble via Extension Blocks. A solid intro to MimbleWimble can be found on CryptoCompare, and it is further detailed in this video.
Anonymity: 0/5 (N/A) Ease of Wallet Upgrade: 2/5 Protocol Change Required: Yes Third Party Server Required: No Trust in Third Party Required: No Upgrade Method: Soft Fork Overhead: Minimal / Negative
Extension blocks are an "opt-in" proposal allowing for many exciting upgrades without compromising the integrity of the base layer. These would provide the network with several major features, including enabling Smart Contracts. The included transaction malleability fix would allow Lightening network support to be built on extension blocks without abusing the chain of digital signatures like Segregated Witness does on the BTC chain. When extension blocks were announced, it created a shit storm of controversy, and those are not my words. I wont bog this down with those details but lets just say Segwit supporters were not happy to have a competing solution to their master plan.
Extension Blocks work by consuming one of the unused OP_NOP# slots available for extending Bitcoin with something like OP_AUX. This new transaction type would create an auxiliary block for each canonical block that is mined. Since they are additional blocks that would be created within the same block interval, they have the effect of further increasing the block size. Extension blocks give us an upgrade path for implementing things like Zero Knowledge Proofs, MimbleWimble, or Rootstock in Bitcoin Cash. While this is not an anonymity proposal in itself, extension blocks offer a solution to the risks of implementing these lower level changes into base layer without introducing new systemic risk. Since the total amount included in an extension block is auditable, a problem like the coin creation exploit Amaury described would be more easily detectable, and would limit the risk to only the users of the extension block. Also, the wallet software changes required to implement this would be minimal (implementing the changes for the specific extension functionality is another story).
Extension blocks are one of the only proposals on this list to propose a change to the P2P Layer of Bitcoin (More on P2P anonymity below).
SPV wallets are fundamentally less private than full nodes. Typically, SPV wallets reveal which addresses they are interested in in order to reduce the data set they will process. Although Bloom Filters have been employed to improve privacy, According to G. Maxwell (yes I know, wrong crowd to quote GMax, but he did invent Coin Join after all), bloom filters used by BitcoinJ SPV were found to uniquely identify wallets in practice. This is one reason Stealth Addresses were dismissed as it was assumed they created additional privacy loss in SPV. The fact remains, SPV anonymity remains an important area for privacy innovation in the future.
P2P Network Anonymity
While all of these proposals address the transactional component of the Bitcoin machine, the P2P Network rarely sees much attention as it is considered the "least innovative" component of Bitcoin. P2P Networks have been around for a while, and the privacy problems with these networks are considered incurable by some. Bitcoin broadcasts and propagates transactions using a simple "flooding" algorithm sometimes called a gossip protocol. Like with Bittorent and other P2P networks, it is possible to identify a transaction's location based on it's IP address. While some solutions that have been floated to improve this, it is unclear at this point what if any of these can/will be used on the Bitcoin Cash network. In general, any anonymity introduced at this level is likely to impact propagation times making it a double edged sword. In a game of milliseconds, the multiple hops of a mesh network are less efficient than the complete network formed by Bitcoin Cash mining nodes. Since Bitcoin Cash is focusing on reducing these propagation times and improving 0-confirmation transactions, it may be less likely that these will be implemented.
On the other hand, one nice advantage Bitcoin Cash has in this arena is a side effect of larger blocks. When transactions are not immediately included in a block, they are periodically rebroadcast to the network providing more opportunity for anyone looking for these messages. Since BCH transactions are quickly included in blocks, this attack surface is reduced.
Dandelion is a proposal that seeks to conceal originating IP addresses of transactions by first broadcasting them only to a single peer. This is called the "stem" phase. Then, in the "fluff" phase, the traditional flooding method is used to propagate the transaction to other peers. While the originator of the fluff phase is more easily identified, the stem is harder to find making the transaction much more private at the cost of a transaction delay.
"The Onion Router" is a well known protocol which is used by the Lightening Network for obfuscating P2P network nodes behind several layers of encryption. Each hop in the network unwraps a layer of encryption exposing some of the routing information. With Onion Routing, each node can only see the immediate hop before and after it. The "exit nodes" are the weakest point in terms of deanonymization since they interface with the unencrypted world. While this may be a worthwhile supplement for anonymization of the P2P network, a recent paper published by Qatar University shows that if transaction linkability is not solved, interactions with TOR hidden services may be discoverable retroactively with the help of indexing services such as Ahima and others that will surely arise in the future.
A Virtual Private Network can help hide a Bitcoin client behind the VPN operator's public address. As always, a VPN can be used to improve the anonymity of a Bitcoin client but its impact is limited, especially as more countries introduce restrictions on operating such public services, and if authorities issue a subpoena, it's possible the Tx records can be determined retroactively.
One unerappreciated "privacy feature" is the intricate details surrounding how the client software is implemented. Just like with cryptography itself, flaws in implementation often pose the highest risk to solidifying intended behavior. For example, it is well known that a wallet who does not change receive addresses make it much easier to identify a user. Some wallets sacrificed this advantage intentionally when fees started to rise since it would cost their users money to use many addresses, especially upon consolidation. Thankfully Bitcoin Cash does not suffer this fate.There are many other nuances that makes a real difference for privacy, such as the specific level of promiscuity between nodes on the network, and when/how they decide to relay information. These specifics can either reinforce privacy and security, or undermine it. The fact that Bitcoin Cash has several development teams, and avoids a central reference client is an advantage in this area. In time, we may discover implementation methods that are exploitable in terms of privacy, as well as ways to avoid these pitfalls. Sharing those findings with others will help build a rock solid foundation for all implementations.
Securing true anonymity for users of public ledgers will be a major challenge for Bitcoin. Many of these solutions make great strides, but should be used together to effectively preserve privacy. Due to its large blocks, diverse community, and the removal of important restrictions like the 40 byte OP_RETURN cap, Bitcoin Cash is in a unique position to adopt the best of breed among these solutions to allow its users to enjoy real privacy on the network, strengthening its fungibility in the process.
14 of 14 reviewers say it's worth paying for
0 of 14 reviewers say it's not worth paying for