How does the bitcoin source code define its 21 million cap?
Many of bitcoin’s staunchest critics have expressed doubt about its 21 million cap, but perhaps the most mindless criticism relates…,
One of the more challenging aspects of understanding bitcoin is the paradigm shift in how transaction processing works, which often causes quite a shock for users who encounter high fees for the first time. In this post, we will attempt to shed some light on the often misunderstood world of bitcoin transaction fees, while sharing some best practices on how users can learn to save on fees when transacting directly on the bitcoin network.
The post is broken into 3 parts:
The first step in understanding bitcoin transaction fees is to clarify the difference in how fees are calculated in bitcoin versus the legacy financial system. These two markets for value transfer are fundamentally different, so how they respond to the market and price themselves are also based on different factors. Trying to apply habits or map experiences from one market to another can be a big source of pain for new bitcoin users.
The core of this difference is understanding what you are paying for. For the purposes of this comparison, we’ll focus mostly on credit card transactions as they are the system most familiar to day-to-day consumers.
In the case of credit card transactions, and even wire transfers, the three primary resources demanded, and therefore sources of cost overhead, are:
For credit cards, merchants often pay anywhere from 1-3% in transaction fees for these services. There are two characteristics of note for our comparison with bitcoin:
The situation in bitcoin is very different. There are no point-of-sale costs, administrative costs, liquidity constraints, and almost no counterparty risk. So what are you paying for? Without getting into too much of the technical details, bitcoin processes transactions by propagating them around the network via nodes, getting them included into a block by a miner, and sharing, verifying, and storing the resultant blocks on every full node.
The costs here are all associated with data: storing data and verifying cryptographic signatures. The more data you want other participants in the network to be responsible for, the more you have to pay for the privilege. This would be similar to having to pay more for an unlimited data plan if you want to stream HD movies all day from your phone vs. just checking email. Another analogy is paying by weight to ship a package: you pay more for faster delivery, for heavier items, and if you’re shipping during peak periods (like Christmas).
Simplistically, bitcoin allows for price discrimination and priority processing, which can also allow for, in economic terms, a more elastic demand curve: someone who needs to have a transaction processed faster pays higher fees, which in turn helps subsidize transaction processing for everyone else.
A final characteristic to keep in mind about bitcoin transactions is that one of the ways the protocol helps limit the data costs imposed on all participants of the network (and limit the free-rider problem) is by capping the total available block space, i.e. the total transaction data allowed per block (~1MB, and up to 4MB depending on the types of transactions, but that’s beyond the scope of this post).
As you can see above, this means that as demand for transaction processing increases, the amount of relative available block space decreases.
The implications of this type of fee market create some interesting dynamics. Besides the idea that you can pay for priority (and these higher payments actually subsidize the rest of the network), the most important thing with regard to fees is that rather than pay for the amount of value transacted, which is what most people expect, you pay for how much data you’re sending.
This means that a $100 transaction could be more expensive to send than a $1m one. For a concrete example, consider this bitcoin transaction sent in April 2020 where a total value of $1.1bn was sent in a single transaction, paying a fee of 0.0001BTC or roughly only $0.68 at the time.
In order to understand how to make transactions cheaper to send, we need to understand what data is being sent and how much control we have to decrease this.
A bitcoin transaction can be thought of as being made up of roughly 3 parts:
At its simplest, a singlesig transaction (the most common in bitcoin today), with one input and one output is going to be <200 bytes of data (1MB, the upper limit for a bitcoin block, is 1 million bytes). Assuming a fee of 10 satoshis per byte, the fee paid is going to be around 3,000 satoshis. Not too bad.
Each additional output is going to add ~34 bytes. Most transactions have two outputs: outgoing to the destination and change back to the sender’s wallet.
This is a difference of ~16%. For such a simple transaction, single output transactions are a way to decrease relative costs, but as transactions get more complicated, these savings make up a smaller percentage of the impact. Inputs are where things get a little more complex and where the greatest opportunities for savings often are.
The value of your inputs need to add up to the total you’re trying to send. Inputs are composed of units of your previously received bitcoin. These are known as Unspent Transaction Outputs, or UTXOs.
Let’s say I have an address that I send 0.1 BTC to every month. At the end of a year, my balance is 1.2BTC made up of 12 UTXOs of 0.1 bitcoin each. Now let’s say I want to send 1 BTC. Unfortunately, my wallet doesn’t have a single UTXO big enough to cover that amount on its own. Instead, I need to use 11 of my 12 inputs to add up to enough to cover the 1BTC output and the fees.
The data for inputs is slightly bigger than outputs, ~41 bytes, but inputs also require signatures to validate them and these are ~73 bytes each. So for each input we have to add ~114 bytes.
For 11 inputs the cost would look like this: 30 (metadata) + 11*114 (11 inputs) + 2*34 (two outputs) = 1,352 bytes. At 10 sats/byte, 1,352 bytes would cost 13,520 satoshis.
For an example of how far this can go, take a look at the largest transaction ever sent in the bitcoin blockchain back in 2015: 5,568 inputs of 0.00001 BTC each and 1 output receiving 0.05569 BTC, totaling 1MB of data. This meant that a single transaction took up the entire block.
Multisignature (aka multisig) addresses take this one step further. For a refresher on what multisig is and how it works conceptually, check out one of our previous articles.
What is relevant to our discussion is that multisig inputs require much more data (for all intents and purposes, an output to a multisig address, though, is indistinguishable from normal addresses).
A standard singlesig input only requires a signature and some metadata that tells a node where to find and verify a given unspent transaction output that is being spent:
As a stark comparison, a multisig input requires:
So for our example of a 2-of-3 multisignature address, each additional input, which in the previous example only added ~114 bytes per input, will add ~293 bytes, a 157% increase. In our example 11-input transaction, this means that rather than 1,254 bytes for the inputs, we will have to pay the bitcoin network to process 3,223 bytes of data, almost a 3x difference.
For 11 inputs in multisig, the cost would look like this: 30 (metadata) + 11*293 (11 inputs) + 2*34 (two outputs) = 3,321 bytes. At 10 sats/byte, 3,321 bytes would cost 33,210 satoshis.
33,210 satoshis is more than double the amount for the equivalent singlesig transaction. In a busier network, it would be conceivable for the fee rates we’re assuming to double to 20 sats/byte for reliable confirmation. At $10k per bitcoin, that’s about $6.50 vs. $2.95, but at $50k per bitcoin, those numbers jump to $32.50 for an 11-input multisig transaction vs. $14.75 for an 11-input singlesig transaction.
These numbers definitely feel quite jarring ($32.50 to send a single transaction?!). As noted in section one of this post, however, the bitcoin protocol creates a fee market. While this can result in higher fees, it also encourages users, whether large exchanges or individual users, to make responsible use of network resources when possible and to follow best practices.
So let’s talk about some of the strategies to reduce fees.
The most straightforward solution is to take advantage of the variable fee rate setting in your wallet. Unchained vaults provide this option when you’re authoring transactions. If you don’t need a transaction to be settled within an hour or two, decrease the fee rate.
It is important however when adjusting the rate to set this to a reasonable level. As we’ve seen, if you have many inputs, even a modestly high fee rate can result in a very large absolute fee amount. On the other hand, if the network is very congested a fee that is too low may cause your transaction to become stuck. Most nodes on the network will end up dropping a transaction that hasn’t been confirmed in a block after three days.
We recommend using a resource like mempool.space for checking the state of the network and determining an ideal fee. Their website provides information on low, medium, and high priority fee rates (low means a transaction takes longer to be confirmed) as well as what rates are currently being purged (i.e. they will likely get stuck and you will eventually need to re-broadcast with a higher fee).
If fewer people are trying to send transactions, then the competition for space in that 1MB block is lower and so lower fee transactions are more likely to be mined. Generally, weekends tend to see less usage, so that can be a good time to send any non-urgent transactions. Mempool.space also provides graphs showing the number of transactions waiting to be confirmed over time organized by fee rate. Try and aim for spends on days when the graph is in a dip.
If you’re looking for a way to get notified when there are changes in the fee market and don’t want to check mempool.space manually, you can try out this pseudonymous and non-KYC tool to receive email alerts: https://txfees.watch
This approach combines the previous two with one more strategy. It can be one of the most effective and easiest ways to save on transaction fees over time, but it does require a little more active management of your wallet.
(Note that combining UTXOs with this approach does have privacy implications, but this is beyond the scope of this article. Our own Tom Honzik wrote more on UTXO management and privacy).
1. Find a time when fees are low
Let’s say that at some point during your bitcoin accumulation, you check mempool.space and find that fees are pretty low, especially on the weekend, and you can get a transaction confirmed within a day for 5 sats/byte.
2. Send a transaction to yourself
This is how your UTXOs are consolidated.
Fees are low, so we want to consolidate the unspent transaction outputs (UTXOs) to only one output, creating one new UTXO while consuming nine.
While all of these inputs could cause a very expensive transaction fee at inopportune times, the current fee market allows us to consolidate all nine of these inputs to one output, which will be a single input later down the line if we ever have to spend when fees are higher.
This chart sums up why having a smaller number of UTXOs can mean big savings later. As you can see, a large number of UTXOs when fees are higher can mean exorbitant fees:
If tax time is coming around and you’d like to make a bitcoin contribution to your IRA, and fees are at 100 sats/byte (and you can’t wait for fees to go down because the tax deadline is fast approaching!), you can rest knowing you’ve consolidated your UTXOs ahead of time!
Read more about UTXO consolidations in our article that goes deeper on high fee environments.
Other more technical strategies, some of which require upfront support from your wallet, are beyond the scope of this article. For completeness and background for the curious, here are some technologies that deserve an honorable mention:
Segregated Witness (AKA “Segwit”): This was an upgrade made to the bitcoin protocol back in 2017. Beyond simply introducing another address format (if you’ve ever seen an address that starts with “bc1” this signals a segwit enabled address), it added several technological improvements. Most notable for the topic of fees was that it enabled a new extension to blocks where signature data could be stored, segregated away from the normal block data. This increased the theoretical max capacity of a block from 1MB to ~4MB. It also introduced a discount to incentivize use of this new format, such that signatures, also known as the “witness” (which, remember, account for a big portion of the “weight” of a transaction, especially for multisig), cost up to 75% less to send if stored in this extension. You can learn more about the benefits of segwit here.
Replace-by-fee (RBF) and Child Pays For Parent (CPFP): While these don’t directly result in lower fees, they are each strategies by which transactions that are stuck can be “bumped” in priority by paying a higher fee. These can be leveraged to “test” the fee market and if a transaction gets stuck, you can bump it later on. You can learn more about RBF here and CPFP here.
The Lightning Network: If you find yourself needing to make many frequent, usually smaller, transactions, paying on-chain fees is probably undesirable. The Lightning Network is what’s known as a “Layer 2” technology that offers a way to send even just a few satoshis for little to no fees. It is still a relatively new innovation and may not be suitable for all use cases but is rapidly growing in adoption and sophistication. You can learn more about the Lightning Network here.
The goal of this post was to introduce a little more clarity into the bitcoin transaction fee market. Varying levels of technical detail were passed over in an attempt to make this as digestible as possible, so please excuse any imprecision as the underlying principles should hold regardless. Hopefully, these principles prove useful as you continue on your bitcoin journey!
Many of bitcoin’s staunchest critics have expressed doubt about its 21 million cap, but perhaps the most mindless criticism relates…Ted Stevenot, Stephen Hall
When Satoshi Nakamoto created bitcoin, he established in its code a fixed number of bitcoin that will ever exist. Since…Ted Stevenot
Originally published in Parker’s dedicated Gradually, Then Suddenly publication. Bitcoin is often described as a hedge, or more specifically, a…Parker Lewis