On May 15th 2023 we launched Surge Cycles on the Whirlpool coinjoin coordinator.

Background: Whirlpool Transaction Size and Miner Fees

To date all Whirlpool coinjoin transactions have been composed of 5 inputs and 5 outputs

To pay for this transaction to be mined into a block we need to consider the size of the transaction, and the current miner fee rate. Using both we can determine the total amount of miner fees which are required to be paid for this transaction to get confirmed in a timely manner.

The size of a transaction, in terms of how much data it takes up on the blockchain, is determined by the type and number of inputs/outputs. The size of a 5-input/5-output Whirlpool coinjoin transaction is 510 virtual bytes (vB).

Observing on-chain, if for example the fee rate for a transaction to be mined into the next block is 20 satoshis per virtual byte (sats/vB), we would have to pay 10,200 sats (510 x 20) for a 5-input/5-output coinjoin transaction to be confirmed in a timely manner.

User Selection of Miner Fee Rate

When a user proceeds to Whirlpool their coins, they are prompted to select a cycle priority of low, normal, or high.

Cycle Priority Selection:

• LOW = 24 block moving average
• NORMAL = 6 block moving average
• HIGH = 2 block moving average

This selection allows a user to dictate the speed at which they wish for their first mix to occur/confirm-on chain. This in turn dictates the miner fee portion of a user’s Premix UTXO/s. The higher the cycle priority selected, the larger the miner fee portion will be in the Premix UTXO/s.

Coinjoin Transaction: Inputs

Historically all Whirlpool Coinjoins have been constructed with

• 2 x Premixer UTXOs from separate wallets*
• 3 x Remixing UTXOs from separate wallets

Premixers are new entrants into Whirlpool, and are those who cover the miner fee for the coinjoin transaction. Remixers are those who have already entered Whirlpool, completed their first mix already, and are now “freeriding” to obtain more mixes.

Whirlpool Coordinator: Trigger Fee Rate

The Whirlpool Coordinator is the arbitrator of which 2 x Premix UTXOs are selected to participate in a coinjoin, and bases this decision on the current state of the Bitcoin network with what miner fee rates are likely to confirm within a timely manner. It would be inefficient for the service in which the Whirlpool Coordinator provides to organise and broadcast a coinjoin transaction if said transaction is of a low fee rate and not likely to get mined into a block.

The Whirlpool Coordinator does this by dynamically changing the Coordinator trigger fee rate based on Bitcoin network activity. When on-chain fees are expensive, a high trigger fee rate is set (e.g. 95 sats/vB). A low trigger fee rate is set when on-chain fees are cheaper (e.g. 5 sats/vB). When 2 x Premixers can satisfy the miner fee cost of the 5-input/5-output coinjoin at the Coordinator trigger fee rate, a coinjoin will then be organised and broadcasted to the Bitcoin network.

On-Chain Fees Suddenly Decrease, now what?

Previous to Surge Cycles, if on-chain fees were to have suddenly decreased and there were Premix UTXOs submitted for mixing with a normal cycle priority in mind, this would have lead to a 5-input/5-output coinjoin being created with an overpayment in miner fees.

Consider the following:

1. There are many unconfirmed transaction in the mempool. Miner fee rates are high.
2. Whirlpool Coordinator trigger fee rate is set to 30 sats/vB.
3. There are Premix UTXOs waiting to carry out their first coinjoin. They entered Whirlpool with a normal priority cycle set by the user. It is only possible for the currently registered Premix UTXOs to support a coinjoin transaction broadcasted at a fee rate of 20 sats/vB.
4. The weekend has arrived, and as usually seen there less activity on the Bitcoin network. The mempool starts to clear out and on-chain fee rates drop quickly to 10sats/vB.
5. Whirlpool Coordinator trigger fee rate decreases to 10sats/vB.
6. The normal priority cycle Premix UTXOs are now eligible for their first mix, and a 5-input/5-output coinjoin transaction is broadcast at a fee rate of 20 sats/vB.

The broadcasted coinjoin transaction has however paid double what it needed to due to the sharp decrease in on-chain fees. An efficiency gain is to be had here. Enter Surge Cycles…

Introducing Surge Cycles

Where miner fee overpayment may have been previously seen given certain on-chain conditions, Surge Cycles now makes use of this surplus to allow for larger, more fee efficient coinjoin transactions without compromising the already strong architecture of Whirlpool and privacy gains it provides. This comes with the introduction of the following additional Whirlpool coinjoins transactions:

• 6-inputs/6-outputs
• 7-inputs/7-outputs
• 8-inputs/8-outputs

If the Whirlpool Coordinator trigger fee decreases, rather than a 5-input/5-output coinjoin being organised and broadcasted, a 6-input/6-output, 7-input/7-output, or 8-input/8-output coinjoin may take place instead. This is achieved by the Whirlpool Coordinator selecting additional Remixer UTXOs to participate in the coinjoin thereby increasing the size of the transaction, in terms of virtual bytes (vB), and decreasing the transaction miner fee rate, in terms of satoshis per virtual byte (sats/vB).

Examples For When A Surge Cycles Could Be Triggered

A 5-input/5-output coinjoin broadcasted at a fee rate of 12 sats/vB would pay a total miner fee of 6,120 sats. With the same amount of miner fees paid by the Premix UTXOs it would be possible to broadcast a 6-input/6-output coinjoin transaction at a fee rate of 10 sats/vb, costing 6,120 sats.

Let’s explore some more scenarios.

This table and side annotations show the potential surge cycles that could occur if the Whirlpool Coordinator trigger fee rate decreases due to a drop in on-chain miner fee rates.

• Trigger fee rate decreasing from 20 sats/vB to 10 sats/vB.
  Surge Cycle constituting 10-inputs/10-outputs would be possible.
• Trigger fee rate decreasing from 18 sats/vB to 10 sats/vB.
  Surge Cycle constituting 9-inputs/9-outputs would be possible
• Trigger fee rate decreasing from 16 sats/vB to 10 sats/vB.
  Surge Cycle constituting 8-inputs/8-outputs would be possible.
• Trigger fee rate decreasing from 14 sats/vB to 10 sats/vB.
  Surge Cycle constituting 7-inputs/7-outputs would be possible.
• Trigger fee rate decreasing from 12 sats/vB to 10 sats/vB.
  Surge Cycle constituting 6-inputs/6-outputs would be possible.

This can be easier visualised by plotting miner fee rates against the required transaction miner fee for each “Surge Cycle”.

Maximum Size Surge Cycles

For now we have limited Surge Cycles to a maximum of 8-inputs/8-outputs. While the introduction of Surge Cycles is exciting, we have a responsibility to ensure all transactions are broadcasted with a realistic miner fee rate to ensure successful on-chain transaction confirmation.

Surge Cycle Benefits

1. Increase to the miner fee efficiency for Whirlpool transactions, and more bang for the user’s buck. Those who paid a relative high miner fee rate at the time of broadcasting their Transaction Zero (Tx0) when entering Whirlpool, if the Whirlpool Coordinator trigger fee rate decreases, the miner fee paying Premixers are rewarded immediately with greater privacy; prior to Surge Cycles, the forward-looking anonymity for a user’s first mix was always 5, but now has the potential to be greater than 5.
2. For those who remain in postmix pool size denominations, a quicker increase to forward-looking anonymity; Remixers will now see an increase in their remixing cycle frequency, and forward-looking anonymity will in turn increase quicker for non-remixers, but for who their forward-looking anonymity can be traced to those UTXOs actively remixing.
3. A quicker increase to backward-looking anonymity for those additional Remixers who are added to a Whirlpool coinjoin due to the triggering of a Surge Cycle.
4. Increase in the number of way Whirlpool coinjoins can be interpreted on-chain:
   5-input/5-output = 1,496 interpretations (existing)
   6-input/6-output = 22,482 interpretations
   7-input/7-output = 426,833 interpretations
   8-input/8-output = 9,934,563 interpretations
5. Deterministic links between inputs and outputs remain 100% broken.
6. No client update required. The ability of Surge Cycles has been been introduced into the Whirlpool Coordinator. For existing users the Whirlpool experience does not change — though you may see an uptick in your remixes ;)

Final Note

We have launched Surge Cycles during a period of high fee on-chain activity of which internally we saw the Whirlpool Coordinator trigger fee rate increase to 150 sats/vB; the highest we have ever seen!

Whirlpool will continue to remain geared around 5-input/5-output coinjoin transactions, and though the benefits to Surge Cycles are very much welcomed, we will be continuing to ensure Whirlpool remains just as performant as prior to its introduction.

Surge Cycles In The Wild

• 6-inputs/6-outputs:
  https://kycp.org/#/04d4ffd7f7564490ee6d7431a02a0ce2d24c43a797173365af3dce9fadc22cb7
