|
|
|
|
@ -85,7 +85,7 @@ minimum transaction relay fee must be a fairly small amount or it would
|
|
|
|
|
create an incentive for users to begin sending transactions to miners
|
|
|
|
|
directly, which would be bad for mining decentralization.
|
|
|
|
|
|
|
|
|
|
When demand exceeds supply, then the only thing that prevents fee costs
|
|
|
|
|
When demand exceeds supply, the only thing that prevents fee costs
|
|
|
|
|
from rising to infinity is that higher prices curtail demand. Each time
|
|
|
|
|
the price increases, the number of people who want to pay that price to
|
|
|
|
|
include a transaction in a block decreases. Conversely, when prices
|
|
|
|
|
@ -99,12 +99,12 @@ image::../images/fee-negative-feedback.png[Negative feedback loop]
|
|
|
|
|
|
|
|
|
|
In particular, people who want to send a transaction during a period of
|
|
|
|
|
high fees will try to find an alternative. There are many alternatives
|
|
|
|
|
for most reasons people need to send a transaction, such as moving to an
|
|
|
|
|
for most reasons why people need to send a transaction, such as moving to an
|
|
|
|
|
offchain payment system like Lightning Network, using an alternative
|
|
|
|
|
payment network, or taking care to construct the smallest transaction
|
|
|
|
|
possible. But it's also possible to take advantage of the negative
|
|
|
|
|
feedback loop to pay less fees. All you need to do is create a
|
|
|
|
|
transaction now which pays a fee that's equal to or higher than what
|
|
|
|
|
transaction which pays a fee that's equal to or higher than what
|
|
|
|
|
miners will accept in the future--even if that price is below what they
|
|
|
|
|
accept now. As the market of other people adapts to the higher price by
|
|
|
|
|
lowering demand, and as miners confirm all transactions paying a higher
|
|
|
|
|
@ -123,7 +123,7 @@ see this scenario illustrated in <<img_wait_times>>.
|
|
|
|
|
|
|
|
|
|
[[img_wait_times]]
|
|
|
|
|
.Wait times for different fee rates
|
|
|
|
|
image::../images/fee-patience.png[Wait times for different feerates]
|
|
|
|
|
image::../images/fee-patience.png[Wait times for different fee rates]
|
|
|
|
|
|
|
|
|
|
In other words, you don't need to pay peak prices, or switch to another
|
|
|
|
|
payment method, if you're willing to wait longer for your transaction to
|
|
|
|
|
@ -206,28 +206,28 @@ different units:
|
|
|
|
|
- weight/satoshi (also commonly used today)
|
|
|
|
|
|
|
|
|
|
We recommend either the vByte/sat or weight/sat units for displaying
|
|
|
|
|
feerates.
|
|
|
|
|
fee rates.
|
|
|
|
|
|
|
|
|
|
[WARNING]
|
|
|
|
|
====
|
|
|
|
|
Be careful accepting input for feerates. If a user copy and pastes a
|
|
|
|
|
feerate printed in one enumerator into a field using a different
|
|
|
|
|
Be careful accepting input for fee rates. If a user copy and pastes a
|
|
|
|
|
fee rate printed in one enumerator into a field using a different
|
|
|
|
|
enumerator, they could overpay fees by 1,000 times. If they instead
|
|
|
|
|
switch the denominator, they could theoretically overpay by 100,000,000
|
|
|
|
|
times. Wallets should make it hard for the user to pay an excessive
|
|
|
|
|
feerate and may want to prompt the user to confirm any feerate that was
|
|
|
|
|
fee rate and may want to prompt the user to confirm any fee rate that was
|
|
|
|
|
not generated by the wallet itself using a trusted data source.
|
|
|
|
|
|
|
|
|
|
An excessive fee, also called an _absurd fee_, is any feerate that's
|
|
|
|
|
significantly higher than the amount that feerate estimators currently
|
|
|
|
|
An excessive fee, also called an _absurd fee_, is any fee rate that's
|
|
|
|
|
significantly higher than the amount that fee rate estimators currently
|
|
|
|
|
expect is necessary to get a transaction confirmed in the next block.
|
|
|
|
|
Note that wallets should not entirely prevent users from choosing an
|
|
|
|
|
excessive feerate--they should only make using such a feerate hard to do
|
|
|
|
|
excessive fee rate--they should only make using such a fee rate hard to do
|
|
|
|
|
by accident. There are legitimate reasons for users to overpay fees on
|
|
|
|
|
rare occasions.
|
|
|
|
|
====
|
|
|
|
|
|
|
|
|
|
=== Estimating appropriate feerates
|
|
|
|
|
=== Estimating appropriate fee rates
|
|
|
|
|
|
|
|
|
|
We've established that you can pay a lower fee rate if you're willing to
|
|
|
|
|
wait longer for your transaction to be confirmed, with the exception
|
|
|
|
|
@ -266,7 +266,7 @@ current list, see https://www.lopp.net/bitcoin-information/fee-estimates.html
|
|
|
|
|
As mentioned, fee rate estimation can never be perfect. One common
|
|
|
|
|
problem is that the fundamental demand might change, adjusting the
|
|
|
|
|
equilibrium and either increasing prices (fees) to new heights or
|
|
|
|
|
decreasing them towards the minimum, as show in
|
|
|
|
|
decreasing them towards the minimum, as shown in
|
|
|
|
|
<<img_equilibrium_change>>. If fee rates go down, then a transaction
|
|
|
|
|
that previously paid a normal fee rate might now be paying a high fee
|
|
|
|
|
rate and it will be confirmed earlier than expected. There's no way to
|
|
|
|
|
@ -491,7 +491,7 @@ separate transaction. Using extra block space requires paying extra
|
|
|
|
|
fees beyond the the cost of the fee bump.
|
|
|
|
|
|
|
|
|
|
There are several challenges with CPFP, some of which we'll explore in
|
|
|
|
|
the <<transaction_pinning>> section. One other problem which we
|
|
|
|
|
<<transaction_pinning>>. One other problem which we
|
|
|
|
|
specifically need to mention is the minimum relay fee rate problem,
|
|
|
|
|
which is addressed by package relay.
|
|
|
|
|
|
|
|
|
|
@ -502,7 +502,7 @@ each node's mempool. Of course, computers have physical limits, whether
|
|
|
|
|
it's the memory (RAM) or disk space--it's not possible for a full node
|
|
|
|
|
to store an unlimited number of unconfirmed transactions. Later
|
|
|
|
|
versions of Bitcoin Core limited the size of the mempool to hold about
|
|
|
|
|
one day worth of transactions, storing only the transactions or packages
|
|
|
|
|
one day's worth of transactions, storing only the transactions or packages
|
|
|
|
|
with the highest fee rate.
|
|
|
|
|
|
|
|
|
|
That works extremely well for most things, but it creates a dependency
|
|
|
|
|
@ -536,7 +536,7 @@ problem.
|
|
|
|
|
=== Transaction Pinning
|
|
|
|
|
|
|
|
|
|
Although both RBF and CPFP fee bumping work in the basic cases we
|
|
|
|
|
described in the sections about them, there are rules related to both
|
|
|
|
|
described, there are rules related to both
|
|
|
|
|
methods that are designed to prevent denial of service attacks on miners
|
|
|
|
|
and relaying full nodes. An unfortunate side effect of those rules
|
|
|
|
|
is that they can sometimes prevent someone from being able to use fee
|
|
|
|
|
@ -566,7 +566,7 @@ large child transaction. If Alice then wants to replace her original
|
|
|
|
|
transaction, she needs to pay a fee that's larger than what both she and
|
|
|
|
|
Bob originally paid. For example, if Alice's original transaction was
|
|
|
|
|
about 100 vbytes and Bob's transaction was about 100,000 vbytes, and
|
|
|
|
|
they both used the same feerate, Alice now needs to pay more than 1,000
|
|
|
|
|
they both used the same fee rate, Alice now needs to pay more than 1,000
|
|
|
|
|
times as much as she originally paid in order to RBF fee bump her
|
|
|
|
|
transaction.
|
|
|
|
|
|
|
|
|
|
@ -593,7 +593,7 @@ Additionally, a transaction and all of its descendants is not
|
|
|
|
|
+
|
|
|
|
|
To prevent these problems, and other related
|
|
|
|
|
problems, Bitcoin Core limits a parent transaction to having a maximum
|
|
|
|
|
of 25 ancestors or descendants in its mempool pool and limits the
|
|
|
|
|
of 25 ancestors or descendants in its mempool and limits the
|
|
|
|
|
total size of all those transactions to 100,000 vbytes. The downside
|
|
|
|
|
of this approach is that users are prevented from creating CPFP fee
|
|
|
|
|
bumps if a transaction already has too many descendants (or if it and
|
|
|
|
|
@ -631,7 +631,7 @@ allow fee bumping with either RBF (using special sighash flags) or CPFP,
|
|
|
|
|
but both of those protocols are vulnerable to transaction pinning.
|
|
|
|
|
Given that the involved transactions are time sensitive, allowing a
|
|
|
|
|
counterparty to use transaction pinning to delay confirmation of a
|
|
|
|
|
transaction can easily lead to an repeatable exploit that malicious
|
|
|
|
|
transaction can easily lead to a repeatable exploit that malicious
|
|
|
|
|
parties could use to steal money from honest parties.
|
|
|
|
|
|
|
|
|
|
LN developer Matt Corallo proposed a solution: give the rules for CPFP
|
|
|
|
|
@ -735,7 +735,7 @@ transaction it created. Under normal circumstances, this +nLocktime+ has
|
|
|
|
|
no effect—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
|
|
|
|
|
But under a reorganization 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
|
|
|
|
|
@ -746,3 +746,9 @@ profitable in some cases and so can help preserve the stability of the
|
|
|
|
|
Bitcoin network as the block subsidy declines. We recommend all wallets
|
|
|
|
|
implement anti fee sniping when it doesn't interfere with the wallet's
|
|
|
|
|
other uses of the nLockTime field.
|
|
|
|
|
|
|
|
|
|
As Bitcoin continues to mature, and as the subsidy continues to decline,
|
|
|
|
|
fees become more and more important to Bitcoin users, both in their
|
|
|
|
|
day-to-day use for getting transactions confirmed quickly and in
|
|
|
|
|
providing an incentive for miners to continue securing Bitcoin
|
|
|
|
|
transactions with new proof-of-work.
|
|
|
|
|
|
David A. Harding
11 months ago