An Investigation into Privacy Preserving Transactions I

An Investigation into Privacy Preserving Transactions I

Disclaimer: Your capital is at risk. This is not investment advice.

Exploring CoinMixers from an on-chain perspective

Our previous article introduced the concept of an unspent transaction output, or UTXO, and how it relates to Transaction Value.

In this article, we will take a deeper dive into CoinMixers and expose how they operate from an on-chain perspective, as well as detailing how this can lead to transaction value on Bitcoin being misreported. A subsequent article will then investigate CoinJoin transactions through a similar lens.

At ByteTree, we have seen a dramatic increase in not-economically-useful-transactions, or NEUF, and we identified that these transactions are consistent with UTXO structures associated with privacy-preserving protocols (PPP), such as Coinmixers and CoinJoin. The use of privacy-preserving techniques enables users that value their privacy to maintain a degree of anonymity while transacting over the Bitcoin Network. However, we must also acknowledge that a fraction, all be it small, of privacy traffic is relating criminal actions; money laundering, exchange hacks, payment for illicit goods and services – I expect you are familiar with the story.

Privacy transactions like CoinMixers are a difficult concept to grasp. In this article we will simplify the data by focusing on the two main CoinMixer traffic types; withdrawals, and consolidations.

The main aim of a PPP is to mask the original source of funds. In the case of CoinMixers, this comes from mixing participants’ funds into an arbitrary ‘pool’. Upon withdrawal, the protocol aims to create a disconnect between a participant’s initial deposit and the funds they withdraw, which is achieved by sending another participant’s funds in its place.

Surely these are easy to identify?

Not exactly. Mixers muddy the chain of transactions by aggregating participants’ crypto together, creating a ‘pool’ which enables users to ‘hide in the masses’. A pool is a single entity, and when a user wishes to withdraw funds, the idea is that the funds they receive are not 100% linked to the funds they initially deposited.

The use of a pool does not come without its risks. Once the third party mixer acquires a user’s funds, they have no obligation to give it back and could disappear with the pooled funds as they are in control of the private keys. In the case that you do in fact manage to retain the funds paid into the pool, you may receive funds that had previously been associated with criminal activities and therefore have ‘tainted’ your coins from use in regulated environments.

Below we discuss the two main signatures that relate to CoinMixers and demonstrate how these affect the transaction value calculation.

Type 1 - Withdrawal Traffic

Source: Blockchain.com. Example of a classic Mixer withdrawal transaction.
Source: Blockchain.com. Example of a classic Mixer withdrawal transaction.

Through our previous method of calculating the transaction value, we would have included the ‘change’ address in our calculation since this is the largest balance sent within the transaction; the old transaction value would be 2.8744898 BTC. With our updated method, only the smaller value addresses are identified because the ‘change’ address is not ‘real’ value. Instead, it is a repayment of the pool back to the pool’s origination address. This would make the updated transaction value 0.01518921 BTC.

The example above shows a Mixer withdrawal transaction. At ByteTree, we noticed that identifying transactions with a single input, multiple outputs, and ‘change’ is the first step to detecting these traffic signatures. If there is a peelchain in the transaction, then it is likely to be a mixing protocol (following a peelchain will likely keep you on the path of an entity).

A peelchain occurs when the same address appears on both the input and output sides, the reappearing address is called a ‘change’ address. From an on-chain perspective ‘peeling’ is recognisable by the movement of the ‘change’ address. With each transaction, the ‘change’ address will get smaller, as more ‘peeling’ occurs. As we cover later on, a consolidation transaction is needed to top up the balance of the ‘change’ address.

Source: ByteTree. A simple view of a peelchain.
Source: ByteTree. A simple view of a peelchain.

We have adapted our algorithm to identify the ‘useful-transaction-output’ and not the NEUF, which in most cases, is the largest output value. In a practical sense, this means that the ‘change’ (which goes back to the original input address) is disregarded, as this is the NEUF.

After detecting the NEUF, our algorithm sums the rest of the outputs to find the useful transaction value. The NEUF is then included in our, soon to be released, ‘Legacy spend’ number. ‘Legacy spend’ includes both the privacy and batch transactions to demonstrate the difference between the prior and updated methodology.

Type 2 - Consolidation Traffic

Source: Blockchain.com. A classic consolidation transaction.
Source: Blockchain.com. A classic consolidation transaction.

The second traffic type that we identified is called a pool consolidation signature. Typically, a consolidation has more than two inputs, with an output address that is the same as the largest input address by value.

Previously, our algorithm would have summed up both the consolidation and the partipicant values; this would have made a total transaction value of 5,460.10559 BTC. With the new updates, only the participant address is counted, meaning that the actual transaction value is 0.57 BTC.

In the case of the above image, the consolidation traffic symbolises a mixing pool growing in value. The top input is the mixing pool address, and the second address is the participant. As we can see from the output address, the participant’s crypto has been aggregated into the mixing pool successfully.

Source: ByteTree. A simple view of a consolidation transaction.
Source: ByteTree. A simple view of a consolidation transaction.

So why did this create a data issue?

The issue arises as a result of the algorithm reading the whole output as a transaction. In the case of consolidation traffic, just the smaller inputs are of value. We have updated our tracking code to take a sum of the values that are not associated with the largest balance address and added this to our transaction value data.

For more information on privacy-preserving protocols, please see the resource list below.


Further Resources