Bitcoin transaction fees, how they’re calculated, and how to pay less

Bitcoin is by far the most valuable and therefore most heavily demanded cryptocurrency, but there ain’t no such thing as a free lunch. Higher demand for an open, borderless, and permissionless monetary system comes with costs. But how do these costs get calculated?

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, so feel free to skip around as needed:

  1. Understanding transaction fees in bitcoin
  2. What makes a bitcoin transaction more or less expensive to send (Crunching the numbers)
  3. Three (simple) strategies to save in fees

We’ll close with some more technical options that we may follow up with in future posts.

Fiat vs. Bitcoin: A new way to think about paying for transaction processing

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 on 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:

  1. Administration and bureaucratic overhead (all the software systems, PoS (Point of Sale) terminals, auditors, etc.)
  2. Assumption of risk usually by an intermediary like Visa from the time a transaction is initiated to the time it is settled, though also often by the merchants themselves in the form of chargeback risk.
  3. Liquidity

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:

  1. You pay more the more you are trying to transact ($3 for a $100 transaction vs. $30 for a $1,000 transaction)
  2. This fee is hidden, often passed through in the price you are charged at point of sale, rather than listed in your receipt.

The situation in bitcoin is very different. There are no PoS 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). This means that as demand for transaction processing increases, the amount of relative available block space decreases.

If something shifts the demand curve to the right (like Tesla and Square buying more bitcoin), the intersection moves to the right, closer to the full blocks, and with higher fees.

Mo’ Data Mo’ Problems

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 regards 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:

  1. “Metadata” – Fixed fields that provide information about a transaction and are always present
  2. Inputs – how you’re funding a transaction
  • Signatures or “witnesses” (these are how you prove ownership of bitcoin that you want to send)
  • Input metadata – information about the bitcoin being spent
  1. Outputs – the value and destination of the bitcoin you want to send

From this we can already see how the size of a transaction could increase. At its simplest though, a single signature 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 bytes, the fee paid is going to be 3,000 satoshis.

Simple tx => Metadata + 1 input + 1 output = 178 bytes * 10 sats/byte = 1,780 satoshis

Not too bad. $0.89 with the price of bitcoin at $50k and a relatively high 10 satoshi/byte rate.


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, so this is a better reference point.

Two Outputs => Metadata + 1 input + 2 outputs = 212 bytes * 10 sats/byte = 2,120 satoshis

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 likely 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 a tenth of a bitcoin 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 1BTC. 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 add ~114 bytes.

11 Inputs => Metadata + 11 inputs + 2 outputs = 30 + 11*114 + 2*34 = 1,352 bytes * 10 sats/byte = 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, checkout some 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 “normal” single signature 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:

A Normal Input

A multisig input requires:

  • A list of all of the public keys that could be signers for that transaction (in a two of three, this means 3 public keys)
  • A signature for each key that is signing (in a two of three, this is two signatures)
  • The normal input metadata for referencing the UTXO on the blockchain
  • Extra metadata describing the “script”

A Multisig Input

So for our example 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. This would be like paying to ship a 5 gallon box of rocks vs. 5 gallons of pillows.

11 Multisig Inputs = Base + 11 inputs + 2 outputs = 30 + (11 * 293) + (34 * 2) = 3,321 * 10 sats/byte = 33,210 satoshis.

33,210 satoshis in fees compared to 14,740. In a busier network, it would be conceivable for those fee rates to double to 20 sats/byte for a reliable confirmation, so 66,420 satoshis vs. 29,480. 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 single signature transaction.

What to do about high transaction fees

So, 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. We’re going to focus mainly on less technical solutions, but at the end we’ll provide a list of some of the more advanced techniques for those interested in learning more.

Lower the fee rate if you’re not in a rush

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 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).

Wait for days with lower network usage

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. 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 manually, you can try out this pseudonymous and non-KYC tool to receive email alerts:

Consolidate your UTXOs

This approach combines the previous two with one more strategy. It can be one of the most effective and also 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. Read more here for how this could reduce the privacy of your wallet).

Let’s go back to our 11 input example from earlier, but instead of 10 or 20 satoshis per byte in fees, is telling us that a medium priority confirmation time will require 80 sats/byte. This would mean that our 3,321 byte transaction will require 265,680 satoshis to confirm in the next couple hours, or $134 at a price of $50k per BTC!

First: Find a time when fees are low

Let’s say that at month 6 and 12 during your bitcoin saving period, you check 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.

Then: Send a transaction to yourself

This is how your UTXOs are consolidated.

So, during month 6, we’ve sent 0.1BTC to ourselves six times for a total balance of 0.6BTC. Fees are low, so we want to consolidate our six unspent transaction outputs (UTXOs). And since we’re spending to ourselves, there’s only one output, creating one new UTXO while consuming six.

Metadata + 6 multisig inputs + 1 output =  30 + (6 * 293) + (34 * 1) = 1,822 bytes * 5 sats/byte = 9,110 satoshis.

To keep it simple, we’ll hold the value of BTC steady at $50k, so we pay $4.50 for this first consolidation.

By month 12 we have six new 0.1BTC UTXOs plus the 0.5999089BTC (0.6BTC – 9,110 satoshi of fees paid). In the meantime, we’ve signed up to receive alerts from and are notified that fees are low, so we take the opportunity to consolidate again.

Base + 7 multisig inputs + 1 output = 30 + (7 * 293) + (34 * 1) = 2,115 bytes * 5 sats/byte = 10,575 satoshis or ~$5.30

Note that even though one of the UTXOs is very large in value, this has no impact on how much it costs to process. One 0.599BTC UTXO costs the same to process as one that’s 0.1BTC (or 0.0001BTC for that matter).

So now we’ve paid a total of $9.80 for consolidating the UTXOs in our wallet making a balance of 1.1998 with just a single UTXO.

Well, tax time is coming around and you’d like to make a bitcoin contribution to your IRA (assuming these purchases were made in the name of your IRA’s LLC of course). Fees are crazy though, back at 80 sats/byte even on the weekend. You can’t wait for fees to go down because the tax deadline is fast approaching. Luckily, you’ve consolidated your UTXOs ahead of time! Let’s see what it looks like to deposit 1BTC into our IRA vault (so two outputs, one to the IRA and one back as change).

Base + 1 multisig input + 2 outputs = 30 + (1 * 293) + (34 * 2) = 391 * 80 sats/byte = 31,280 satoshis or $15.64

The total we’ve spent on fees to send 1BTC has gone from $134 in the earlier 11-input, single transaction example down to $25.44 to send three transactions with a consolidation approach, a savings of over 80%!

Final Thoughts

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 technical oversights or fudging of numbers as the principles should hold up despite any such errors. Hopefully these principles prove useful as you continue on your bitcoin journey!

These are by no means the only ways to reduce fees though! Other more technical strategies, some of which require upfront support from your wallet, were beyond the scope of this article. For completeness and background for the curious, here are some technologies that deserve an honorable mention:

  1. 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.
  2. 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.
  3. 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.