• 7-inputs/7-outputs: https://kycp.org/#/f82fa771e355ef46e9744da2407f677ea4372d85b61b4a4d735d88a85798dfc4
• 8-inputs/8-outputs:
  https://kycp.org/#/f82fa771e355ef46e9744da2407f677ea4372d85b61b4a4d735d88a85798dfc4

Footnotes

*it is possible for a Whirlpool coinjoin to constitute more than 2 x premix UTXOs.

Introducing Whirlpool Surge Cycles was originally published in Samourai Wallet on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’re happy to announce the release of Samourai Wallet 0.99.98g. You can download the APK from our website or on Google Play. You can find full release notes on our documentation site.

Let’s start with the big news…

Stealth Mode is back!

One of our very first features we launched with in 2015 was Stealth Mode. It allowed Samourai to hide from the Launcher menu and home screen, providing users protection from casual phone searches. It was one of our most popular features at the time. Unfortunately in early 2019 Google forced us to remove Stealth Mode and various other niche security features.

Samourai Wallet on Twitter: "Sad but true, @GooglePlay is forcing us to remove Stealth Mode, SMS Commands, and SIM Switch Defense features as they transition to becoming more of a "Walled Garden" - despite the fact these features have proven record of helping users transact safely. https://t.co/kLRQT9PWvh / Twitter"

Sad but true, @GooglePlay is forcing us to remove Stealth Mode, SMS Commands, and SIM Switch Defense features as they transition to becoming more of a "Walled Garden" - despite the fact these features have proven record of helping users transact safely. https://t.co/kLRQT9PWvh

We are very happy to announce that — finally — as of Dec 27 2022, Stealth Mode has returned to Samourai Wallet. Let’s dig in and check it out.

You can find Stealth Mode by opening your wallet and navigating to Settings > Wallet. Once there, toggle on Stealth Mode and select which decoy app you want to use.

Once Stealth Mode has been enabled your wallet will automatically hide itself when you fully exit the wallet. Each decoy app has a different method of triggering the wallet to open and prompt for your PIN code.

Samourai Wallet on Twitter: "No you can't do that anymore. Each decoy app has a different way to launch the wallet. Calculator decoy app launches wallet with 5 taps of the "=" symbol pic.twitter.com/F6e6FvKc92 / Twitter"

No you can't do that anymore. Each decoy app has a different way to launch the wallet. Calculator decoy app launches wallet with 5 taps of the "=" symbol pic.twitter.com/F6e6FvKc92

We’re very pleased to finally bring back the Stealth Mode feature. We look forward to hearing all your Decoy App ideas.

Broadcast Transaction Hex

Another notable improvement builds on our last release where we introduced a new Tools screen. In this release we have included a brand new tool, the ability to broadcast any signed transaction in Hex format.

This tool allows you to use your Samourai Wallet to broadcast transactions that it didn’t create or have private keys for. This could be useful for cold storage systems, but more importantly this helps solidify our commitment to censorship resistance. Every Samourai Wallet app can now broadcast any valid bitcoin transaction on behalf of any another party. We’ll continue to build out useful tools and utilities for the new Tools screen.

Thank you

Download Samourai Wallet 0.99.98g today. You can download the APK from our website or on Google Play. Join our Telegram to keep up to date on development and to receive help from the very helpful community.

If you need any help or assistance reach out on samourai.support and view documentation on docs.samourai.io. Please be aware there are numerous scam/impersonator accounts claiming to be Samourai Wallet support. We do not provide support anywhere but the samourai.support platform.

Wallet Update 0.99.98g — The Stealth Mode update! was originally published in Samourai Wallet on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is a big update with dramatic UI changes, new functionality, the release of a brand new feature, and improvements for our power users.

PayNym Bot & Toolbar Menu

You’ll notice that the Samourai logo in the top left of the toolbar has been replaced with your individual PayNym Bot image. A PayNym Bot is a visual representation of a BIP47 Reusable Payment Code. A Bot is created by taking a BIP47 code and applying a hashing algorithm which produces a unique fingerprint used to create the Bot image. So each bot image is unique to each wallet. If you tap your PayNym bot image you will open the new toolbar menu.

In the Toolbar Menu you’ll notice some new options such as Collaborate and Tools. So let’s move on to the next major UI update we have made, Collaborative Transactions (Cahoots) has had a major UI rework.

Collaborate

The collaborative transaction has a long history in Samourai. In March 2019 we released our first iteration of collaborative transactions. It required users to manually scan and share at least 5 QR codes with their collaborator. It was just a start but we knew it would develop into a key feature.

In November 2020 we released our new open source app-agnostic, Tor based encrypted communication protocol called Soroban. This allowed us to automate the coordination of small 2 person collaborative coinjoin transactions to make them much quicker than before and without using a centralised coordinator. These transactions, STONEWALLx2 and Stowaway enjoy heavy use among our user base and have even been implemented along with Soroban in third party wallets such as Sparrow Wallet.

In this update we have created a brand new UI for both initiating and collaborating in STONEWALLx2 or Stowaway transaction.

Up until now the collaborative transaction workflow and UI were somewhat of an afterthought, and users needed to be pretty savvy in navigating around the app to make use of the feature.

This update should make it even easier for anyone to participate or initiate a new collaborative transaction. Both initiation and participation are located in one easy to reach location (before this update there could be 4 different places to go to initiate or participate in a transaction like this!)

For those that need a quick primer on STONEWALLx2:

This type of transaction is a two person coinjoin that the sender and a third party collaborate to send to an external wallet. This is a great choice when sending to someone who doesn’t have Samourai Wallet, for instance a merchant using BTCPayServer. Using a STONEWALLx2 transaction to make your payments undermines the Common Input Ownership Heuristic — a bedrock of blockchain snoops and spies.

Introducing JoinBot

One of the problems that remain with Collaborative Transactions in Samourai Wallet is that you need someone to collaborate with. This can be a problem for many users, especially new users. They may want to explore the feature, or benefit from the privacy enhancements that Collaborative Transactions offer but be unable to do so because they don’t have anyone they can collaborate with.

This is the perfect time to introduce our newest feature, JoinBot. For a small spam prevention fee you can have JoinBot act as the second participant in a STONEWALLx2 collaborative transaction

There are some benefits choosing to use JoinBot as your STONEWALLx2 collaborator.

• Joinbot is always online, so it is great for time sensitive payments where you might not have time to find a collaborator who is online and able to help you.
• Joinbot only uses UTXOs directly from Whirlpool postmix, so you do not need to worry about the history of the collaborating UTXOs and how they have been handled by the collaborator.
• Since JoinBot is online 24/7 it always has UTXOs registered for remixing, so there are very good odds that you collaborating with extremely well remixed UTXOs.

JoinBot fees

There is a small anti-spam fee in addition to the usual miner fees when using JoinBot. The service fee is set at 3.5% of the send amount or 0.01 BTC, whichever is less.

For example, if you are sending 0.1 BTC using JoinBot as a collaborator the fee would be 0.0035 BTC, meanwhile sending 1 BTC would use the capped maximum fee of 0.01 BTC.

The fee is paid in a second transaction automatically using another type of collaborative transaction called Stowaway.

The fee transaction is not associated with the JoinBot transaction on the blockchain. This makes sure the STONEWALLx2 transaction made with JoinBot looks like every other STONEWALL transaction out there, you cannot tell any difference.

Some caveats

• You will need to have at least two unrelated UTXOs available in your wallet in order to successfully perform a STONEWALLx2 with JoinBot.
• STONEWALLx2 requires that both participants each pay half of the transaction miner fee. This is respected with JoinBot, but you will reimburse JoinBot for that half of the miner fee within the anti-spam fee transaction.
• For this initial release we are only allowing a maximum transaction amount of 1.5 BTC using JoinBot as a collaborator. The minimum amount you can send is 546 sats.

Tools

We’ve also introduced a new screen in the wallet activated from the new Toolbar Menu. This screen is called ‘Tools’ and contains new UI for sweeping private keys and calculating addresses for your wallet. Most casual users will not have much need to use this section of the wallet, but will be a big upgrade for our power users.

• Sweep Private key — You now have full control of the miner fee you pay for sweeping a private key, as well as what address derivation you wish to sweep to. The final big change here is you can now sweep Taproot addresses into your Samourai Wallet.
• Sign Message — We moved this from where it was buried in the settings. You can now very easily sign a message using any address on any derivation within your wallet.
• Wallet Address Calculator — Again, we moved this from buried deep in the settings. You can now derive address, redeem script and private key from any address in your wallet on any derivation path.

Authenticate using PayNym

