From 4a6344a4d0d3153cd0a5fd9add039de07b759a0f Mon Sep 17 00:00:00 2001 From: "David A. Harding" Date: Mon, 31 Jul 2023 13:30:58 -1000 Subject: [PATCH] CH09: remove sections about fee market theory These were absurdly hard to write and, as often happens when something is that hard to write, they don't appear to be helpful, as judged by Murch. The last time I tried to explain the theory[1], it also sucked, so maybe this isn't what I'm meant to do. :-) The removed text introduces the term "mempool" for this chapter, so a small edit is made later on to compensate. [1] https://en.bitcoin.it/wiki/Miner_fees#The_market_for_block_space --- chapters/fees.adoc | 99 +++------------------------------------------- 1 file changed, 5 insertions(+), 94 deletions(-) diff --git a/chapters/fees.adoc b/chapters/fees.adoc index 4cdf297d..2a7abeb1 100644 --- a/chapters/fees.adoc +++ b/chapters/fees.adoc @@ -54,92 +54,6 @@ In this chapter, we'll explore various aspects of those bids--transaction fees--and how they influence the creation and management of Bitcoin transactions. -=== Bids on space and time - -There's a chart taught in most economics courses that shows simplified -supply and demand curves, shown in <>. In these -simple scenarios, increasing aggregate demand or decreasing aggregate -supply results in higher prices; alternatively, decreasing demand or -increasing supply results in lower prices. - -[[img_supply_demand]] -.Traditional supply and demand curves -image::../images/supply-demand.png[Traditional supply and demand curves] - -It's possible for the supply of block space in Bitcoin to significantly -change, but normally it's very consistent when averaged over the course -of several hours or longer. That means, for the purposes of considering -transaction fees, price is almost entirely a function of aggregate demand, -as shown in <>. - -[[img_block_supply_demand]] -.Bitcoin block space supply and demand -image::../images/supply-demand-constant.png[Bitcoin block space supply and demand] - -When demand is less than supply, the transaction fees should be nearly -zero. Most full nodes which help relay transactions from users to -miners require that every transaction they relay pay a minimum -transaction fee. This prevents their relay bandwidth being wasted. -That minimum fee is the effective floor on transaction fees. Note, the -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, 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 -decrease, the the number of people willing to pay that price to confirm -a transaction increases. Engineers call this a _negative feedback -loop_, as shown in <>. - -[[img_negative_feedback]] -.Negative feedback loop -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 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 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 -price, the price will drop until miners are willing to accept the -lower fee you offered earlier. - -We can imagine four separate transactions that are equivalent except -that each pays a different fee. The transaction paying the highest fee -gets confirmed first. As the high prices result in lower demand, which -subsequently leads to lower prices, the second highest fee transaction -gets confirmed, as does the third. Eventually the lowest fee -transaction gets confirmed. However, the lower the price becomes, the -more demand there is to confirm transactions at that price, so a -transaction paying too low of a fee might never be confirmed. We can -see this scenario illustrated in <>. - -[[img_wait_times]] -.Wait times for different fee rates -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 -confirm. - -Miners keep a pool of transactions that they will attempt to mine, -either presently or in the near future. Full nodes which relay -unconfirmed transactions will also keep their own pool. In some -Bitcoin implementations these pools are kept in memory and are called -memory pools or _mempools_. The mempools across most nodes tend to be -very similar, so it's common to talk about _the mempool_ as if it was a -single pool synchronized across multiple peers. Although that's -convenient most of the time, anyone evaluating potential problems with -transaction relay (both accidental problems and deliberate attacks) -needs to remember that every relay node keeps its own mempool. - === Who pays the transaction fee? Most payment systems involve some sort of fee for transacting, but @@ -266,8 +180,8 @@ 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 shown in -<>. If fee rates go down, then a transaction +decreasing them towards the minimum. +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 lower the fee rate on a transaction you've already sent, so you're stuck @@ -277,10 +191,6 @@ which is called _fee bumping_. There are two commonly used types of fee bumping in Bitcoin, Replace-By-Fee (RBF) and Child Pays For Parent (CPFP). -[[img_equilibrium_change]] -.Equilibrium change -image::../images/equilibrium-change.png[Equilibrium change] - [[rbf]] === Replace-By-Fee (RBF) Fee Bumping @@ -497,8 +407,9 @@ which is addressed by package relay. ==== Package Relay -Early versions of Bitcoin Core didn't place any limits on the size of -each node's mempool. Of course, computers have physical limits, whether +Early versions of Bitcoin Core didn't place any limits on the number of +unconfirmed transactions they stored for later relay and mining in their +mempools (see <>). 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