Techniques to reduce transaction fees

Universally useful but already widely deployed

The original Bitcoin software released in 2009 used 65-byte uncompressed public keys to identify the owner of a set of bitcoins. In 2012, Bitcoin protocol developer Pieter Wuille implemented a change to the program now known as Bitcoin Core that allowed it to use 33-byte compressed public keys instead.[1] As Bitcoin Core users adopted this feature and other wallets upgraded to use it as well, this reduced the size of a typical transaction on the network (with one input and two outputs) from about 258 bytes to about 226 bytes, a 14% savings.

The percentage of transaction inputs per block using the old uncompressed pubkey format in their scriptSigs. Note: early Bitcoin transactions often placed pubkeys in their scriptPubKeys rather than their scriptSigs.

The change was fully backwards compatible and did not change security in any way, but it did require users wanting to access the space savings to generate new Bitcoin addresses.

Since 2012, many wallets have adopted compressed public keys—but still some wallets continue to use the less efficient uncompressed public keys. These wallets could achieve a significant savings in transaction fees for the same priority by switching to compressed public keys. If all wallets adopted it, this would effectively lead to a small increase in the available block space:

See also:

• Compressed public keys — Bitcoin.org Developer Guide
• Bitcoin Core 0.6.0 release notes
• BIP143 - Requires all pubkeys in segregated witness witnesses be compressed pubkeys

Very useful for high-frequency spenders (e.g. organizations); moderately useful for lower-frequency spenders (e.g. individuals)

Every Bitcoin transaction must reference the funds being spent and provide proof that the transaction was authorized by the owner of those funds. To spend a single collection of funds takes a minimum of 79 vbytes under normal circumstances. This same amount of block space is used no matter how many recipients are paid in that transaction. For example, consider the following two scenarios:

• Alice pays Bob in one transaction and then pays Charlie in a second transaction. Each transaction contains a minimum of 79 vbytes related to the funds being spent—a total of 158 vbytes.
• Alice uses a single transaction to pay both Bob and Charlie. The single transaction only needs one set of 79 vbytes related to the funds being spent—a savings of 50% for this field.

This type of savings increases as more payments are added to a single transaction until the cost per payment is just barely more than the cost of adding the vbytes directly related to that payment in the transaction. The plot below shows the cost per payment for a native segwit P2WPKH transaction paying other P2WPKH outputs:

We see the cost drop by more than 50% after five payments are added, with the savings increasing up to about 70% for segwit transactions. Not shown is that the savings increase up to about 80% for legacy transactions because these transactions start off less efficient than segwit transactions. That's a major benefit and one that's easily obtainable by high-frequency spenders, such as organizations.

Many wallets support batching payments. In graphical wallets, there's often a button that allows you add additional recipients to a transaction (see image below). In command-line and RPC wallets, there's often a call such as sendmany that lets you pay multiple recipients.

Note that there are other parts of a transaction that stay a constant size (or nearly so) when payments are added, so the benefits stack up faster than a fixed cost of just 79 vbytes might suggest. The section below about change avoidance addresses how one of these cases can itself be eliminated as a cost.

See also:

• Saving up to 80% on Bitcoin transaction fees by batching payments
• SendMany RPC - Bitcoin.org Developer Reference

Universally useful

Transactions that spend bitcoins secured by segregated witness (segwit) use less space in a block than equivalent non-segwit (legacy) transactions, allowing segwit transactions to pay less total fee to achieve the same feerate as legacy transactions. The amount of savings varies depending on the details of your transaction, but here are a few common transaction types an an example:

Note that the multisig examples above use the same security as the equivalent legacy P2SH multisig. Segwit optionally allows access to a multisig form that is more secure on one dimension but it requires an extra 12 vbytes per output, which would reduce efficiency somewhat.

To access these savings, you must use a wallet that supports generating P2SH-wrapped segwit addresses (addresses that start with a "3", although not all addresses that start with a 3 are segwit-enabled). When you spend bitcoins received to these P2SH-wrapped segwit addresses, your transactions will automatically consume less block space, allowing your wallet to pay proportionally less fee.

See also:

• Segregated Witness
• Segregated Witness Wallet Development Guide - BitcoinCore.org
• List of wallets, libraries, and services that support segwit - BitcoinCore.org

