Blog

In Part 1 of our series on making every spend a CoinJoin, “Why We Mix”, we walked through the philosophical and practical first steps behind the fight for privacy in Bitcoin. In Part 2 we’re digging into what information we share when we make a standard Bitcoin transaction, and what we want to (and can!) choose to protect to gain financial privacy. 

Each transaction we send in Bitcoin contains information on all inputs used, all outputs sent, and the time when the transaction is published to the mempool and included in a block. This ultimately breaks down into 4 key pieces of information; the sender, the recipient, the amount sent, and the source node.

Why does Bitcoin reveal so much information in each transaction?

When you sit down and think about the amount of information contained in a Bitcoin transaction, you may begin to wonder why in the world all of this has to be shared with the world each time you send a Bitcoin transaction. One of the tradeoffs that comes with making Bitcoin a decentralized and distributed ledger is that each transaction must contain enough information for (1) miners and nodes to validate that transactions don’t double spend funds, (2) users to be able to find their own funds without hassle, and (3) for the supply of Bitcoin to be easily validated by network participants.

While novel approaches to leveraging more powerful (but more complex!) forms of cryptography to hide sender, recipient(s), and amounts have been developed and proposed over the years, none of these approaches existed in the early days of Bitcoin, and each comes with its own set of tradeoffs and risks. Instead of implementing protocol changes like ring signatures, confidential amounts, or stealth addresses at the base layer, the Bitcoin community and developers have opted to keep Bitcoin’s base layer transparent by design and rely on higher layers and application-level privacy tools to allow users to opt-in to better privacy in Bitcoin.

Because of this choice, the ability for each of us to gain privacy becomes a matter of personal responsibility and knowledge instead of a protocol-enforced default. For better or worse, we each get to choose our own preferences and path towards financial privacy when it comes to Bitcoin.

An example transaction

As we walk through these four key pieces of information about each Bitcoin transaction, having an example transaction to refer back to will be invaluable. This transaction has been chosen at random from the Bitcoin ledger, but illustrates quite a few key aspects of a lack of privacy being inherent in Bitcoin.

What can we learn from a simple look into the transaction? Let’s break it down into key findings from using simple, widely available blockchain exploration tools like mempool.space and oxt.me:

• The sender consolidated multiple outputs to make the transaction, revealing all the inputs as almost certainly belonging to them
• Going back one hop with the largest input shows us that some of the funds were withdrawn from Bitstamp (but not all)
• The sent amount is almost certainly 0.011 BTC, as it is sent to a different type of address (“P2SH”, or wrapped/nested SegWit)
  • We can also confirm this analysis due to the rounded payment amount (0.011 BTC) which almost never happens with fees or change outputs
• The recipient is still using a legacy Bitcoin wallet and has not upgraded to use Segwit
• The change amount is almost certainly 0.00004088 BTC, as it is sent to the same type of address as the inputs (“P2WPKH”, or Segwit Bech32)

We’ll look more at these findings in each section below.

Protecting the sender

When we look at the different pieces of information revealed in a Bitcoin transaction, the information on funds being spent (and thus on the sender themselves) rightfully deserves the most focus when approaching transactional privacy. When you view any basic Bitcoin transaction in an explorer, you quickly realize that you can learn an immense amount of information about the sender by simply following the inputs backwards.

How do we see this play out in our example transaction? Let’s take a closer look:

• The sender consolidated multiple outputs to make the transaction, revealing all the inputs as almost certainly belonging to them
• Going back one hop with the largest input shows us that some of the funds were withdrawn from Bitstamp (but not all), tying multiple addresses together with funds connected to the sender’s identity known by Bitstamp

This simple analysis is primarily possible because in Bitcoin, almost all transactions are performed by a single entity; and if a single entity is performing a transaction, then all inputs to that transaction are necessarily owned by them. This heuristic is called the “common-input-ownership heuristic” and is one of the foundational building blocks for the majority of chain surveillance in Bitcoin today. When those wishing to surveil Bitcoin’s usage can safely assume that all inputs in a transaction are owned by the sender, they can build detailed and nearly complete pictures of a user’s spending habits past, present, and future.

This heuristic is also the core of what CoinJoin-style transactions attempt to confuse and break by coordinating a single transaction between many different participants. If enough Bitcoin users started to make CoinJoin transactions regularly, we could even go so far as to break this heuristic and make it inaccurate for chain surveillance companies, severely limiting their visibility into our financial activity on Bitcoin.

