mirror of
https://github.com/bitcoinbook/bitcoinbook
synced 2024-12-23 15:18:11 +00:00
199 lines
9.9 KiB
Plaintext
199 lines
9.9 KiB
Plaintext
[[ch06]]
|
||
|
||
[[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–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")))
|