A few years ago we came up with a specification for allowing users to login to websites/apps without needing to provide a username or password, just by using their PayNym. Sparrow Wallet has already added this specification into their wallet. Keep tuned for further announcements about this feature in the near future.

Thank you

Download Samourai Wallet 0.99.98f today. You can download the APK from our website or on Google Play. Join our Telegram to keep up to date on development and to receive help from the very helpful community.

If you need any help or assistance reach out on samourai.support and view documentation on docs.samourai.io. Please be aware there are numerous scam/impersonator accounts claiming to be Samourai Wallet support. We do not provide support anywhere but the samourai.support platform.

Wallet Update 0.99.98f was originally published in Samourai Wallet on Medium, where people are continuing the conversation by highlighting and responding to this story.

Intro

A financial flow (transaction graph) analysis aims to track a single entity’s spending over multiple transactions. By naively mapping the flow relationship of bitcoins, analysts can miss obvious signs of coins changing hands.

Additional information known as wallet or software “fingerprinting” can be used to help determine when bitcoins are spent by a different software. Spending by wallets with a new fingerprint is a heuristic for coins changing ownership. The latest OXT transaction graph update visually encodes changes in wallet fingerprints on the graph to improve analysis accuracy.

Entity Tracking Recap — Change Detection

To track an entity, “change detection” heuristics are used to determine which transaction outputs are payments and which outputs are “change” returned to the original spender. The analyst evaluates the full transaction details including the input and output amounts, script types, output positions, and more. If one or more change heuristics can be applied, the analyst continues tracking the spender to the next transaction. We previously presented several change detection heuristics in these posts and Youtube playlist.

Applying these simple heuristics in combination can be extremely accurate. Academic researchers are looking to thoroughly establish the accuracy of change detection heuristics using machine learning algorithms as presented here and here.

The results of these papers indicates that including wallet fingerprinting such as different script types, version numbers, and lock times encountered during a transaction graph analysis can be used to improve tracking.

OXT’s New Fingerprint Mode

OXT’s transaction graph is a directed acyclic graph. Nodes on the graph represent transactions. Edges (lines) map the relationships between nodes. To provide maximum detail and minimize cognitive load on the analyst, OXT’s new Fingerprint Mode encodes the various transaction and TXO data in different ways.

Transaction details are encoded by varying node shapes and shading. TXO details are encoded by varying edge linetype and color.

The end result makes change detection easier for analysts and visually displays different fingerprints to transaction graph observers without the observer needing to know what these differences are.

With this new data visualizer, bitcoin users can keep pace with the advances in academic research and evaluate the impacts of using wallets that do not support anti-fingerprinting defaults.

Menus and Buttons

A summary of the buttons on the transaction graph tool bars is presented below.

Quick access menus for transactions, TXOs, and comments are presented below. These are accessed via right-clicking the desired object.

Fingerprint Mode Legend

Transaction Version Number Encoded via Node Color
dark grey = version no. 1
light grey = version no. 2

Transaction Locktime Encoded via Node Shape
circle = 0
square = block height
hexagon = timestamp

TXO “Script Hash” Type via Edge Dashing
one interspace = P2SH
two interspaces = P2WSH
three interspaces = P2TR
no dashes = non script hash scripts (unnested P2PKH, P2WPKH, raw multisig, etc)

TXO Script Type via Edge Coloring
green = P2PK/P2PKH
orange = multisig
yellow = OP_Return
light-blue = P2WPKH/P2SH
pink = non-standard

Additional Updates

OXT.me

• Search Bar: auto-completes possible addresses with additional unique address characters

Transaction Graph

• Mouse hover over transactions now includes version number and locktime
• Transaction Details Window includes txid copy button
• Transaction Details Window includes expand all inputs or outputs buttons
• When expanding a single TXO from the transaction details window, the selected TXO is automatically made active

Enjoy the update. Comments and feedback are welcome.

OXT Update was originally published in OXT Research on Medium, where people are continuing the conversation by highlighting and responding to this story.

The author of the article reached out to us on March 11 with the following questions to allow us to respond.

Since only a single sentence of our response was used in the resulting article we have decided to publish our entire response that we sent to the Financial Times below.

There must be a distinction made between what the NCA has labelled ‘crypto mixers’ and the open source software algorithms that are used in Samourai Wallet, known as CoinJoin. A “mixer” implies a custodial system where crypto is sent into the control of a third party custodian who promises to send back crypto that is unrelated to the deposit. The software that Samourai Wallet produces is fundamentally different. In the Samourai software, users individually collaborate with each other to compose what are known as CoinJoin transactions to themselves. The user retains custody of their bitcoin at all times and a transmission of funds to any third party never occurs.

While it is true that Bitcoin is a pseudonymous system at the protocol level, the vast majority of crypto on-ramps and off-ramps are the custodians of vast amounts of personally identifiable information about their users — to comply with KYC and AML guidelines and regulations.

Several of these custodians have had serious data breaches where this sensitive information is now in the hands of criminals and other bad actors putting innocent users at increased risk of being the target of serious crime like fraud, kidnapping, or worse. With transparent ledgers like the Bitcoin blockchain every transaction is publicly recorded and viewable by anyone indefinitely, a situation no normal person would tolerate in the existing financial system. The existing system has several legislative mechanisms built in that ensure basic privacy (your bank doesn’t share your account balance and transaction history with the barista at the coffee shop for example). The blockchain doesn’t have the luxury of legislative power to solve these problems, therefore software solutions such as CoinJoin are used to obtain these basic protections.

The argument that crypto users identity is obscured on the blockchain so users shouldn’t need to worry themselves with basic financial privacy is not only bad advice, it is a feeble attempt to justify an unprecedented encroachment into the financial privacy of law abiding citizens. The NCA’s remit is to stop serious and organized crime not regulate the behaviour of law abiding citizens.

Elliptic doesn’t provide the underlying data they use to produce these unverifiable numbers. Their methodolgy is often a black box, where headline numbers and charts are presented in lieu of data. Likewise, government contracts play an important part of for profit businesses like Elliptic. It is our contention that these figures are likely overstated. For H1 2021, FINCEN estimated ransomware, by far the largest illicit use volume of bitcoin, to mixer flows at only 1% (source). Elliptic’s and FINCEN’s estimates are an order of magnitude apart, which implies one of them is wrong.

We believe the vast majority of users who are using non custodial CoinJoin software are law abiding and simply trying to obtain a basic level of financial privacy when using a transparent and public blockchain.

Businesses that take custody of funds on behalf of customers are already heavily regulated. We agree that the use of centralized mixers that take possession and custody of funds should be scrutinized and avoided. However, free and open source software algorithms in which there is no entity that takes custody of funds cannot be effectively regulated. We believe the NCA should instead focus on more productive methods to prevent serious crime and catch criminals.

The National Crime Agency vs non custodial CoinJoin was originally published in Samourai Wallet on Medium, where people are continuing the conversation by highlighting and responding to this story.

When we started building Samourai Wallet in 2015 one of our first priorities was to enable the software to work through the Tor network for increased user privacy and protection. Tor was still a little hairy on mobile at that time, but using a third party app (Orbot) our users were able to make use of Tor with the wallet.

A few years later, Samourai Wallet was the first mobile bitcoin wallet to include Tor as fully integrated functionality, meaning users no longer needed to have a third party app installed. They could route all traffic through Tor with the simple press of a button. This dramatically increased the number of users making use of Tor.

Since then we have released Samourai Dojo, a full bitcoin node based wallet back-end that can power your Samourai Wallet and runs natively over the Tor network. We also released Samourai Whirlpool, a blinded Chaumian CoinJoin implementation that requires Tor to function properly. Earlier this year we released Samourai Soroban, a Tor based encrypted message passing system designed for use in peer2peer CoinJoin transactions that are available in the wallet.

All of the free and open source software that Samourai releases makes heavy use of the free and open source Tor software maintained by the Tor Project. We are proud to announce today that we are able to support the work of the Tor Project with a $50,000 USD donation and joining the project as a “Vidalia Onion” member.

We’re proud to have been able to give back to one of the most important technologies available in reclaiming and preserving your privacy. To make your own donation to the Tor Project visit https://donate.torproject.org/

Supporting the Tor network with a $50,000 donation to the Tor Project was originally published in Samourai Wallet on Medium, where people are continuing the conversation by highlighting and responding to this story.

Applying Chain Analysis Concepts To Improve User Privacy

Introduction

So far this guide has introduced the basics concepts used by chain analysis and the concepts used to undermine chain analysis.

It is unlikely that users reading this are looking to become “experts” in chain analysis, but a fundamental understanding of the tools and concepts used to attack their privacy will allow them to better protect their privacy.

In this section we will introduce the real world implications of sending and receiving transactions on user privacy. From there we will present specific privacy enhancing technologies that can be used to maintain privacy when interacting with bitcoin.