While hiding the input addresses and amounts is strictly not possible in Bitcoin today, we do have a few options for obfuscating and confusing chain surveillance, making their lives as difficult as possible.

What can we do today?

While we’ll keep things short and sweet in this section, here are a few ways you can better protect your financial privacy when sending Bitcoin transactions:

1. Always use a new receive address
   1. If your current Bitcoin wallet doesn’t do this automatically, it’s far past time to switch!
2. Don’t consolidate funds in your wallet (a commonly recommended way to save on fees down the line) by sending all of your Bitcoin back to yourself in a single transaction
3. Use as few inputs as possible (only one, if possible!) when sending a transaction
   1. Thankfully most good Bitcoin wallets will do this for you by default!
4. Prefer using PayJoin when enabled by a merchant (anyone using BTCPay Server can easily enable this if they’re using a hot wallet!)
   1. Read our guide on doing just that when buying a Passport: Buying Passport Privately Using CoinJoin
5. Use wallets like Samourai Wallet and Sparrow Wallet to CoinJoin your funds, ensuring that even when you spend funds the prior history of each input isn’t able to be traced
6. Use wallets like Samourai Wallet and Sparrow Wallet which automatically create dummy CoinJoin transactions whenever possible to obscure the sender (often called a “STONEWALL” transaction)
7. Use wallets like Samourai Wallet and Sparrow Wallet to create collaborative transactions that obfuscate the true sender and input (often called a “STONEWALLx2” transaction)

Protecting the amount sent

Protecting the sender is the core focus for many of the privacy tools built on Bitcoin, but protecting the amount sent in each transaction is also an important piece of a holistic approach to privacy on-chain. If we’re not careful about how amounts are handled, we can make it easier to undo our privacy and link transactions and addresses to each other. The most common ways to use amounts to reveal information in a transaction are to look for rounded payment amounts (i.e., 0.001 BTC exactly) or to look for exactly matching amounts (minus normal fees) going into and out of exchanges, instant exchangers, or decentralized exchanges.

How do we see this play out in our example transaction? Let’s take a closer look:

• The sent amount is almost certainly 0.011 BTC, as it is sent to a different type of address (“P2SH”, or legacy SegWit)
  • We can also confirm this analysis due to the rounded payment amount (0.011 BTC) which almost never happens with fees or change outputs
• The change amount is almost certainly 0.00004088 BTC, as it is sent to the same type of address as the inputs (“P2WPKH”, or Segwit Bech32)

Amount-based heuristics are a common tool used by chain surveillance companies to confirm other heuristics (like the “common-input-ownership heuristic” we’ve already discussed) or to make educated guesses in the absence of clearer signs on-chain. The ability to use amounts to tie transactions and inputs together is one of the main reasons that most of the most battle-tested CoinJoin protocols use common denominations for inputs (i.e., 0.05 BTC) instead of allowing arbitrary amounts. Using these common denominations prevents trivial linkage of inputs and outputs down the line.

What can we do today?

1. Avoid using rounded amounts (i.e,. 0.01 BTC) when sending funds unless necessary
2. Avoid using specific fee amounts (outside of 1sat/vbyte, of course) and allow your wallet to calculate fees appropriately
3. Prefer using PayJoin when enabled by a merchant (anyone using BTCPay Server can easily enable this if they’re using a hot wallet!)
4. Use wallets like Samourai Wallet and Sparrow Wallet and create a “STOWAWAY” transaction with other Samourai and Sparrow users to hide the amount being sent and true input

Protecting the recipient

Now that we’ve taken a look at protecting both the sender and amount in a transaction, how do we go about protecting the recipient’s privacy? Thankfully, many of the same principles apply here as well, especially avoiding address re-use. As every transaction in Bitcoin necessarily has a recipient with address and amount being visible on-chain, it can be quite difficult to actually preserve the privacy of the recipient, both from the sender and from outside observers.

How do we see this play out in our example transaction? Let’s take a closer look:

• The sent amount is almost certainly 0.011 BTC, as it is sent to a different type of address (“P2SH”, or legacy SegWit)
  • We can also confirm this analysis due to the rounded payment amount (0.011 BTC) which almost never happens with fees or change outputs
• The recipient is still using a legacy Bitcoin wallet and has not upgraded to use Segwit
• The recipient sweeps this output along with many others in a later transaction, linking their other receive history together