Universally useful. Complete usage requires native segwit adoption by the people sending you bitcoins, but you may be able to use it for your change outputs immediately

The P2SH-wrapped segwit described above is backwards compatible with the P2SH address format supported by older wallets, but a new and non-backwards compatible format is available that saves additional space. The following examples and savings are compared to the size of the P2SH-wrapped examples above:

To access these savings, you must use a wallet that supports generating native segwit addresses, called bech32 addresses (addresses that start with a "bc1"). When you spend bitcoins received to these native segwit addresses, your transactions will automatically consume less block space than even P2SH-wrapped segwit addresses, allowing your wallet to pay proportionally less fee.

Once a wallet supports native segwit, it can begin using it immediately for any change outputs it generates back to itself without waiting for anyone else to begin using native segwit. In early 2018, when native segwit adoption is low, this may make it easier to identify which output is change and so reduce your privacy. However, once native segwit adoption increases just slightly, this is not expected to adversely affect privacy.

See also:

• Bech32 adoption
• BIP173 — Bech32 addresses

Useful for high-frequency recipients (e.g. organizations), especially those who already effectively use transaction batching

When a Bitcoin transaction references the funds it wants to spend, it's required to spend all of those funds. For example, if you received 5 BTC in a previous transaction and now you want to spend 2 BTC, Bitcoin requires that you spend all 5 BTC. For this reason, almost all Bitcoin transactions currently pay some bitcoins back to the spender. For example, you'd return the remaining 3 BTC from the previous example back to yourself. This return of money to yourself is called change by analogy to the change a store clerk hands you when you (for example) buy a $2 item with a $5 bill.

A typical change output adds about 32 vbytes to the size of a transaction. If the spender can pay with exact change—that is, doesn't need to refund any change to them self—they can eliminate the change output and generate transactions that are up to 23% smaller. In addition, a change output will later be spent at a typical cost of 69 vbytes or more, but when paying with exact change, this future cost is also avoided.

To use change avoidance requires having previously received a payment or set of payments that's close to the size of the amount being spent (including the transaction fee). This can be rare in the case of individual user wallets that don't receive many payments to choose from and can't significantly vary the amount of their spending transactions, but for organization wallets that receive many payments and already use payment batching to combine multiple outgoing payments, change avoidance can be an easily-obtainable efficiency improvement. The number of ways n inputs choose m outputs combines grows exponentially[2], so if the organization has a decent number of outputs well under the value being paid then this method is very practical.

The spender doesn't need to match the inputs and outputs of their transaction exactly to Bitcoin's full 10 nanobitcoin precision, but can instead overpay or underpay fees slightly by including inputs that are (respectively) slightly more or slightly less than the desired amount. Even when paying slightly more fees than desired, this can result in savings if the slight increase in fees is still less than would normally be paid for the extra 32 vbytes (or so) for a change output and the typical mininum of 69 vbytes for later spending that output.[3] When paying slightly lower fees, confirmation of the transaction may be delayed, but current-generation (2018) fee estimates are still inaccurate enough that small differences in feerates may not strongly correlate to delays.

For example in a notable bitcoin casino implementing this technique, when a player withdraws money they are given two options of Instant Send or Queued Send. The latter option puts their withdrawal in a queue where it may or may not be included when changeless withdrawal transactions are calculated. A large amount of people prefer the queued send, as they can save money from the savings being passed onto them. The feature has a nice UX where the customer can see it's waiting, and can cancel it if it's taking too long.

See also:

• An Evaluation of Coin Selection Strategies - Mark Erhardt
• Bitcoin Core pull request #10,637 - A proposed implementation of Erhardt's "branch and bound" strategy
• Bitcoin-Dev mailing list post - With good coin selection, I am able to avoid change about ~75% of the time in my simulations..."

Useful for all wallets but may require users sacrifice some privacy

The amount of fee a transaction pays is proportional to its size in vbytes, and one the main contributors to size is the number of inputs the transaction spends. Each input is a reference to the funds the transaction wants to spend, and when a wallet contains only low-value inputs, it can't create a comparatively higher output paying a recipient without adding many of those inputs to the transaction. Each input adds a minimum of 41 vbytes to the transaction and almost always 69 or more vbytes, so any strategy that reduces the number of inputs is worth considering.