Lost On Chain — Starting Points And Breaking Pseudonymity

Bitcoin is pseudonymous by default. Without additional information tying user activity to on-chain activity, an analysis has no “starting point” for tracking related bitcoin network activity.

Starting points typically include users willingly disclosing addresses they control. Provided addresses are typically for receiving payment. Starting points can also be obtained from information provided by third parties, such as the information sharing agreements between surveillance firms and exchanges.

For beginner analysts, some “context” is usually necessary for performing an analysis. That valuable context often comes from analysis of their own transactions. Users evaluating their own transaction history via a third party block explorer are encouraged to use a VPN or Tor browser to prevent linking of their IP address with their transaction information.

OXT Workflow — Addresses As Starting Points

Most users query block explorers by entering an address as a starting point. When querying OXT with an address as a starting point, the associated transaction information will not automatically be displayed. Users should follow the steps below to navigate to the transaction graph.

1. Log in to your OXT account. Accounts are free and do not require any personally identifiable information for creation.

2. Enter the desired address into the search bar.

3. Navigate to the TRANSACTION TAB

4. Select the desired transaction. Users should note that a starting address may have received multiple payments. If the address has received multiple transactions, they will have to select the desired transaction based on volume and timing of the transactions.

5. From there the Transaction Page will be opened.

6. Open the transaction graph to begin the financial flow evaluation.

Note: If users already have the desired transaction ID, they can avoid logging into OXT and navigate directly to the transaction page for accessing the transaction graph. Revisit Part II for additional details on interacting with the transaction graph.

Analysis Directions — UTXO History And Future Spending

Analysts presented with a starting transaction and UTXO can pursue two investigation “directions”.

They can search for the “source” of funds by evaluating the past history of the target UTXO. Source evaluation for transaction chains with a single input are fairly simple to perform, because there is no “decision” to be made in evaluating which input UTXO path to follow. However, multi-input transactions present analysts with multiple sources to evaluate.

Analysts can also search for the “destination” of future spends from the associated UTXO by applying the change detection heuristics presented in Part I and external transaction data presented in Part II.

Note: UTXO flows should not be tracked across custodial services. It is highly unlikely that a deposit UTXO will be used to payout to the entity making the deposit.

Privacy Implications Of Sending And Receiving Payments

When sending or receiving a payment, users necessarily reveal some of their UTXO set to their counterparty. For naively managed UTXOs, this may reveal a users entire wallet balance to a counterparty.

Disclosing wealth for making payments is an unfortunate side effect of bitcoin’s transparency. The negative implications of this disclosure to counterparties should be obvious, particularly for simple spends.

In addition, payments made by a sender allow for a recipient to assess the senders past transaction history. Payments also allow a sender to evaluate a recipients future spending of their received payment.

The techniques discussed below are designed to mitigate the negative side effects of bitcoin’s transparency.

Samourai Wallet Privacy Enhancing Transactions

Much of chain analysis is based on the following core concepts:

• analysts needing a starting point
• the issues of the transaction graph
• change detection
• clustering separate addresses by the common input ownership heuristic

In Part I and II we introduced the core concepts of chain analysis. Part III presented the concepts used to undermine these techniques.

The OXT team works with the Samourai Wallet developers to test and create techniques that mitigate the privacy shortcomings we have introduced so far. These techniques are discussed below.

Stealth Addresses — Denying a Start Point

Chain analysts need a starting point when attempting to track an entity’s on chain activities. This typically means linking a target’s online activity with an address they have posted for receiving payments or donations. From this address an analyst can evaluate a user’s activity including received payments, total address balance, and spending patterns.

User’s frequently share addresses for receiving payments. The shared addresses are the same addresses that appear on the blockchain and are searchable via any block explorer.

Instead of exchanging a direct address for receiving payment, users can exchange “stealth addresses”. Stealth addresses are based on concepts derived from the Diffe-Hellman key exchange, a critical cryptographic concept that underpins TLS/SSL, one of the most important forms of cryptography used in internet secure communications.

Samourai Wallet’s stealth address implementation is based on the BIP 47 Proposal by the Open Bitcoin Privacy Project. BIP 47 reusable payment codes allow a sender to: create an unlimited amount of unique bitcoin addresses for payment to the intended recipient without the recipient needing to be online.

Reusable payment codes deprive analysts of a “free” starting point on the bitcoin block chain. More information on Samourai Wallet’s reusable payment code can be found here.

Coin Control — UTXO Segregation

Combining inputs from multiple sources in future spends can allow payment senders to evaluate the transaction histories of additional UTXOs combined with their spent UTXO.

To mitigate this privacy leak, users can practice “coin control”. Broadly coin control consists of several steps.

• Labelling received payment UTXOs. At a minimum labelling should include the sender and reason for payment.
• “Marking Do Not Spend”. To prevent a wallet from accidentally including a UTXO in a future payment, UTXOs can be made inactive for inclusion in future spends.
• Sending Individual (Selective UTXO Activation). UTXOs can be selectively spent.

When payments are made, users should also get in the habit of labelling their change UTXOs. When a label is added to a single UTXO, Samourai Wallet will automatically label any other UTXOs (change outputs) from the same spend with the same label.

Ricochet — Adding Distance

Ricochet is a simple tool that automatically adds “hops”, or dummy transactions between an origin UTXO and payment destination. Ricochet transactions do not obfuscate source of funds or break the transaction graph. However, these transactions put distance between a payment destination and previous UTXO histories.

Source of fund evaluation for transactions with a single input are relatively easy to perform, but adding “hops” requires a receiving entity to evaluate history beyond the immediate incoming UTXO. Transaction graph traversal analyses are simple to perform, but expanding incoming UTXO history evaluation implies additional doubt based on the “UTXO Ownership Model” which increases chances for false positives.

The current version of ricochet includes four extra hops. A more “dynamic” ricochet with a variable number of hops is planned in future updates. More information on ricochet can be found here.

STONEWALL and STONEWALLx2 — Payments Made Safe

STONEWALL and STONEWALLx2 use the same coin selection algorithm to create transactions with coinjoin properties. STONEWALL is a simulated coinjoin that uses inputs from an individual wallet. STONEWALLx2 is a “true” coinjoin that uses inputs from 2 collaborating users/wallets.

Using the same algorithm means these transactions have identical on-chain footprints, and are indistinguishable to outside observers. As a result, analysts must consider the possibility that any STONEWALL transaction is a “true” coinjoin.

The STONEWALL algorithm is an extension of the transaction properties aimed at defeating simple spend change detection heuristics such as like-type output scripts and randomised change output position.

Due to their coinjoin properties, stonewall transactions are capable of defeating the round output payment heuristic interpretation that cannot be defeated by a simple spend. Stonewall defeats these heuristics by creating transactions with a “dummy” output equal to the intended payment amount.

STONEWALL’s are true payments, that still include deterministic links for their “change” UTXOs. Because a STONEWALL can be a two-wallet coinjoin, a transaction counterparty cannot be sure which change UTXOs belong to the transaction sender responsible for making the payment and which change UTXO belongs to the coinjoin collaborator.

Stowaway — Breaking the CIOH

As we described in Part III, payjoin transactions undermine the common input ownership heuristic. If a single UTXO does not have a sufficient balance to make the desired payment amount, wallet software will include additional inputs as needed to meet the desired amount. Analysts can potentially incorrectly assume the inputs these transactions are controlled by the same wallet.

Payjoins typically have no indistinguishable on chain fingerprint. By including inputs from the transaction sender and payment recipient, two wallets are used to construct the transaction. This undermines the CIOH and creates a “false cluster”. As a consequence of the recipient contributing inputs to the transaction payjoin, the true transaction payment amount is also hidden.

Whirlpool Coinjoin — Creating Forward Privacy

Payment senders can track the future spending of their payment UTXO and potentially obtain additional information about their counterpatry’s wallet composition. To maintain their privacy, payment recipients can coinjoin to break the link between their payment receipt and future spending. In otherwords, sending UTXOs received as payment through a coinjoin establishes forward privacy.

Whirlpool is the only 100% entropy zerolink coinjoin implementation. Whirlpool coinjoins do not include “unmixed change” outputs within the coinjoin transaction that can be used to continue to track user activity.

The Whirlpool transaction process begins with the Tx0 which pays the coordinator fee, creates premix UTXOs that are equal to the pool denomination plus miner fees, and a segregated change UTXO.

Inputs to a Tx0 should be selected with care to avoid linking UTXOs from different sources. Combining multiple inputs sources reveals common ownership. The change UTXO should also be handled with care so as to not directly link any future spending activity.

After coinjoining and breaking the links between their original (premix) UTXOs and postmix UTXOs, payment recipients can be confident that any payment senders will not be able to reliably follow the future spending of their payment UTXO.