Chain surveillance companies leverage many of the same techniques to identify recipients as they do with senders, including wallet fingerprinting by fees, script types, output consolidation, and address re-use. When these types of heuristics are used, it can lead to “wallet clustering”, where those performing surveillance can tie together transactions under a single entity, even if there is no direct identification attached. As always with privacy, it’s important to blend in with the crowd and avoid any mistakes that can make it easier to separate and cluster transactions under a single entity.

What can we do today?

1. Avoid re-using addresses when receiving funds
2. If you’re the sender and a recipient is re-using an address or has a static Bitcoin address posted for donations or payments, pressure them to either use a PayNym or a solution like SatSale or BTCPay Server to provide a new address with every payment
3. Prefer using PayJoin when enabled by a merchant (anyone using BTCPay Server can enable this, if it’s not enabled ask your merchant to enable it!)
   • Read our guide on doing just that when buying a Passport: Buying Passport Privately Using CoinJoin
4. Use wallets like Samourai Wallet and Sparrow Wallet to create collaborative transactions that obfuscate the true sender, receiver and input (often called a “STONEWALLx2” transaction)
5. Use wallets like Samourai Wallet and Sparrow Wallet and create a “STOWAWAY” transaction with other Samourai and Sparrow users to hide the amount being sent and true received output

Protecting the source node

Last but not least comes an aspect of Bitcoin privacy that is often forgotten – protecting the IP address of the Bitcoin node that broadcasts the transaction in question. While the IP address and information about the originating node isn’t stored on the blockchain directly, it can be relatively easily seen by anyone operating a few nodes on the network and desiring to gather that type of information.

Because Bitcoin Core uses a very simplistic transaction broadcast protocol, an adversary seeking to surveil the network can run many nodes in many different geographic locations to try and be at least one connection of most nodes in the network. Once they have these broadly distributed nodes (a “Sybil attack”, something that is very cheap and easy to do in a permissionless and decentralized network like Bitcoin), they can then watch for where in the network they see transactions first broadcast. If they notice that a transaction they’re interested in was first broadcast from one node and propagated from there, they can make a very well educated guess that it was the source node for the transaction.

While this doesn’t guarantee that their guess is correct, it does help them narrow down the potential source node of a transaction and more actively Sybil attack that specific node to look for further transactions of interest. This can be combined with on-chain heuristics to try and find the source node being used by a specific entity and gain vast insight into their spending habits, their geographic location, and even their home address (if they reveal their true IP address to the Bitcoin network).

It’s important to remember that a peer-to-peer network like that used in Bitcoin is designed to be censorship-resistant and permissionless, not private. This approach works extremely well at ensuring that in most censorship scenarios a transaction can still be broadcast to the whole network, but also ensures that a motivated adversary can quite easily follow the flow of transaction propagation and block propagation across the network.

If you’d like to learn more about the issues inherent in this approach, there is an excellent article on the topic titled “Bitcoin’s P2P Network” at nakamoto.com.

What can we do today?

1. If you run your own Bitcoin node, set it to only use the Tor network for communication
   1. This option is controlled by `onlynet=onion` in the config file, read more on the topic here
2. Broadcast transactions manually via the Tor Browser and a service like mempool.space
   1. Only do this over Tor, never via clearnet!
   2. The current Onion address of the mempool.space broadcast tool is here
3. Run your own Samourai Wallet “Dojo” node stack, which is Tor-only by default

Conclusion

After reading this I hope you come away with the conclusion that while Bitcoin’s on-chain privacy is imperfect by default, there are solutions available to each of these problems today. It may seem daunting to have to consider each of these aspects of information when sending or receiving a Bitcoin transaction, but as the issues around privacy within Bitcoin are clarified and made known, the wallets and apps we use to interact with Bitcoin can grow to better handle all of these potential issues for a user automatically.

Over the long-term it’s extremely important that wallet developers and node developers work hard to build in sane and private defaults to their apps, as most users have neither the knowledge nor expertise to properly handle every core piece of Bitcoin privacy. The more we as developers can improve users’ privacy without them even thinking actively about it, the better off our users will be and the better off the Bitcoin network and ecosystem will be.

In part 3 of this series we’ll take a closer look at protecting the sender via CoinJoin, including a sneak peak at what we’re working on to help make Bitcoin privacy more approachable for every Bitcoin user.

Stay tuned, and thanks for diving into the deep end of Bitcoin privacy with us today!