An Overview of Bitcoin Transaction Types
Examples of Common Patterns in Analyzing Bitcoin Wallets
This article demonstrates common patterns found in the Bitcoin network as funds are moved around between various parties, including: payments, consolidations, deposits, parking, and obfuscation through mixing/tumbling. Simple, online tools like Blockchain.info will be used for all examples to make them easily accessible.
A few months ago I did an interview for VICE on HBO about the lack of anonymity of Bitcoin, based on a article I had written tracing back the GRU wallets used by Russian hackers indicted as part of Mueller’s investigation.
Since then I’ve been asked in a myriad of ways by interested readers in how to better understand what they’re seeing when they follow the trail I laid out starting at this address: 1LQv8aKtQoiY5M5zkaG8RWL7LMwNzVaVqR.
To that end I’d like to introduce readers to the common patterns that they might see when looking through the Bitcoin blockchain. The material presented starts with simple use cases (like single payments) and moves to more complex examples (mixing or consolidation) as we go.
A Simple Payment
Our first example is a very simple payment using the standard transaction output common to Bitcoin, in this case a payment to BitVPN.
In the transaction above we see the sending address on the left-hand side sending two separate amounts of Bitcoin to two separate addresses.
Sender: 1MYQzejdwhiU83qy4SsLKcm7CwV5XxVFRn (10.396157 BTC)
Recipient: 13ov4UBJYJQBC1Tv5vEvijShn2vWS3vPrJ (0.09120588 BTC)
Change: 1MS4KRpKakzTEUFzcU9PHCbs2f1u9a1aL4 (10.30490112 BTC)
The sender address is exactly what it sounds like, the address where the transaction originated. The recipient, likewise, is the party receiving a payment.
The change address, on the other hand, is not intuitive to new users of Bitcoin until they understand that every time they send a transaction their Bitcoin wallet software also makes an entirely new address and forwards any remaining funds to it, and stops using the original address.
About Change Addresses
The architecture of Bitcoin requires that the entire output from a previous transaction held in an address MUST be spent in any subsequent transaction.
In other words: if an address received 2.5 BTC in the morning, and 1.5 BTC in the afternoon, then there is a total of 4 BTC in unspent outputs assigned to that address.
If the owner decides to spend 0.5 BTC from that address to pay for something, then they ALSO need to send the remaining 3.5 BTC to another address as part of the same transaction. Forwarding the remainder to yourself under a new address in this manner is the purpose of a “change address” — it’s like the change you get from a cashier in a grocery checkout aisle after breaking a $20 bill to buy $5 worth of milk.
Here’s a helpful visualization from Blockchain.info:
Can You Send Change to the Original Address?
Absolutely.
It’s just frowned upon and the default behavior of most wallets it to generate new addresses for change rather than re-use the originating one.
Why? Privacy and Security.
In the first case, new addresses on both the sender and receiver side make tracing transfers a bit more difficult (though by no means impossible).
In the second, the concern is that the same address being re-used would make any future attack on the ECDSA algorithm able to discover your private key through the multiple uses of your public key on the same address.
What About Fees?
If you do the math on the tree visualization above versus the raw amounts I posted for each address you’ll see a mismatch in the amounts:
The tree visualization shows the origin starting with 10.396107 BTC, while the earlier section showed 10.396157 BTC.
The discrepancy is 0.00005 BTC, which was the standard transaction fee at the time.
If you review the transaction associated with the sender -> recipient address you’ll see the fee explicitly listed:
Why have fees at all?
Fees are small amounts of Bitcoin paid to the miners to incentivize them to include your transaction in a block they’re working on. It’s in the miners’ best interests to prioritize high-paying transactions at the top of the stack, especially when block sizes are close to their size limits or network congestion is high.
Simple Payment Chains
The transaction structure described above represents a simple, singular payment with the change moving to a new address.
A series of such payments, viewed over time, looks like a chain connected by the change addresses.
In the case of the example of the wallet you can discover about twenty (20) distinct links following the simply payment transaction model before things get complicated.
Transfers (Full Payment)
The simplest transaction of all is one in which the full funds from one address are transferred to another address (minus fees), thus not requiring a change address at all.
As you can see in the example above the entire transaction contains only one input and one output.
Multiple Payments (Batches)
Another common example, such as this one from Xapo.com, will have multiple recipients (along with a change address).
Notice how a single input can have multiple outputs?
Batch payments make transaction fees more affordable, as you pay for the amount of bytes consumed in creating the transaction, rather than multiplying the minimum fee over many separate transactions.
Notice how the last address in the list (the change address) is unspent. At the time the article was written this was the last transaction sent to the 37sL... address and the 0.18 BTC had not been used in a subsequent transaction.
Thus, the unspent transaction (or UXTO) can be used as the input for a future transaction from that address.
Consolidation (Multiple Inputs)
The reverse of this is receiving multiple inputs to a single address in a given transaction.
In the example above the BitVPN address is receiving funds from two separate addresses, consolidated into a single payment.
A consolidation of funds does not imply the same entity owned all the input addresses with their associated private key signing. Instead, it implies that all entities contributing to the transaction with their inputs agreed on the common cause.
In other words, it would be incorrect to say all the inputs were from the same wallet, but it would be correct to say that the inputs bore a relationship (even if transitory in nature).
For instance: it could be a mining pool or cryptocurrency exchange that owned many addresses and wallets with separate private keys programatically creating a transaction to bring funds together.
Complex (Multiple Inputs and Outputs)
Here’s an example of a cryptocurrency exchange funding a customer’s new address:
All four of the inputs lead back to a cryptocurrency exchange, and if you follow the change address 1JXF... it also loops back into the same cryptocurrency exchange.
The 1KgU...address, on the other hand, is the actual customer withdrawal address and leads to a trail of simple payments made over time.
Parking (Unspent Payment)
When a Bitcoin user creates a new address and puts a portion of funds in it, but keeps using the remainder, you could consider the stored, unused funds parked.
Notice how the structure is identical to a simple payment described at the beginning of the article, but that the 1J8k... address is Unspent.
A great example of parked funds (or possible abandoned) are the alleged Satoshi Nakomoto addresses from the early Bitcoin mining period, such as this one:
Mixing and Tumbling
The easiest way to obfuscate the trail of Bitcoin transactions is to use a mixing/tumbling service: a process that takes a certain amount of your Bitcoin, extracts a fee, and then outputs your change across multiple addresses over a given time period at the same time as other users’ funds are being distributed as well.
This shotgun approach to dispersing funds makes it difficulty to identify the relationship between deposits and withdrawals.
HelixMixer, for example, will take up to five output addresses to send your “clean” coins to.
If you looked at one of their historical outputs you’d see something like this:
Spread out minutes, hours, or days over several addresses and being composed of many inputs (some of which are also other people laundering their coins at the same time) makes analyzing the original source for mixers incredibly difficult.
On the other hand, since these are not native functions of the Bitcoin network it means that this is just a server sitting in a closet somewhere that can be subpoena’d, raided, or co-opted by governments.
Mining Pool Outputs
Another common pattern you might find are mining pool outputs, like those from SlushPool or AntPool. These look a lot like mixers/tumblers but in reverse: there are an incredible number of outputs spread out in a “dusty” fashion (having smaller output amounts).
This example from SlushPool has dozens upon dozens of outputs.
Since several pools support “renting” hashpower, and that same rental can be paid for initially in Bitcoin, it can be said that mining pools can also make for very effective mixing/tumbling methods since unclean coins can be laundered through the pool outputs over time to target addresses.
Summary
We covered a lot of different transaction types, including consolidations in which two or more addresses might merge their funds, as well as common cases for laundering coins.
While the examples above are all basic they comprise the majority of transaction types you’ll see in the Bitcoin blockchain.
