One of the less intuitively understood properties of Bitcoin is the concept of how bitcoin values are stored in a wallet. Most people — even some of those who use Bitcoin regularly — believe that when you remit bitcoins to a Bitcoin address, the balance of that address is simply updated to reflect the new transaction. However Bitcoin operates in an entirely different manner; as a result, there is an unfortunate side effect that you need to know about, because it increases your BTC transaction costs.

If you have ever looked at a bank account statement, you will have noticed that it contains the following items:

• Balance at the start of the reported period
• A list of debit (spend) and credit (receive) transactions
• Balance at the end of the reported period

Because this format of the statement is so easy to view and understand, you may be tempted to think that your Bitcoin wallet stores information exactly the same way. That is why you will probably be surprised to learn that there is no record of the ‘total balance’ in your Bitcoin wallet.

The blockchain keeps a permanent record of all transactions directed towards any given Bitcoin address. Each of these is called unspent output (UTXO in Bitcoin parlance). When your wallet software tells you that you have a balance of e.g 1.43517 BTC, it does not read that value from any file or blockchain entry. It actually has to scan the whole blockchain and sum all UTXOs that point towards the particular address. Only then it can report to you that the address in question has a balance of 1.43517 BTC.

The outcome of this operation may be all the same to you, but you need to know how wallet balances are derived, as it also relates to the way bitcoins are spent.

Another thing that people usually disregard are the details of a bitcoin spend transaction. Most folks will assume that when they spend coins from a given address, the bitcoin wallet just writes a check for the spent amount plus the transaction fees, and then updates the balance of the wallet as required. However what actually happens ‘under the hood’ of a simple spend transaction is quite more sophisticated.

Each Bitcoin transaction has a minimum of two explicitly defined and one implied output. Say you have 1.0005 BTC in your wallet; you want to send 0.5 BTC to a friend, and you choose a transaction fee of 0.0005 BTC 1‘Choose’ is perhaps the wrong word for this. Most wallets have means of determining the present going rates of transactions and will offer you a value that guarantees reasonably fast inclusion on the ledger. But you generally do have the choice to adjust the size of the fee or input a value entirely by choice..

When you press the ‘Send’ button, your wallet performs the following set of operations:

• Using the original UTXO as input, create one new UTXO for the amount of 0.5 BTC, directed towards the address of the recipient
• Using the original UTXO as input, create another new UTXO for the amount of 0.5 BTC, directed towards:
  • either the address belonging to the original UTXO you are spending, or
  • another address belonging to you, called a ‘change address’

The two newly created 0.5 BTC UTXOs are clearly visible in this transaction 2What about the transaction fee? Your wallet cannot create an unspent output to cover the cost of the network fee, because the address of the recipient of the fee is not yet known. That is why the extra 0.0005 BTC is kept as an implied output: the difference between the original UTXO and the newly created UTXOs will be claimed by the miner who finds the block that includes your transaction. Future queries by your wallet software will see that the original UTXO is spent, but that it refers to the new UTXO directed to your own address; the wallet will tell you that 0.5 BTC is available to spend.

Imagine now that you need to spend more Bitcoin than you have in any of the unspent outputs assigned to the source wallet address you want to use. In such cases, your wallet software is programmed to find two (or more) unspent outputs which are the oldest and whose sum is slightly larger than the amount you want to spend (BTC transaction costs included).

The problem is that the wallet then needs to create separate UTXO operations to perform the complete transaction, and each of these operations takes up a number of bytes. Transaction fees are calculated per byte, regardless of the amount of Bitcoin transferred.

The side effect of this design decision becomes painfully clear when you receive regularly small payments (e.g. daily or weekly NiceHash payouts) but want to spend a larger Bitcoin amount in a single payment. Here is what recently happened when I tried to spend some of my payouts:

A 930 bytes long transaction (median size is about 260 bytes) that cost me 0.00225991 BTC (about €7.90 at going rate, dammit)… just because of ‘wallet fragmentation’. Had I used a single UTXO, BTC transaction costs would have been about 3.5 times smaller. Also bear in mind that this transaction has a single output because I transferred the bitcoins to an exchange. If this transaction required change, the BTC transaction costs would be higher still, because there would have been a second output towards my change address.

The moral of the story — if there can be such a thing — is that you should be planning ahead and should generally avoid taking multiple small incoming Bitcoin transactions if you have the chance to replace them with a smaller number of larger transactions.

A possible solution would be to monitor the network for periods when fees are lower (https://bitcoinfees.21.co/ is a very helpful tool for this) and consolidate your UTXOs into larger chunks to offset the cost of future transactions. You could also try to specify lower fees and rely on the ‘Bitcoins Destroyed’ mechanism to push them through the ledger eventually, but you risk having your coins stuck in the network for days or weeks unless you are willing to pay more to speed up a stale transaction.

 

What are your experiences with wallet fragmentation? Have you found a solution to this problem? Let me know in the comments below.