Review

Bitcoin maintains basic user privacy with its pseudonymous nature by not linking real world identities and activities on the blockchain.

At the protocol level, bitcoin transactions send bitcoin to and from transparent addresses for transparent amounts. This transparency has lead to a proliferation of block chain analysis. The bulk of what is considered chain analysis involves payment change detection, transaction graph analysis, and use of the common input ownership heuristic for “wallet clustering”.

While many of these techniques rely on heuristics, applying external transaction data such as address reuse and outputs to or from centralised services can significantly undermine the ambiguity of simple bitcoin transactions.

Wallet software can include randomised fingerprinting and like-type address outputs to maintain ambiguity of simple spends. Even with these tools, the on-chain flows of bitcoin remain “traceable” and deterministic. Properly constructed equal output coinjoins remain the best way for breaking deterministic links and introducing plausible deniability into the transaction graph.

It is likely that the typical user reading this guide is not looking to become an expert in chain analysis. Rather they are looking to improve their privacy when sending and receiving payments. The act of sending and receiving payments necessarily reveals UTXO set information about a sender’s wallet to a payment recipient. As a result, payment senders and receivers are able to evaluate the respective past and future spending of these known UTXOs, which can reveal additional information about their counterparty.

Users armed with knowledge of chain analysis are better prepared for evaluating the implications of spending and receiving and can begin to take steps to protect their privacy.

Those steps include: not linking blockchain activities to an online persona, avoiding address reuse, segregating UTXOs with different histories, establishing forward privacy with coinjoin, and using the advanced spending tools previously discussed to undermine chain analysis heursitics.

Knowledgeable use of these techniques can allow users to obtain a basic level of privacy they may be accustomed to in the traditional finance system.

Closing

A general bitcoin privacy and OXT guide has been requested by many readers. Our hope is that this provides you with a starting point for continuing to expand your understanding of bitcoin privacy.

Armed with additional knowledge and context from this guide, long term readers are encouraged to revisit our previous research reports. Particularly the previously included transaction graphs.

Feedback, comments, and requests for additional guides are welcome.

Thanks for reading and stay safe.

- The OXT Research Team

Understanding Bitcoin Privacy with OXT — Part 4/4 was originally published in OXT Research on Medium, where people are continuing the conversation by highlighting and responding to this story.

Defences Against Chain Analysis

Introduction

With the foundational concepts of chain analysis introduced in Part 1 and Part 2, Part 3 will discuss the methods for undermining chain analysis.

In this section we will present the following:

1. defeating heuristics for change detection in simple spends
2. creating an ambiguous transaction graph with equal output coinjoins
3. undermining the CIOH with coinjoins

The UTXO Ownership Model & Ambiguity Of Simple Spends

Previously, we introduced change detection heuristics for simple spends with 1 input and 2 outputs. We assumed that the transaction included a payment and change output.

In reality, a simple spend has many additional interpretations based on the UTXO “ownership model”. The ownership model attempts to assign ownership to the inputs and outputs of a transaction. The complete ownership interpretations for a transaction with 1 input and 2 ouputs are shown in Fig 3.1.

Each of these interpretations must be considered by an analyst, especially when only applying internal transaction data. Interpretations can be eliminated when accounting for additional wallet fingerprinting, normal wallet behaviour, and typical user behaviour.

Typical user behaviour makes interpretations 1 and 2 most likely. Interpretations 3 and 4 are possible, though many bitcoin wallets to do not have batch spend functionality. Interpretation 5 is rare due to extra fees paid and UTXO set bloat.

The application of external transaction data such as outputs sent to centralised services or reused addresses, can be used to eliminate interpretations. Due to the concentration of the bitcoin transaction graph around centralised services and patterns of normal user behaviour, these full interpretations are rarely considered in practice.

Defeating Change Detection Heuristics

Transactions can be made more ambiguous by wallet software that aims to defeat the heuristics for change detection presented in Part 1. When taken in isolation, the transaction below is an example of a “maximally” ambiguous simple spend.

Round Number Payment Heuristic Defences

The payment amount is determined by the user. If a user selects a round payment amount, it is difficult for a wallet to protect against this heuristic in a simple spend. For most true payments (priced in fiat), this heuristic is less likely to apply. The example in Fig 3.2 above does not have a round number payment amount and maintains protection against this heuristic.

Identical Change Output Script Type

The example transaction has identical output script types for both outputs so the unique script output heuristic does not apply. This helps to maintain ambiguity and makes change detection more difficult.

Randomised Change Output Position

To further increase the ambiguity of this wallet’s behaviour over a series of transactions, wallet software must randomise the change output position. Alternating the change position between output 0 and 1 would make the automated tracking of wallets like the activity shown in Fig 2.8 more difficult.

Evaluate the Transaction Including External Transaction Data

OXT’s transaction graph shows relative UTXO and transaction amounts by varying line weights. In this way, expanding the transaction graph automatically includes some external transaction data.

Based on the transaction graph and future UTXO spending, which output might be the payment? Do the addresses in this transaction have any previous history of reuse?

This is a perfect example of how external transaction data can be used to aid in determining payments and establishing a change output. Expand the transaction graph or follow the future UTXO spending to verify your payment/change assumption.

UTXO Flows And Deterministic Spends

Identical change output scripts and randomised change positions can be applied by wallets to maintain the ambiguity of simple spends, but they do not address the fundamental link between inputs and outputs consumed in a transaction.

A link always exists between a transaction’s inputs and outputs. These intra-transaction UTXO relationships can be thought of as “flows”. Where the BTC consumed by input UTXOs are transferred to the output UTXOs.

In the case of a simple spend (1 input and 2 outputs), the single input must have been used to pay both outputs. A simple spend’s intra-transaction flows only have a single interpretation. As a result, the link between the single input and each output is mathematically deterministic (certain).

The link between inputs and outputs can be displayed on the OXT transaction graph by selecting an input or output. The transaction visualiser at kycp.org also shows the intra-transaction links.

Breaking Links — Non Deterministic Transactions

Though UTXO ownership ambiguity always exists, the UTXO ownership model cannot be relied upon to obfuscate on-chain BTC flows. Without breaking deterministic links and introducing ambiguity into the transaction graph, bitcoins remain “traceable”.

Breaking deterministic links and creating on-chain ambiguity requires a specific transaction structure. Determinism is dependent on the number of transaction inputs, outputs, and the BTC amounts of each UTXO.

By themselves, transactions with multiple inputs and outputs can create a noisy transaction graph. These types of transactions are not easily interpreted without special tooling or considerations.

Despite the noisy transaction graph, deterministic links between UTXOs of transactions with multiple inputs and outputs can still be evaluated. Kristov Atlas was the first to introduce this concept in his “CoinJoin Sudoku” advisory and algorithm.

In a coinjoin, users pool their funds and collaborate to construct a transaction. Typically by creating a transaction with equal output amounts. The CoinJoin Sudoku algorithm uses a branch of mathematics called subset sum analysis to evaluate transactions for “common ownership” of inputs and outputs.

A discussion of these maths is beyond the scope of this guide, but the important takeaway is that a naively constructed coinjoin transaction can be evaluated for deterministic links.

Today, the coinjoin sudoku concept has been extended with the Boltzmann algorithm created by the OXT lead developer, LaurentMT. Boltzmann uses the CoinJoin Sudoku concept to evaluate transactions for several privacy related metrics.

For properly constructed coinjoins, a link between inputs and equal outputs still exists, however these links are probabalistic not deterministic. The Boltzmann algorithm calculates a Link Probability Matrix (LPM) for the relationship between a transactions inputs and outputs.

A transaction’s LPM output can be found on the TRANSACTION page on OXT. In the INPUTS&OUTPUTS tab, the link subset between an input and each output can be seen by clicking the “CHAIN ICON” to the right of the desired UTXO.

The LPM for selected UTXOs in evaluated transactions can also be found by selecting inputs and outputs on the OXT Transaction graph (see Fig 3.3). A visual of the full LPM produced by Boltzmann’s algorithm can be found at kycp.org.

Entropy — Equal Output CoinJoins And When Is It Appropriate To Apply The CIOH

In an equal output coinjoin, multiple users collaborate to create a transaction that pools their funds and breaks the deterministic links between their transaction input and equal output.

By including multiple users, these transactions also break the CIOH. Assuming inputs to transactions that could be coinjoins are controlled by a single wallet could result in a false positive wallet cluster by the CIOH.

To avoid this an analyst could apply an equal output heuristic to transactions that may be coinjoins. However, all transactions having multiple equal outputs are not necessarily coinjoins. If constructed naively, transactions with multiple equal outputs may still have deterministic links between inputs and equal outputs, which is evidence that a transaction is not a coinjoin.

