Creating transactions that are smaller in size weight , or which accomplish more for a given size, provide a more efficient way of using scarce block space and so pay less total fee to achieve a feerate that is equivalent to less efficient payments. 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. 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. For this reason, almost all Bitcoin transactions currently pay some bitcoins back to the spender.
The section below about change avoidance addresses how one of these cases can itself be eliminated as a cost. 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. Since , many wallets have adopted compressed public keys—but still some wallets continue to use the less efficient uncompressed public keys. In command-line and RPC wallets, there's often a call such as sendmany that lets you pay multiple recipients.
As blocks have filled, this has changed, and as of early all widely-used wallets use dynamic fee estimation to select a fee based on the condition of the current fee market. 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. 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.
That's a major benefit and one that's easily obtainable by high-frequency spenders, such as organizations. For this reason, almost all Bitcoin transactions currently pay some bitcoins back to the spender. Other wallets may not show transactions opting in to replacement at all until one version of the transaction has been confirmed.
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. 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. If that again doesn't confirm, another update can also include the third 10 minutes of transactions at the original intended feerate. 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.
Every Bitcoin transaction must reference the funds being spent and provide proof that the transaction was authorized by the owner of those funds. 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. 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. The number of ways n inputs choose m outputs combines grows exponentially  , so if the organization has a decent number of outputs well under the value being paid then this method is very practical. When a Bitcoin transaction references the funds it wants to spend, it's required to spend all of those funds.
Technically offchain payments such as those made in payment channels are a type of extremely efficient payment and so belong to this category, but they've been given a separate category because of the distinctive way they achieve their high efficiency. If transaction replacement is always combined with change avoidance , it could avoid this privacy issue. Useful for high-frequency recipients e. However, once native segwit adoption increases just slightly, this is not expected to adversely affect privacy. 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.
Instead of adding both of these payments to the block chain, we could more efficiently just add a 1 BTC payment from Alice to Charlie. In , Bitcoin protocol developer Pieter Wuille implemented a change to the program now known as Bitcoin Core that allowed it to use byte compressed public keys instead. The initial transaction version could be broadcast immediately, and each of the replacements would pay successively higher fees. Users who adopt the improvements may be able to further lower their fees.