Given that fees vary over time, one method that can reduce overall fees is input consolidation—combining a set of smaller inputs into a single larger input by spending them from yourself to yourself during a period of time when fees are lower than normal. For example, if your usual target feerate during normal-priced fee periods is 100 nanobitcoins per vbyte and the current feerate is 10 nanobitcoins per vbyte, you could save up to almost 90% on fees by consolidating now before you next need to spend some of those inputs.

Consolidation does come with the overhead of creating the consolidation transaction, which is equal to the cost of spending one input to one output, which is about 110 vbytes for P2WPKH inputs/outputs. Also, if you combine inputs that were originally sent to addresses unconnected to each other, you may reduce your privacy in some cases by making that connection in your consolidation transaction (although it's believed that few people currently manage to spend their inputs in a manner that preserves this element of privacy).

See also:

• How to cheaply consolidate coins to reduce miner fees

Universally useful. Already widely deployed but still being improved as research and development continues

Early Bitcoin wallets often defaulted to paying a fixed fee on every transaction—enough to incentivize a miner to include it but not enough to compete against other transactions seeking confirmation in the block space market. As blocks have filled, this has changed, and as of early 2018 all widely-used wallets use dynamic fee estimation to select a fee based on the condition of the current fee market.

However, some fee estimation tools may be better than others, achieving confirmation by the desired time even when paying lower fees. Although data from multiple wallets and fee estimation services can be compared[4] and there have been some attempts to compare fee estimation between different wallets,[5] there is no known survey of fee estimation quality across a large number of popular wallets as of early 2018.

In addition, also as of early 2018, some techniques have recently been described that could significantly improve fee estimation, such as factoring current mempool data into confirmation-based fee estimates.[6][7]

See also

• Transaction fees
• The Challenges of Bitcoin Transaction Fee Estimation - Jameson Lopp
• High level description Bitcoin Core's fee estimation algorithm - Alex Morcos

Very useful for non-urgent transactions. Not useful for urgent transactions

Spenders who can patiently wait for their transactions to confirm can take advantage of variations in the feerate necessary to achive confirmation. For example, sometimes several Bitcoin blocks are produced in quick succession, raising the effective supply of block space by several multiples; other times, demand drops off, such as fees on Sunday being on average 20% lower than fees on Friday in Q4 2017. Looking at data from the widely-used fee estimator included in Bitcoin Core, we can see fee savings of 90% or more possible, with around 50% being easily obtainable by many patient spenders.

In the data plotted above, the Bitcoin Core fee estimator suggests that for this sample period the following savings are available:

* Economical savings have a lower probability of being achieved and are recommended for use with the transaction replacability described in a later section.

Although waiting up to four days is impractical for many use cases, there are also many cases where it can be practical. A few examples: moving funds between one's own wallets, consolidating many smaller inputs into one larger input that can be more efficiently spent, or payments or remittances to friends or family who trust the spender and so don't need fast confirmation.

See also:

• P2SH.info - Fee estimates from multiple sources
• Other fee plotting sites

Universally useful, but may cause UI issues in recipient wallets

Although not strictly a method for reducing fees by itself, opt-in transaction replacement allows a wallet to update previously-sent transactions with new versions that pay higher fees and, possibly, make other changes to the transaction. The method is also called opt-in Replace-By-Fee (RBF). This technique allows wallets to initially pay lower fees in case there's a sudden increase in the supply of block space, a sudden decrease in demand for that space, or another situation that increases the chance of low-fee transactions being confirmed. If none of those things happens, the spender can then increase ("bump") the transaction's fee to increase its probability of confirming.

This often allows wallets that support transaction replacement to pay lower fees than wallets that don't support replacement.

Transaction replacement can appear odd in some recipient wallets. Wallets such as Bitcoin Core (pictured below) show each replacement as a separate payment in the list of transactions. When one version of the replacements is confirmed, it is shown as a normal transaction; the other versions are then shown with an X icon to indicate that they are conflicted (cannot occur together in the same valid block chain). This helps communicate the status of all affected payments to the recipient, but it may not be entirely clear what's happening to users who aren't familar with replacements. Other wallets may not show transactions opting in to replacement at all until one version of the transaction has been confirmed. There's no clear community consensus on the correct way to handle this situation using user interfaces, documentation, or both.

Transaction replacement can be advantageously combined with payment batching (described previously). Instead of waiting, for example, 30 minutes to batch all outgoing payments, the spender can batch the first 10 minutes of payments with a low feerate. If that doesn't get confirmed within 10 minutes, the spender can replace that transaction with a slightly higher feerate transaction that also includes then next 10 minutes of payments. If that again doesn't confirm, another update can also include the third 10 minutes of transactions at the original intended feerate. This allows the recipients of the first 10 minutes of payments to receive a notification that the payment has been sent up to 20 minutes earlier than with normal batching, and it also gives those early payments a chance to confirm at a lower-than-expected feerate. Updating a batched transaction with more payments can be done as many times as necessary up to a relay limit on transaction size of 100 kilobytes.

Currently, transaction replacement does have one significant downside: it tends to reduce privacy. When the fee on a transaction is increased, either additional inputs must be added or the value of the change output must be decreased. In either case, this makes the change output easier to identify among the different outputs being paid by a transaction. Value-blinding techniques such as confidential transactions could improve this situation, but there are no near-term plans to add such a feature to Bitcoin as of early 2018. If transaction replacement is always combined with change avoidance, it could avoid this privacy issue.

See also:

• Transaction replacement
• Opt-in Replace-By-Fee (RBF) FAQ - BitcoinCore.org
• BIP125 - Opt-in Full Replace-by-Fee Signaling

Pre-computed fee bumping is an idea to create and sign multiple replacements for a transaction at the time the initial transaction is created. The initial transaction version could be broadcast immediately, and each of the replacements would pay successively higher fees. This idea could be combined with Bitcoin's existing nLockTime feature to allow the replacement versions to forbid being included in a block earlier than a specified time or block height, which would allow the replacements to be trustlessly transmitted to third parties (even miners themselves).

For example, Alice would tell her wallet that she wanted to pay Bob within the next 10 blocks and also indicate what is the highest fee she’s willing to pay. Alice's wallet would then use its existing fee estimation feature to create an initial version of the transaction to Bob that paid the lowest expected fee for a transaction to confirm within 10 blocks. At the same time, Alice's wallet would also create possibly 9 other versions of the transaction, the first one using nLockTime to ensure it can’t be added until two blocks from now; the second timelocked until three blocks from now; etc…

Each of these subsequent transactions would pay a slightly higher fee than the original transaction (up to Alice’s indicated max fee) to increase the incentive for miners to mine that transaction.

Because all versions of the transaction would be signed at the time Alice sent the initial transaction, she would only need to unlock her wallet once. Also, because all subsequent versions of the transaction would use nLockTime, Alice could trustlessly distribute copies of these transactions to other people for later broadcast in case she went offline.

In short, the software would automatically offer Alice’s maximum fee if it had to, but it’d pay a lower fee if it could get away with it—ensuring Alice got close to the best price possible without any extra effort on her part.

See also:

• Bitcoin Core IRC meeting summary for 2017-03-02 - See "Precomputed fee bumping" bullet point

Very useful for small-size and moderate-size payments, but not yet widely deployed as of early 2018

Payment channels are a type of enforceable offchain payment where bitcoins are deposited into a smart contract between two or more parties, allowing the involved peers to make trustless payments to each other. Combined with hashlocks, payments can be securely routed across a network of peers, as in the Lightning Network, allowing Alice to pay Charlie by routing a payment through their mutual peer Bob.

Opening a payment channel requires a confirmed transaction, incurring the cost of the fees for that transaction, although those fees are identical to sending a regular transaction. Closing a channel also requires a confirmed transaction, adding that transaction's fees to the cost of the payment channel, although those fees too are similar to the costs of the recipient of the funds re-spending them to a new recipient. This means a payment channel's fee cost is very similar to making onchain payments.

Outside of the channel open and channel close transactions, a payment channel can support an unlimited number of payments without paying any further transaction fees. This can make them extraordinarily efficient—for example, imagine making a million in-channel payments for the cost of just two transaction fees. Note: your channel peers and other channel nodes you route payments through may require their own fee for using their services; these are not related to the transaction fees that are the topic of this article.

As of early 2018, no payment channel implementation is widely used, but several cooperating implementations of a first version of Lightning Network are available.

See also:

• Payment channels
• Lightning Network