Instead of incorrectly clustering a transaction or naively excluding transactions with identical outputs, analysts can truly evaluate transactions for coinjoin properties using Boltzmann.

Boltzmann effectively uses subset sum analysis to ask the question: Are there multiple ways (interpretations) a transaction’s inputs could have paid its outputs?

If a transaction has multiple intra-UTXO flow interpretations, Boltzmann will score the transaction’s entropy greater than or equal to 0. The concept of entropy originates from a thermodynamic mental model. In this model, the number of interpretations can be thought of as microstates of the overall transaction macrostate.

Entropy can be seen as a metric measuring the analysts lack of knowledge about the exact configuration of the transaction being observed.

Transactions with entropy have coinjoin properties and broken deterministic links. Coinjoin properties are evidence that a transaction has multiple users contributing inputs to the transaction. Conservatively, the inputs to transactions with entropy should not be clustered by the CIOH.

KYCP Transaction Interpretation

KYCP includes a significant amount of transaction information including address reuse across the transaction, deterministic and probabilistic links, and input and output merges. The example transaction above is a dark wallet coinjoin transaction. The deterministic links for equal outputs are broken, but deterministic links still exist between the inputs and “change outputs”. Also note that output 1 and 3 are sent (merged) into the same future transaction. Indicating that the same users/wallets are mixing together again.

CoinJoins — Equal Output (Encryption) vs. PayJoin (Steganography)

Equal output coinjoins have a unique on-chain footprint that can be identified by the presence of multiple equal outputs. But the flows across the transaction for equal outputs are not deterministic. If an analyst knows they are observing a coinjoin, they must consider the user they are attempting to track controls one of the many equal outputs. In most cases this is enough to stop an analyst in his tracks.

When an analyst encounters an equal output coinjoin, they know a privacy technique is being used but cannot reliably interpret the transaction. In this way, equal output coinjoins are similar to encryption. Observers of encrypted messages know a message exists (can observe the coinjoin) but cannot decipher the message (reliably interpret the flows across the transaction).

The other type of coinjoin is called payjoin or pay-to-end-point or Stowaway in Samourai Wallet. Payjoin transactions consist of a collaborative transaction between the user making a payment and the user receiving a payment. On the blockchain, many payjoins have no discernible patterns or applicable heuristics.

In effect, payjoins are indistinguishable from a normal transaction where a user spends multiple UTXOs. Without any distinguishable on chain transaction footprint, an analyst may incorrectly apply the CIOH to these types of transactions and incorrectly assume each of the inputs are controlled by the same user.

In this way payjoin transactions are a steganographic technique. Steganography is the process of hiding a secret message (the fact that a coinjoin has occurred) within otherwise normal appearing data (a normal transaction spending multiple inputs). Because payjoins do not have any reliable on-chain footprint, they often result in false clusters by the CIOH.

Other Techniques — “Breaking” The Transaction Graph

Custodial tumblers, often referred to generically as mixers, are one of the oldest privacy techniques employed at the application layer. The purpose of custodial tumblers is to act as a swap service. Users deposit coins to the tumbler and (hopefully) receive different UTXOs with a new transaction history in return. Ideally, the swapping process results in a “broken” transaction graph that severs the link between a user’s deposits and withdrawals.

This techniques also popularised the concept of “taint”. Where tumbler users may unknowingly receive UTXOs with some “problematic history” as a part of their swap. Interested readers can see our evaluations of two of the largest custodial tumblers (ChipMixer and Blender) from our investigation of the Kucoin Hack.

Additional privacy enhancements such as coinswaps aim to break the transaction graph in a non-custodial way. These techniques are still in their infancy. Without additional mitigation, these theoretical swaps will suffer from the same “taint” swapping issues as custodial tumblers. This section will be updated as additional techniques are deployed.

Review

In Part 3 we introduced the many tools capable of defeating the main heuristics of chain analysis.

Change detection heuristics can be defeated by avoiding round payment amounts, creating transactions with identical change output script types, and randomising change output positions.

Equal output coinjoins are collaborative transactions involving multiple users. By breaking deterministic links these transactions create ambiguous transaction graphs. By involving multiple users, they defeat the CIOH.

Payjoin transactions are also collaborative transactions. They involve the payer and payee in creating a transaction and have the same transaction fingerprint as a normal multi-input spend. Without an identifiable fingerprint, these transactions defeat the CIOH.

Part 4 discusses:

1. Analyses needing a “starting point”
2. The privacy implications of sending and receiving payments
3. How existing privacy techniques can mitigate many of the issues discussed throughout the guide.

Understanding Bitcoin Privacy with OXT — Part 3/4 was originally published in OXT Research on Medium, where people are continuing the conversation by highlighting and responding to this story.

Chain Analysis Core Concepts

Introduction

Now that we have presented the basic concepts in Part 1, we can move on to the core concepts that underpin chain analysis by expanding our analyses to include “external” transaction data.

Specifically, Part II will focus on two of the most important tools underpinning chain analysis:

1. The transaction graph
2. The common input ownership heuristic (aka wallet clustering)

External Transaction Data

External transaction data can be used to improve confidence in change detection (weaken transaction privacy) by leveraging additional information and patterns.

External transaction data includes any information not strictly limited to the information included in an individual transaction by the bitcoin protocol. Examples include:

• address reuse over multiple transactions
• co-spending from multiple addresses in the same transaction (wallet clustering)
• multi-sig scripts (which are only revealed after a UTXO is spent)
• wallet fingerprinting over a series of transactions
• off-chain data such as outputs spent to labelled clusters and IP addresses of nodes broadcasting a transaction
• volume, timing, and other transaction pattern recognition analysis

Transaction Graph Analysis

Transaction graphs are the simplest way to show the relationship of inputs and outputs across multiple transactions.

OXT’s transaction graph is a Directed Acyclic Graph (DAG). DAG graphs are used to map the relationship between two different objects. In the case of bitcoin, the transaction graph maps the relationship between UTXOs and transactions.

OXT Transaction Graph Basics

The transaction graph is best understood through interaction, but before we get started we will introduce some of the functionality of the OXT transaction graph.

1. To access the transaction graph, navigate to the TRANSACTION tab on OXT by imputing or clicking a TxID of interest.
2. Click the TX GRAPH ICON icon on the tool bar on the left side of the screen.

The starting transaction will be displayed. Transactions are presented as vertices (circles) on the graph. Vertices represent a change in the UTXO Set by showing a new relationship between UTXOs consumed and created by a transaction.

Single clicking the transaction will select the transaction, change its colour from blue to green, and display additional options on the toolbar (left side of screen).

The tool bar icons perform the following actions:

Double click the transaction to fully expand all transaction UTXOs. The UTXOs are displayed as “edges” (lines) with arrows indicating if the UTXO is an input (pointing toward the transaction) or output (pointing away from the transaction). The graph will also display the transaction creating the inputs or consuming the outputs. If the output is unspent, an unfilled diamond will be displayed on the end of the UTXO.

Double-clicking or fully expanding a transaction can make your transaction graph noisy and difficult to read. To minimise clutter, we suggest selectively expanding UTXOs. To selectively expand UTXOs, select the transaction and open the Transaction Details window. The transaction inputs and outputs can be selectively expanded by hovering the mouse to the right of the address text and selecting the visible Expand Tx Graph.

On the graph, hovering the mouse over an input or output will display additional information about the object of interest, without the need for expanding the transaction details tab.

OXT’s transaction graph will also help to process some additional information automatically. Transactions and UTXOs will be “weighted” on a relative basis based on their BTC volumes. This can be very helpful for change detection and illustration of “peel chains”, which we will discuss in further detail below.

OXT Peel Chain Transaction Graph Example

A simple transaction graph example is presented below.

1. Navigate to the hyperlink of the transaction page and expand the transaction graph.
2. Select the transaction with a single click.
3. Open the transaction details window by clicking the respective icon on the left toolbar.

4. Double click the starting transaction to expand all inputs and outputs.

5. Zoom out using the mouse scroll wheel and re-orient the graph with the oldest transactions in your preferred order (ie. left to right) by clicking and dragging the transactions in the preferred orientation.

The two outputs present us with a question to answer if we are going to attempt to track the activity of the wallet creating the transaction.

Which output do we follow?

If we apply the different script heuristic (see Part I), we identify the second output as change.

6. Double click the next transaction that spends the second output from the original transaction.

7. Repeat the process for change identification using the heuristics presented in Part I. Expand two more transactions using this process.

Afterwards, the graph should look similar to the image in Fig 2.8 above. To add additional emphasis on the change UTXOs, the change UTXOs can be marked and highlighted in orange using the left toolbar button. A transaction graph showing a series of simple spends from the same wallet is commonly referred to as a “peel chain”.

