|
|
|
@ -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
|
|
|
|
@ -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
|
|
|
|
@ -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.
|
|
|
|
|