bitcoinbook/chapters/fees.adoc

//FIXME
// - Economic incentives for segwit
// - RBF (opt-in, full)
// - CPFP
// - CPFP carve out
// - Package relay
[[tx_fees]]
==== Transaction Fees

((("transactions", "outputs and inputs", "transaction fees")))((("fees",
"transaction fees")))((("mining and consensus", "rewards and
fees")))Most transactions include transaction fees, which compensate the
bitcoin miners for securing the network. Fees also serve as a security
mechanism themselves, by making it economically infeasible for attackers
to flood the network with transactions. Mining and the fees and rewards
collected by miners are discussed in more detail in <<mining>>.

This section examines how transaction fees are included in a typical
transaction. Most wallets calculate and include transaction fees
automatically. However, if you are constructing transactions
programmatically, or using a command-line interface, you must manually
account for and include these fees.

Transaction fees serve as an incentive to include (mine) a transaction
into the next block and also as a disincentive against abuse of the
system by imposing a small cost on every transaction. Transaction fees
are collected by the miner who mines the block that records the
transaction on the blockchain.

Transaction fees are calculated based on the size of the transaction in
kilobytes, not the value of the transaction in bitcoin. Overall,
transaction fees are set based on market forces within the Bitcoin
network. Miners prioritize transactions based on many different
criteria, including fees, and might even process transactions for free
under certain circumstances. Transaction fees affect the processing
priority, meaning that a transaction with sufficient fees is likely to
be included in the next block mined, whereas a transaction with
insufficient or no fees might be delayed, processed on a best-effort
basis after a few blocks, or not processed at all. Transaction fees are
not mandatory, and transactions without fees might be processed
eventually; however, including transaction fees encourages priority
processing.

Over time, the way transaction fees are calculated and the effect they
have on transaction prioritization has evolved. At first, transaction
fees were fixed and constant across the network. Gradually, the fee
structure relaxed and may be influenced by market forces, based on
network capacity and transaction volume. Since at least the beginning of
2016, capacity limits in bitcoin have created competition between
transactions, resulting in higher fees and effectively making free
transactions a thing of the past. Zero fee or very low fee transactions
rarely get mined and sometimes will not even be propagated across the
network.

((("fees", "fee relay policies")))((("minrelaytxfee option")))In Bitcoin
Core, fee relay policies are set by the +minrelaytxfee+ option. The
current default +minrelaytxfee+ is 0.00001 bitcoin or a hundredth of a
millibitcoin per kilobyte. Therefore, by default, transactions with a
fee less than 0.00001 bitcoin are treated as free and are only relayed
if there is space in the mempool; otherwise, they are dropped. Bitcoin
nodes can override the default fee relay policy by adjusting the value
of +minrelaytxfee+.

((("dynamic fees")))((("fees", "dynamic fees")))Any bitcoin service that
creates transactions, including wallets, exchanges, retail applications,
etc., _must_ implement dynamic fees. Dynamic fees can be implemented
through a third-party fee estimation service or with a built-in fee
estimation algorithm. If you're unsure, begin with a third-party service
and as you gain experience design and implement your own algorithm if
you wish to remove the third-party dependency.

Fee estimation algorithms calculate the appropriate fee, based on
capacity and the fees offered by "competing" transactions. These
algorithms range from simplistic (average or median fee in the last
block) to sophisticated (statistical analysis). They estimate the
necessary fee (in satoshis per byte) that will give a transaction a high
probability of being selected and included within a certain number of
blocks. Most services offer users the option of choosing high, medium,
or low priority fees. High priority means users pay higher fees but the
transaction is likely to be included in the next block. Medium and low
priority means users pay lower transaction fees but the transactions may
take much longer to confirm.

((("bitcoinfees (third-party service)")))Many wallet applications use
third-party services for fee calculations. One popular service is
http://bitcoinfees.21.co/[_http://bitcoinfees.21.co_], which provides an
API and a visual chart showing the fee in satoshi/byte for different
priorities.

[TIP]
====
((("static fees")))((("fees", "static fees")))Static fees are no longer
viable on the Bitcoin network. Wallets that set static fees will produce
a poor user experience as transactions will often get "stuck" and remain
unconfirmed. Users who don't understand bitcoin transactions and fees
are dismayed by "stuck" transactions because they think they've lost
their money.
====

The chart in <<bitcoinfees21co>> shows the real-time estimate of fees in
10 satoshi/byte increments and the expected confirmation time (in
minutes and number of blocks) for transactions with fees in each range.
For each fee range (e.g., 61&#x2013;70 satoshi/byte), two horizontal
bars show the number of unconfirmed transactions (1405) and total number
of transactions in the past 24 hours (102,975), with fees in that range.
Based on the graph, the recommended high-priority fee at this time was
80 satoshi/byte, a fee likely to result in the transaction being mined
in the very next block (zero block delay). For perspective, the median
transaction size is 226 bytes, so the recommended fee for a transaction
size would be 18,080 satoshis (0.00018080 BTC).

The fee estimation data can be retrieved via a simple HTTP REST API, at
https://bitcoinfees.21.co/api/v1/fees/recommended[https://bitcoinfees.21.co/api/v1/fees/recommended].
For example, on the command line using the +curl+ command:

.Using the fee estimation API
----
$ curl https://bitcoinfees.21.co/api/v1/fees/recommended

{"fastestFee":80,"halfHourFee":80,"hourFee":60}
----

The API returns a JSON object with the current fee estimate for fastest
confirmation (+fastestFee+), confirmation within three blocks
(+halfHourFee+) and six blocks (+hourFee+), in satoshi per byte.

[[bitcoinfees21co]]
.Fee estimation service bitcoinfees.21.co
image::images/mbc2_0602.png[Fee Estimation Service bitcoinfees.21.co]

==== Adding Fees to Transactions

The data structure of transactions does not have a field for fees.
Instead, fees are implied as the difference between the sum of inputs
and the sum of outputs. Any excess amount that remains after all outputs
have been deducted from all inputs is the fee that is collected by the
miners:

[[tx_fee_equation]]
.Transaction fees are implied, as the excess of inputs minus outputs:
----
Fees = Sum(Inputs) – Sum(Outputs)
----

This is a somewhat confusing element of transactions and an important
point to understand, because if you are constructing your own
transactions you must ensure you do not inadvertently include a very
large fee by underspending the inputs. That means that you must account
for all inputs, if necessary by creating change, or you will end up
giving the miners a very big tip!

For example, if you consume a 20-bitcoin UTXO to make a 1-bitcoin
payment, you must include a 19-bitcoin change output back to your
wallet. Otherwise, the 19-bitcoin "leftover" will be counted as a
transaction fee and will be collected by the miner who mines your
transaction in a block. Although you will receive priority processing
and make a miner very happy, this is probably not what you intended.

[WARNING]
====
((("warnings and cautions", "change outputs")))If you forget to add a
change output in a manually constructed transaction, you will be paying
the change as a transaction fee. "Keep the change!" might not be what
you intended.
====

((("use cases", "buying coffee")))Let's see how this works in practice,
by looking at Alice's coffee purchase again. Alice wants to spend 0.015
bitcoin to pay for coffee. To ensure this transaction is processed
promptly, she will want to include a transaction fee, say 0.001. That
will mean that the total cost of the transaction will be 0.016. Her
wallet must therefore source a set of UTXO that adds up to 0.016 bitcoin
or more and, if necessary, create change. Let's say her wallet has a
0.2-bitcoin UTXO available. It will therefore need to consume this UTXO,
create one output to Bob's Cafe for 0.015, and a second output with
0.184 bitcoin in change back to her own wallet, leaving 0.001 bitcoin
unallocated, as an implicit fee for the transaction.

((("use cases", "charitable donations")))((("charitable donations")))Now
let's look at a different scenario. Eugenia, our children's charity
director in the Philippines, has completed a fundraiser to purchase
schoolbooks for the children. She received several thousand small
donations from people all around the world, totaling 50 bitcoin, so her
wallet is full of very small payments (UTXO). Now she wants to purchase
hundreds of schoolbooks from a local publisher, paying in bitcoin.

As Eugenia's wallet application tries to construct a single larger
payment transaction, it must source from the available UTXO set, which
is composed of many smaller amounts. That means that the resulting
transaction will source from more than a hundred small-value UTXO as
inputs and only one output, paying the book publisher. A transaction
with that many inputs will be larger than one kilobyte, perhaps several
kilobytes in size. As a result, it will require a much higher fee than
the median-sized transaction.

Eugenia's wallet application will calculate the appropriate fee by
measuring the size of the transaction and multiplying that by the
per-kilobyte fee. Many wallets will overpay fees for larger transactions
to ensure the transaction is processed promptly. The higher fee is not
because Eugenia is spending more money, but because her transaction is
more complex and larger in size--the fee is independent of the
transaction's bitcoin value.((("", startref="Tout06")))

[[transaction-pinning]]
=== Transaction Pinning

FIXME

[[rbf]]
=== Replace by Fee (RBF)

FIXME

[[fee_sniping]]
==== Timelock Defense Against Fee Sniping

((("scripting", "timelocks", "defense against
fee-sniping")))((("timelocks", "defense against
fee-sniping")))((("fees", "fee sniping")))((("security", "defense
against fee-sniping")))((("sniping")))Fee-sniping is a theoretical
attack scenario, where miners attempting to rewrite past blocks "snipe"
higher-fee transactions from future blocks to maximize their
profitability.

For example, let's say the highest block in existence is block
#100,000. If instead of attempting to mine block #100,001 to extend the
chain, some miners attempt to remine  #100,000. These miners can choose
to include any valid transaction (that hasn't been mined yet) in their
candidate block  #100,000. They don't have to remine the block with the
same transactions. In fact, they have the incentive to select the most
profitable (highest fee per kB) transactions to include in their block.
They can include any transactions that were in the "old" block
#100,000, as well as any transactions from the current mempool.
Essentially they have the option to pull transactions from the "present"
into the rewritten "past" when they re-create block  #100,000.

Today, this attack is not very lucrative, because block reward is much
higher than total fees per block. But at some point in the future,
transaction fees will be the majority of the reward (or even the
entirety of the reward). At that time, this scenario becomes inevitable.

To prevent "fee sniping," when Bitcoin Core creates transactions, it
uses +nLocktime+ to limit them to the "next block," by default. In our
scenario, Bitcoin Core would set +nLocktime+ to 100,001 on any
transaction it created. Under normal circumstances, this +nLocktime+ has
no effect&#x2014;the transactions could only be included in block
#100,001 anyway; it's the next block.

But under a blockchain fork attack, the miners would not be able to pull
high-fee transactions from the mempool, because all those transactions
would be timelocked to block #100,001. They can only remine  #100,000
with whatever transactions were valid at that time, essentially gaining
no new fees.

To achieve this, Bitcoin Core sets the +nLocktime+ on all new
transactions to <current block # + 1> and sets the +nSequence+ on all
the inputs to 0xFFFFFFFE to enable +nLocktime+.((("",
startref="Stimelock07")))