Chain surveillance firms attempt to frame peel chains as a form of suspicious activity related to “structuring or money laundering.” Though as we described in part 1, approximately 50% of bitcoin transactions are simple spends with 1 input and 2 outputs, in other words entirely normal behaviour.

For our purposes, a peel chain is the simple process of tracking a single wallet’s activity over multiple transactions.

Wallet Fingerprinting and Transaction Graph Interpretation

As you continue interacting with the example peel chain, additional patterns indicative of a consistent wallet fingerprint will become apparent. Including the following:

1. The largest output, shown by OXT’s automatic line weight feature makes the change outputs readily apparent.
2. The change outputs are always paid to P2PKH addresses.
3. The change outputs are always the second of the two outputs.
4. Not shown on the graph, but also worth noting are the consistent transaction version number (2) and lock-time (0) throughout the graph. To see this information, click the transaction ID in the transaction detail window to navigate to the TRANSACTION page. Then select the the TECHNICAL tab to display the transaction version number and lock-time.
5. Expanding the previous or future spending history of this transaction graph will reveal more transactions with the same pattern.

Each of these patterns can be used to describe the behaviour of the observed wallet software. Generalisation of observed wallet behaviour is referred to as wallet fingerprinting, which leverages the following patterns:

1. Input and output address scripts
2. Change UTXO position consistency
3. Version number and lock-time

Combining the above patterns can give an analyst high confidence in their interpretation of change outputs. We confirmed these change interpretations by interacting with the service responsible for this transaction activity. The example peel chain shows activity from a well-known custodial tumbler payout mechanism. Explore the graph source by backtracking from the provided transaction to find coins related to an exchange hack.

In the next section, we will discuss how transaction graph analysis can be improved further by using wallet clustering and monitoring outputs for spends to centralised services.

Wallet Clustering — Common Input Ownership Heuristic

The remaining critical chain analysis tool is referred to as “wallet clustering”. Clustering aggregates addresses based on their co-spending patterns and assumptions about normal wallet software behaviour.

Most bitcoin wallets today are hierarchical deterministic wallets. They generate a single master private key which is used to derive child private/public keys and the associated addresses.

Wallet software typically creates a new address automatically for each received payment (UTXO received). If a single UTXO or address balance is not adequate for making a payment, a wallet will include additional UTXOs/addresses controlled by different private keys/addresses as necessary to spend the desired amount. Most wallets do this automatically without user input.

Because of this normal wallet functionality and bitcoin’s private/public key cryptography backing, an analyst can assume that each address used as an input to a transaction, is controlled by the same private key or wallet software.

The assumption that each input to a transaction is controlled by the same wallet is called the common input ownership heuristic (CIOH) or more simply, the merged input heuristic.

Like all heuristics there are specific scenarios where the CIOH does not hold true. The breakdowns in the CIOH tend to revolve around specially constructed privacy enhancing transactions. We will cover the special scenarios where the CIOH is broken and how OXT handles these exceptions in a later part of this series.

The ANONs — OXT’s Clustering Scheme

Separate addresses that are assumed controlled by the same wallet are usually given a wallet cluster ID by analysis software. Due to bitcoin’s pseudonymous nature a wallet cluster may be representative of a single user or centralized service’s activity.

But without additional information, the wallet remains “anonymous” in that it has not been attributed to any real world entity activity. As a result, OXT gives each new cluster an ANON prefix followed by an index number.

OXT calculates several cluster types of cluster activity including:

• A summary of general activity (balance, number of transactions, active dates, number of addresses)
• Plots of monthly and daily transaction activity, BTC volumes sent and received, UTXOs sent and received, and address stats
• A temporal pattern of cluster activity by day of the week and hours
• A notes section where OXT users can add notes on possible attribution or context for interacting with an unknown cluster during an investigation.

OXT’s general cluster stats are viewable without an account. However, with a free OXT account (no email required), a user can access additional features. When logged in, cluster statistics including daily balance, daily volumes, transaction lists, address lists, and more are accessible.

Cluster Attribution — ANON to Labeled Service

Using the CIOH, OXT will keep track of a wallet cluster’s on-chain activity. To attribute the wallet cluster to a specific service requires interacting with the service.

An analyst can create an account with a service and send BTC to a deposit address provided by the service. From there, the analyst can monitor the spending of their deposit UTXO. When spent the analyst can attribute the address and its co-spent addresses to the corresponding cluster ID.

Alternatively, an analyst can use opensource intelligence techniques to search for publicly available information posted by service users. Deposit and withdrawal addresses can be commonly found in social media posts. This publicly available data can also be used to attribute a wallet cluster to a centralised service.

Applying External Transaction Data To Change Detection

Additional information including wallet fingerprinting, output spending timing, and output clustering can be applied to change detection interpretation.

The most damaging to transaction privacy is when a simple spend is made to a wallet cluster that has been identified as a centralised service.

When a simple spend is made to a centralised service, all change detection ambiguity is lost. The output to the centralised service is clearly the payment. The only remaining output is the obvious change output. An example from the future spending of the peel chain example above is shown below.

The most crucial aspect of the CIOH isn’t necessarily how it is used to target individual user privacy, but how wallet clustering among centralised services negatively and significantly effects the privacy of the the bitcoin network transaction graph.

A significant portion of bitcoin’s economic activity is immediately from or to a centralised service which has a major centralisation effect on the overall bitcoin network transaction graph.

Review

In Parts 1 and 2 we introduced the fundamentals of chain analysis including change detection, transaction graph analysis, and the common input ownership heuristic.

Change detection consists of a series of heuristics used to determine a likely transaction change output. A transaction graph analysis can quickly and visually illustrate these heuristic interpretations to track the activity of a single user. Additional data including wallet clustering by the common input ownership heuristic can be used to improve confidence in change detection. Attributing a wallet cluster to a user or centralised service activity requires additional off chain data tying a suspect address and spending activity to the noted service.

In the following section we will introduce the concepts used to defeat chain analysis and make user tracking more difficult.

Part 3 covers core concepts of improving bitcoin’s privacy including:

1. Randomised wallet fingerprinting for defeating change detection.
2. UTXO flows and the fundamental link between inputs and outputs.
3. How equal output coinjoins address the issue of deterministic flows.
4. Transaction entropy
5. How payjoin defeats the common input ownership heuristic

Part 4 discusses:

1. Analyses needing a “starting point”
2. The privacy implications of sending and receiving payments
3. How existing privacy techniques can mitigate many of the issues discussed throughout the guide.

Understanding Bitcoin Privacy with OXT — Part 2/4 was originally published in OXT Research on Medium, where people are continuing the conversation by highlighting and responding to this story.

Chain Analysis And Transaction Privacy

Introduction

Awareness of Bitcoin’s value proposition for censorship resistant payments took off in 2011 with the launch of Silk Road and the rescue of the otherwise donation starved Wikileaks.

Simultaneously a dangerous and inaccurate narrative surrounding bitcoin transaction privacy took off: “anonymous” payments.

This perception was never true and largely due to a lack of understanding of bitcoin’s underlying functionality. Further, almost no one was watching the blockchain in 2011. But the blockchain is forever.

Today law enforcement’s access to chain analytic tools has aided in many high profile take-downs. Chain surveillance firms clamor for first publication of blog posts on the latest “crime” using bitcoin for payment. The mainstays of old media are running headlines on bitcoin’s traceability.

Traceability is mainstream.

The reality of bitcoin privacy, and what users are capable of when using bitcoin to make payments, lies somewhere between perfectly anonymous and perfectly traceable.

Most tracking techniques are reliant on heuristics and evaluating the flow of bitcoin. Without fundamental privacy enhancements at the protocol level, these techniques must be undermined at the application layer.

Early in bitcoin’s history, randomized wallet fingerprinting was used to defeat analytic heuristics. Tools such as custodial tumblers were used to defeat financial flow analyses at the risk of loss of funds. Today coinjoins and collaborative transactions allow for reasonable spending privacy with enhanced security over previous methods. However, much work remains to be done in automating privacy enhancements at the application layer.

We consider education among the remaining work to aid users in obtaining a basic level of financial privacy they are typically afforded by the legacy financial network. This is our main motivation for creating this documentation. In this guide we will cover the following:

1. What “traceable” bitcoin really means including examples.
2. Defensive measures users can take to defeat tracking and why they work.
3. Practical considerations for users sending and receiving payments.

PROBLEM STATEMENT — PSEUDONYMOUS BITCOIN

Bitcoin transaction activity is pseudonymous, not anonymous. A user’s true name and personal identification information (PII) is not included in the Bitcoin protocol. This provides a very basic level of privacy, as transaction activity must be attributed to an individual.

However, bitcoin transactions are made for transparent amounts to transparent addresses. Addresses are pseudonyms that represent an actual user’s activity, or more specifically, a private key’s activity.

Bitcoin transactions are broadcast to the bitcoin network, and archived on the bitcoin ledger. The ledger, and any transactions included in the ledger, are viewable to anyone running a bitcoin node or with access to a web based blockchain explorer.

The transparency of this public information allows for an unprecedented ease of information access that is not possible with the traditional financial system.

Users can query a blockchain explorer through a web browser and observe the entire bitcoin network’s past transaction history. They can easily track the flows of bitcoin across multiple transactions.

Broadly, this practice has become synonymous with the terms traceability and chain analysis.

The most common form of chain analysis is focused on identification of transaction “change” outputs. The process is based on a series of heuristics that can be used to follow a user’s activity over multiple transactions.

If this on-chain activity leads to an identified economic entity’s wallet cluster, investigators may be able to obtain user PII associated with the observed transaction activity.

From here we can glean two critical issues that can be used to attack a user privacy:

1. “Change” outputs can be used to track a users activity on the blockchain.

2. The intersection of this activity with entities that obtain PII links observed blockchain activity with a possible real identity.

While item 2 is a critical part of what turns chain analysis into real world enforcement, this documentation will focus specifically on mitigation of the on-chain tracking.

Heuristics

Heuristics are rules of thumb used to make decisions under uncertain conditions. They are often based on practical shortcuts. Being shortcuts heuristics are not 100% accurate.

Much of traditional chain analysis is based on heuristics. The primary heuristics have to do with “change detection” in simple spends and the clustering of separate addresses by the common input ownership heuristic.

In isolation, these heuristics can be misleading and inaccurate. But when combined with additional transaction patterns or external data such as wallet cluster labeling, the short comings of these heuristics become less damaging to attempted tracking.

Unspent Transaction Outputs (UTXOs)

Bitcoin transactions are records of the flows of bitcoin between addresses.

Unspent transaction outputs (UTXOs) are “pieces of bitcoin” that are used to construct transactions. Transaction structure can be divided into inputs and outputs.

A user constructs a transaction by designating a payment address(es) and payment amount(s). These will be the outputs of the newly constructed transaction.

Typically wallet software will complete the transaction by algorithmically including UTXOs from previous transactions as inputs to the new transaction.

There is a difference between an address and a UTXO. UTXOs are “pieces of bitcoin” paid to an address. The simplest way to visualize the difference is to understand that an address can receive multiple UTXOs, a process detrimental to privacy referred to as “address reuse”.

Example Transactions

There are several common categories of bitcoin transactions. These categories are inferred based on a transactions input and output profile along with our experience and observed cluster labeling. Examples of the major transaction types are provided below.

Simple Send

Simple spends are some of the most common transaction types and make up roughly 50% of bitcoin transactions in recent blocks (Source: transactionfee.info).

These transaction types are evidence of typical user behavior, where a user makes a payment and receives a change output.

Traits:
- Number of Inputs: 1 (or more)
- Number of Outputs: 2
- Common Interpretation: 1 payment output, 1 change output

Sweep

“Sweeps” spend the entirety of a single UTXO to a new address.

Traits:
- Number of Inputs: 1
- Number of Outputs: 1
- Common Interpretation: Possible self-transfer

Consolidation Spend

Consolidation transactions combine multiple UTXOs into a single UTXO. These are rarely “true payments” because a normal payment has a change output.

Traits:
- Number of Inputs: >1
- Number of Outputs: 1
- Common Interpretation: Possible self-transfer

Batch Spend

Batch spends are most likely performed by exchanges and include 1 or more inputs and many outputs. These transactions aim to save on miner fees by making as many payments as possible in a single transaction.

Traits:
- Number of Inputs: ≥1
- Number of Outputs: MANY
- Common Interpretation: Large economic activity, likely exchange

Multi-party Transactions (Coinjoin)

Multi-party transactions involve collaboration between many users to perform a single transaction that improves participant privacy. These transactions are easily identified by their equal output amounts.

Traits:
- Number of Inputs: MANY
- Number of Outputs: MANY
- Output Profile: Number of identical outputs is a proxy for number of participants.

Change Detection — Simple Spend Interpretations

In this section we are going to introduce transaction interpretations for simple spends (1 input, 2 outputs). This section will focus on the most common interpretation of these transactions, where one output is interpreted as a payment and the remaining output is interpreted as change back to the original wallet. A complete list of interpretations under this model are presented in Part III. The goal of this section is to familiarize the reader with the heuristics used to evaluate simple spends and detect a change output.

When observing a single transaction in isolation, we are presented with a limited amount of data that is included within the transaction. We refer to this information as internal transaction data.

Internal transaction data is limited to the following:

• amounts (input, output, miner fees)
• input address script type
• output address script type
• transaction version number
• transaction locktime
• replace by fee signalling

Change Detection

Due to miner fees, a normal bitcoin payment always requires spending a larger output amount than the intended payment amount.

When a single UTXO for a larger amount than the intended payment amount is consumed, the user will receive a change UTXO for the remainder back to an address generated by their wallet’s private key.

Much of traditional chain analysis is based on detecting this change output. If a change output can be successfully detected, a single user’s activity can be tracked across a series of transactions.

In this section we will detect change outputs based on internal transaction data. The heuristics are presented roughly in the order of decreasing effectiveness accuracy. Examples will be presented and annotated screenshots shown for aiding users in visualizing these concepts.

Address Reuse

Addresses are created by a single private key. Multiple uses of the same address are signs of activity of the same private key.

In a simple spend, if one output is to a new address, and the remaining output is to the same address as the input address, we know that the reused address is the change output.

Today, most bitcoin wallets will automatically generate a new address for receiving change outputs. However, a wallet can be configured to receive change to the same address as the transaction input. This behavior is typically indicative of centralized service wallet activities or old versions of the bitcoin core wallet.

Round Number Payment Heuristic

When a user initiates a payment, they input the payment destination (address), payment amount, and a network transaction fee into their wallet software. The wallet software will select input UTXOs and generate the change output (if there is one).

The change amount in a simple spend is calculated as follows:

input amount - payment amount - tx size (in vbytes) * network fee rate (in sat/vbyte)

It’s difficult for a user to generate a change output for a “round number amount” on purpose. In a simple spend, the round number output is the likely payment which makes the remaining output the change output.

Different Script Type Heuristic

There are several bitcoin address script types. Readers will be most familiar with the following script types:

• Pay to pubkey hash (P2PKH): Addresses starting with a 1
• Pay to script script hash (P2SH): Addresses starting with a 3
• Native Segwit (version 0)(bech32): Addresses starting with bc1q

For a given input script type, if one output is to the same type as the input and the remaining output is to a new address script type, the output to the new address script type is the likely payment. Which makes the output to the same address address script type the likely change output.

In other words, an output to a different script type is the likely payment output. This heuristic can also be combined with the round number payment heuristic.

Largest Output Amount Heuristic

Another simple heuristic, assumes that the largest output amount is the likely change output. This is one of the weakest heuristics, particularly when taken in isolation, but as we will discuss in Part 2, this heuristic can be helpful in a transaction graph analysis.

Review And Preview

In this section we introduced many of the basic concepts around bitcoin transaction privacy. Pseudonymous bitcoin provides a basic level of privacy that is not directly associated with personal identifiable information.

However, the openness of the bitcoin protocol allows for the tracking of bitcoin flows. This concept is broadly referred to as “chain analysis”. A core focus of chain analysis focuses on detection of change outputs by making use of several heuristics. If successful, these heuristics allow for tracking a single users activity over multiple transactions.

Part 2 will introduce core concepts of chain analysis such as:

1. External transaction data, which can be used to weaken transaction privacy.
2. Transaction graph analysis, a main tool for tracking the flow of bitcoin over multiple transactions.
3. The common input ownership heuristic, also known as “wallet clustering” and its implication on the bitcoin network.
4. This section also includes a walk-through and examples of OXTs transaction graph tool and wallet clustering scheme.

Part 3 cover core concepts of improving bitcoin’s privacy including:

1. Randomized wallet fingerprinting for defeating change detection.
2. UTXO flows and the fundamental link between inputs and outputs.
3. How equal output coinjoins address the issue of deterministic flows.
4. Transaction entropy
5. How payjoin defeats the common input ownership heuristic

Part 4 discusses:

1. Analyses needing a “starting point”
2. The privacy implications of sending and receiving payments
3. How existing privacy techniques can mitigate many of the issues discussed throughout the guide.

Understanding Bitcoin Privacy with OXT — Part 1/4 was originally published in OXT Research on Medium, where people are continuing the conversation by highlighting and responding to this story.