Motivation The default relay-fee (-minrelaytxfee) was set to 1000 sat/kvB about 10 years ago. Over that period the USD price of BTC has risen by roughly 2-3 orders of magnitude, making the economic cost of relaying small transactions disproportionately high.
Proposed change Lower the default to 100 sat/kvB—a 10× reduction—bringing the effective USD cost back in line. This maintains DoS resistance without discouraging low-value UTXO consolidation.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32959.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| Concept NACK | 1440000bytes |
| Concept ACK | delta1 |
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.
No conflicts as of last run.
DEFAULT_INCREMENTAL_RELAY_FEE should be decreased along with this as well.
p2p_ibd_txrelay.py test needs updating.
DEFAULT_INCREMENTAL_RELAY_FEEshould be decreased along with this as well.
Assuming there are miners using Bitcoin Core to mine, then the DEFAULT_BLOCK_MIN_TX_FEE should be lowered as well.
the USD price of BTC has risen by roughly 2-3 orders of magnitude…[let’s do] a 10× reduction
Wouldn’t a 100x reduction be more in line? i.e. something like 10 sat/kvB?
Every commit needs to pass CI independently, and instead of merge commits or cherry-picks, we usually add co-authors. Could you please squash the commits according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits?
And could you please explain how you got to the 10x reduction, did you conduct some analysis or is it just a hunch?
test: Update p2p_ibd_tx_relay.py to support minrelaytxfee as low as 100 sats/kvB.
Concept NACK
I don’t see any need to change default minrelaytxfee. It is configurable and users can change it for their node. Full RBF and OP_RETURN changes were done for different reasons. However, this is now getting into DoS territory.
Only fee estimation should be changed to work with lower fee rates: #13990
It’s good that bitcoin price in terms of USD is higher and the cost for an attacker to use p2p as broadcast system has increased over the years. With the block rewards decreasing every halving, low demand for blockspace etc. 1 sat/vbyte seems to be a good floor for miners’ revenue.
Over that period the USD price of BTC has risen by roughly 2-3 orders of magnitude, making the economic cost of relaying small transactions disproportionately high.
The question is whether DoS protection back then was actually sufficient, or if the increase in fiat terms was the luck we needed. I don’t know the answer to that.
As an example, a recent DoS fix involved a rate limiting mechanism that was set to 7 transactions per second. This rate limit is based on how many transactions fit in a block. It seems plausible, but I don’t know, if a lower relay fee would have made it cheaper to DoS nodes before v25.0. It’d be interesting to simulate that with Warnet.
Another difference between now and back then is the presence of Lightning and other systems that are sensitive to mempool shenanigans in general. Again I don’t know if those attacks scale with the minimum relay fee either.
If that research has already been done, please link to it. Otherwise I would not be in favor (although we may not have a choice if the full-RBF game is repeated).
Finally in terms of pure node performance, it might be better to wait for cluster mempool #30289 to be deployed.
DUST_RELAY_TX_FEE should be decreased along with this as well…
That value is used to calculate the minimum output amount, not the fee rate of a tx. That seems orthogonal to the goal of this PR.
That value is used to calculate the minimum output amount, not the fee rate of a tx. That seems orthogonal to the goal of this PR.
The two concepts of “dust limit” and minRelayTxFee are logically related and the former was originally derived from the latter in the implementation (see commit eb30d1a introducing the dustRelayFee).
If this logical relationship is abandoned, it would be better to explain why and what is the economic rationale behind the determination of the value defining the “dust limit”.
DUST_RELAY_TX_FEE should be decreased along with this as well…
DEFAULT_MIN_RELAY_TX_FEE and DUST_RELAY_TX_FEE serve different purposes. The former is about protecting the P2P network, while the latter also aims at protecting the UTXO set from DoS attacks. Given that half of the UTXO set is spam these days, it seems like the dust limit should rather get increased than decreased. So it’s a whole different discussion, and I would not want to conflate these two in this PR.
27@@ -28,17 +28,17 @@
28 )
29 from test_framework.test_framework import BitcoinTestFramework
30
31-MAX_FEE_FILTER = Decimal(9170997) / COIN
32-NORMAL_FEE_FILTER = Decimal(100) / COIN
33+MAX_FEE_FILTER = Decimal(9936506) / COIN
MAX_FEE_FILTER line was changed, could you elaborate?
When I evaluated why the test was failing, I noticed that changing the value for NORMAL_FEE_FILTER on its own was insufficient for making the test pass. Digging further into the mechanics on how the policy filters worked, and looking logs on my local version of the code this is what I found:
I made the change from 9170997 to 9936506 because, reducing minrelaytxfee halves min_fee_limit (500→50, fees.cpp:1090). This alters the geometric sequence in MakeFeeSet (fees.cpp:1092-1095).
With spacing=1.1 (set in fees.h:322), starting lower fits one more bucket before capping at 1e7, yielding a higher max (9936506) due to floating point multiplication.
This can be verified independently if you run FeeFilterRounder with CFeeRate(100) vs CFeeRate(1000), and call round(MAX_MONEY).
To @instagibbs’s point, if the better approach is write a new set of tests instead of working with the poorly written tests we have now, happy to help when I have time.
It’s ridiculous to obsess over “spam” and have it dictate policy, rather than rely on economic incentives. Dust limits should be set based on it being economical to spend a UTXO at minimum relay fees, rather than your misplaced notion of “spam”.
This is an ideological stance that ignores how Bitcoin has operated for basically its entire existence.
Reducing DEFAULT_MIN_RELAY_TX_FEE only makes sense to me in conjunction with reducing DEFAULT_BLOCK_MIN_TX_FEE. Otherwise nodes become subject to free relay attacks that could be used to waste bandwidth across the network with transactions that are not even in danger of getting mined in most blocks.
DEFAULT_INCREMENTAL_RELAY_FEEshould be decreased along with this as well.
That’s probably a bad idea, as it would increase the surface for bandwidth wasting attacks 10× even on top of what dropping the DEFAULT_MIN_RELAY_TX_FEE would do.
While I’m sympathetic to users wanting to transact (and especially consolidate) at lower feerates whenever blockspace demand is as low as it currently is, this drops a full block’s minimum transaction fees to ~100,000 sats, or about ~0.03% of the current subsidy. That seems like the wrong signal when the ecosystem’s long-term roadmap relies on transaction fees eventually funding mining.
If this idea gets traction, perhaps it would be interesting to combine a reduction of the minimum relay transaction fee rate with shifting the denomination of fee rates to sats/WU and setting a new minimum relay transaction fee rate to 100 sats/kWU instead which would be 0.4 sats/vB rather than 0.1 sats/vB.
If tests aren’t breaking, a good place to start would be to write a test that breaks on these changes, then fix them in feature commit. As of now, nothing breaks which is concerning.
On the meta level: Very low feerate transactions have negligible impact on mining profitability in terms of block templates themselves. It’s not obvious that the price going up 10x means we get to lower the default by 10x, because it’s a more important system now and the stakes are simply higher. The most persuasive argument for this would be that miners have diverged from defaults and it is impacting block relay and the DoS risk of 10x lower fees is acceptable. Note that under transactional load(which is what we need long term anyways for consensus stability), this change is a no-op, so I’m not convinced at all this is the right tradeoff.
The most persuasive argument for this would be that miners have diverged from defaults
You continue to confuse cause and effect. Miners mine what gets relayed, not the reverse.
Default relay policy for Core essentially controls what ends up in the blockchain and what doesn’t. It’s pointless to keep pretending otherwise.
If tests aren’t breaking, a good place to start would be to write a test that breaks on these changes, then fix them in feature commit. As of now, nothing breaks which is concerning.
The original commit did break the test p2p_ibd_txrelay.py. I then shared a PR to robin’s repo which was squash commited and force pushed here, so each commit would pass the test. It was done as a squash commit after being advised to do so by @l0rinc
Every commit needs to pass CI independently,
I don’t think this PR changed the min relay fee (see all assert_equal(node.getmempoolinfo()["minrelaytxfee"], Decimal('0.00010000')) tests). A 0.1sat/vB tx is still rejected.
I agree the dust feerate is largely orthogonal, but the other minimum feerates are tied, hence autocorrection in mempool_args:
The incremental relay feerate, at least for RBF rule 4, should be the same as minrelaytxfee, since they represent the “price of bandwidth per vb” for transaction relay. Arguably we should price bandwidth for relaying the replacements as the same as the original. I haven’t thought much about what it would look like to use evicted+0.1sat/vB for setting mempoolminfee, but probably good to write up an argument for why that’s fine.
Also, -blockmintxfee should never be higher than -minrelaytxfee, as it would cause you to accept and relay transactions that you would never mine.
The most persuasive argument for this would be that miners have diverged from defaults
You continue to confuse cause and effect. Miners mine what gets relayed, not the reverse.
Default relay policy for Core essentially controls what ends up in the blockchain and what doesn’t. It’s pointless to keep pretending otherwise.
Neither Bitcoin Core, nor Knots, not even LibreRelay nodes relay transactions below 1 s/vB by default. Only some manually configured nodes do, and yet we see them get included in blocks. It’s basically impossible to have a higher degree of filtering and yet it is ineffective. Repeating your wishful thinking like a mantra does not make it true.
The most persuasive argument for this would be that miners have diverged from defaults
You continue to confuse cause and effect. Miners mine what gets relayed, not the reverse. Default relay policy for Core essentially controls what ends up in the blockchain and what doesn’t. It’s pointless to keep pretending otherwise.
Neither Bitcoin Core, nor Knots, not even LibreRelay nodes relay transactions below 1 s/vB by default. Only some manually configured nodes do, and yet we see them get included in blocks. It’s basically impossible to have a higher degree of filtering and yet it is ineffective. Repeating your wishful thinking like a mantra does not make it true.
It’s not an all-or-nothing thing as you’re characterizing it.
Reducing
DEFAULT_MIN_RELAY_TX_FEEonly makes sense to me in conjunction with reducingDEFAULT_BLOCK_MIN_TX_FEE. Otherwise nodes become subject to free relay attacks that could be used to waste bandwidth across the network with transactions that are not even in danger of getting mined in most blocks.
DEFAULT_INCREMENTAL_RELAY_FEEshould be decreased along with this as well.That’s probably a bad idea, as it would increase the surface for bandwidth wasting attacks 10× even on top of what dropping the
DEFAULT_MIN_RELAY_TX_FEEwould do.While I’m sympathetic to users wanting to transact (and especially consolidate) at lower feerates whenever blockspace demand is as low as it currently is, this drops a full block’s minimum transaction fees to ~100,000 sats, or about ~0.03% of the current subsidy. That seems like the wrong signal when the ecosystem’s long-term roadmap relies on transaction fees eventually funding mining.
If this idea gets traction, perhaps it would be interesting to combine a reduction of the minimum relay transaction fee rate with shifting the denomination of fee rates to sats/WU and setting a new minimum relay transaction fee rate to 100 sats/kWU instead which would be 0.4 sats/vB rather than 0.1 sats/vB.
So why not increase it to 10 sats/vB—reducing bandwidth consumption by 10×, making the network 10× more resilient to spam, and sending the right economic signal for long-term sustainability? I understand the opinion of some core devs, but you can’t force people to pay higher fees unless it’s a consensus rule. Miners, wallets, and sub-1 sat transactions only highlighted an obvious economic incentive.
So why not increase it to 10 sats/vB—reducing bandwidth consumption by 10×, making the network 10× more resilient to spam, and sending the right economic signal for long-term sustainability?
Because especially with arbitrary values, the onus is on the person attempting to change it. Constantly fiddling with the default value is also not really a sustainable option even if we somehow found a new “optimal”. If we enter a 90% drawdown bear market, we aren’t going to revisit this value and raise it, are we?
I understand the opinion of some core devs, but you can’t force people to pay higher fees unless it’s a consensus rule.
No one is forcing anyone to do anything, hysterics do not help.
Because especially with arbitrary values, the onus is on the person attempting to change it. Constantly fiddling with the default value is also not really a sustainable option even if we somehow found a new “optimal”. If we enter a 90% drawdown bear market, we aren’t going to revisit this value and raise it, are we?
Perhaps the solution lies not simply in arbitrarily adjusting technical parameters, but rather in adopting rules that better align the economic incentives of all network participants. Bitcoin’s long-term sustainability depends on both economic theory and technical engineering.
A fixed limit of 1 sat/vB may make spam attacks more expensive initially, but it also has the side effect of blocking legitimate transactions from users trying to use the network during times of low demand.
Instead of setting a fixed value, why not use rules such as a mempool size limit and only accepting new transactions with higher fees, based on the actual pressure for block space? An attacker, in this scenario, would need to compete with legitimate transactions, naturally increasing the minrelay fee and, thus, the cost of the attack itself.
This approach doesn’t require deciding on a new (arbitrary) value; it simply aligns relay rules with the network’s current economic incentives, making the system more adaptive and efficient.
I understand the opinion of some core devs, but you can’t force people to pay higher fees unless it’s a consensus rule.
No one is forcing anyone to do anything, hysterics do not help.
If we enter a 90% drawdown bear market, we aren’t going to revisit this value and raise it, are we?
Plus, we wouldn’t be able to at all for software that is already released. Better have a conservative value that is resistant to an asset price decrease than an optimistic value that tries to captivate very low fees in times of high asset prices and low usage.
I am not against lowering the minrelay value, especially if it is shown that there is sustained usage of sub-1sat/vb transactions that get included by miners. But i agree with @instagibbs that this is a non-trivial change for little gains and the onus is on the supporters of the change.
Also, i don’t think there is a good reason for decreasing the incremental relay fee at the same time as the min relay fee.
A naive question I have is how does this relate to another policy change like mempoolfullrbf? We currently have 20% of hashrate now mining sub 1 sat/vbyte (source) and some mining pools are leaving revenue on the table due to not having the right mempool policy (source), couldn’t the argument be made that some mining pools are being advantaged by using the default values?
A fair counter point is, this explicit change by definition is over a de minimis amount of revenue (1.8 million sats in fee revenue in a full block on the high end). Maybe it is ok to leave some money on the table by running defaults, because a high demand of this transaction type would never result in a material amount of missed revenue?
The most persuasive argument for this would be that miners have diverged from defaults
You continue to confuse cause and effect. Miners mine what gets relayed, not the reverse. Default relay policy for Core essentially controls what ends up in the blockchain and what doesn’t. It’s pointless to keep pretending otherwise.
Neither Bitcoin Core, nor Knots, not even LibreRelay nodes relay transactions below 1 s/vB by default. Only some manually configured nodes do, and yet we see them get included in blocks. It’s basically impossible to have a higher degree of filtering and yet it is ineffective. Repeating your wishful thinking like a mantra does not make it true.
It’s not an all-or-nothing thing as you’re characterizing it.
Your claim was that “default relay policy for Core essentially controls what ends up in the blockchain and what doesn’t.” The default policy of all popular node implementations is to reject transactions below 1 s/vB. As we still see transactions propagate on the network and published in blocks (assuming you accept these obvious facts), your assessment that “default relay policy for Core essentially controls what ends up in the blockchain and what doesn’t” is obviously falsified.
It’s not an all-or-nothing thing as you’re characterizing it.
Now you are accusing me of your own argument’s demerit claiming that my statement was lacking nuance when yours was trivially false due to being overly general.
your assessment that “default relay policy for Core essentially controls what ends up in the blockchain and what doesn’t” is obviously falsified.
It obviously remains true, you’re just cherry picking. Again, the vast, overwhelming, super-super majority of what you see in the chain is what nodes will typically relay due to whatever Core’s defaults are.
This is not an “overly general” statement, it’s a fact that - I’m sorry to have to point out - is being ignored because that is convenient for the recent agenda to keep removing filters along with the justification that they “don’t do anything” when they clearly do.
A contrived scenario in which a whole bunch of transactions start hitting the chain which violate a default a Core filter is not conclusive proof otherwise.
It’s not obvious that the price going up 10x means we get to lower the default by 10x, because it’s a more important system now and the stakes are simply higher.
Sure, though at the same time the situation being discussed here isn’t price up 10x means default down 10x. Compared to when this was last adjusted the price is up 500x and this proposes down by 10x. :P The magnitudes matter– particularly in that it answers your drawdown comment: Even if bitcoin prices drop by 90% they’ll still be 50 times higher than where the current value was established.
One should be wary of fixating more on the status quo state while disregarding the status quo reasoning. If, at the time the figure was set, you had asked “But what happens if later bitcoin is trading at 100x what it is now?” you would have gotten a (near-)unanimous and hesitation free “then the setting can be adjusted down 100x”. And so I think those arguing to change the principle ought to have some burden in justifying what the new principle is or saying outright that their position is just an unprincipled dedication to inaction! :P
I think a useful way to think about this setting is that it should have no effect on average, but only truncate out some exceptional/dossy behavior… The anti-dos mechanisms in the Bitcoin protocol are degenerate at a feerate of 0 (or arbitrarily close to zero), so the effective feerate must not fall to zero even during periods of low demand. That’s the primary reason why minrelay fee exists.
There is a secondary reason it exists: It turns out that there is a dysfunction in wallet/user behavior around the transition between zero-fees and some-fees, because having to manage paying some fees requires software and accounting affordances for choosing/managing/controlling those fees so when the network has transitioned from a period of no fees to fees it has been extremely disruptive.
I think on both of those basises it would be obviously correct to reduce the limit now. I suspect we initially set the value too low (in purchasing power terms) in prior adjustments (out of caution)– close enough to zero that it didn’t quite achieve its purpose, which would be a reason to not reduce it 500 fold. Going 10 fold sounds reasonably conservative, though given that its hard to go backwards it might be sensible to first reduce 5 fold to a value of 200– which would still leave the rate in purchasing power terms more than 50x higher than when it was last adjusted.
I think ideally this parameter would just track some longtime floor of what actually gets mined but since it results in stuck/unrelayable transactions when it goes up I don’t think it’s particularly safe to automate.
If someone wanted to rationalize the setting in more detail it might be interesting to see a scatter plot of the volume of dusting-attack (ones that pepper wallets with dust payments that are worthless to spend) vs minfeerate-in-USD (or some other economic unit to cancel out changes demand for Bitcoin). It may be possible to see a rate under which dust attacks are far more common, and if so I think a good case could be made for keeping the setting above that threshold.
If this logical relationship is abandoned, it would be better to explain why and what is the economic rationale behind the determination of the value defining the “dust limit”.
A point of correction, the link you’ve provided is looong after the dust limit was implemented, but instead was a change making it independently configurable. You’re correct about their historical relationship in the software, however. It’s obviously harmful for the system to allow creating outputs that have negative value at future prevailing feerates. The setting vs minimum relay fee though doesn’t actually model the goal because hopefully min_relay fee is always somewhat below prevailing rates.
Both limits have problems with upwards adjustment, as it results in stuck transactions. Though I think it’s worse to have too low a dust limit than too low a minrelay fee because the latter also has dynamic management through mempool eviction– so at least when there is a substantial backlog the effective relayfee limit will temporarily go up.
And probably any revision of either should decouple them since it would not make sense to decrease the dust limit unless it appeared that future prevailing rates decreased, and reduction of the minimum fee for relay may have only a small or no significant effect on prevailing rates and in any case whatever effect it may have will be lagging. You don’t want a situation where both are halved (say) but then it turns out that the cost of spending an output even during low demand periods only went down 5% and the system is now belting out effectively unspendable outputs, but increasing the dust limit would result in a bunch of stuck transactions.
If, at the time the figure was set, you had asked “But what happens if later bitcoin is trading at 100x what it is now?” you would have gotten a (near-)unanimous and hesitation free “then the setting can be adjusted down 100x”
I don’t think I was around then, so maybe or maybe not :)
I assume the same logic holds for incremental rate?
There is a secondary reason it exists
Not sure I understood this point.
I assume the same logic holds for incremental rate?
I think that the incremental rate, like dust limit, would in an ideal world be just a pure function of the “actual” feerate, but we don’t have access to the actual feerate and the actual rate is fluctuating while it’s preferable for these to be more stable so the minrelay fee gets used as a proxy.
Not sure I understood this point.
If there is a sustained period of low demand (such that few blocks are full) then absent artificial limits like minfeerate wallet functionality and user business practices for assessing and controlling fees paid can atrophy, as managing fees requires extra complexity. Then when fee’s reemerge stuff catches fire because software and practices aren’t able to accommodate paying any fees at all (or anything but some infinitesmal static amount) . I think that it’s another reason why it’s preferable to have a minfeerate even when its not needed to make the anti-DOS stuff work. For it to have the effect it’s sufficient that the minimum rate is high enough in real terms that developers won’t respond by just statically paying some multiple of it.
Maybe it’s a weak point, but I was trying to capture the early/original reasons for the limit to try to test the idea of reducing the limit (in BTC terms) against them.
One should be wary of fixating more on the status quo state while disregarding the status quo reasoning. If, at the time the figure was set, you had asked “But what happens if later bitcoin is trading at 100x what it is now?” you would have gotten a (near-)unanimous and hesitation free “then the setting can be adjusted down 100x”. And so I think those arguing to change the principle ought to have some burden in justifying what the new principle is or saying outright that their position is just an unprincipled dedication to inaction! :P
I think a useful way to think about this setting is that it should have no effect on average, but only truncate out some exceptional/dossy behavior… The anti-dos mechanisms in the Bitcoin protocol are degenerate at a feerate of 0 (or arbitrarily close to zero), so the effective feerate must not fall to zero even during periods of low demand. That’s the primary reason why minrelay fee exists.
Sorry if this is not the ideal place to ask but would creating a secondary mempool of ~10 MB in Bitcoin Core only during low-demand periods, for network-beneficial transactions such as UTXO consolidation (≥ 5 inputs, ≤ 2 outputs), batching, or fees below the minrelaytxfee (< 1 sat/vB), be too complex? These transactions would be included in blocks only during low-demand periods, after the main mempool.
DUST_RELAY_TX_FEE should be decreased along with this as well…
DEFAULT_MIN_RELAY_TX_FEE and DUST_RELAY_TX_FEE serve different purposes. The former is about protecting the P2P network, while the latter also aims at protecting the UTXO set from DoS attacks. Given that half of the UTXO set is spam these days, it seems like the dust limit should rather get increased than decreased. So it’s a whole different discussion, and I would not want to conflate these two in this PR.
The issue is they are conceptually linked for a reason. Even if not explicitly tied together in code it doesn’t make sense to separate them.
Also, i don’t think there is a good reason for decreasing the incremental relay fee at the same time as the min relay fee.
If DEFAULT_INCREMENTAL_RELAY_FEE is not lowered along with DEFAULT_MIN_RELAY_TX_FEE, users will be forced to pay fees above the estimates during periods of low transaction demand. It’s as if DEFAULT_INCREMENTAL_RELAY_FEE were now effectively set to 10,000 sat/kvB.
That’s exactly what I’m seeing. Yesterday I broadcast a transaction with a 0.2 sat/vB fee, and within about one minute it had propagated to mempool.space’s node. A short while ago I sent an RBF with a 0.5 sat/vB fee, waited 30 minutes, and it still hadn’t reached mempool.space’s node. I then used Broadcast Transaction to push the RBF directly and got this response: “Failed to broadcast transaction, reason: insufficient fee, rejecting replacement TXID, not enough additional fees to relay; 0.00000033 < 0.0000011”.
you can’t force people to pay higher fees unless it’s a consensus rule
I think even if consensus rules would dictate fees, then it would still be possible to bypass them. For example: users can sign a given transaction, only if the next one would send them their coins back. Which means, that if free transactions would be consensus rule, then users would use additional anchor-like outputs to pay to miners. And if 100% fee transactions would be required by consensus, then miners could still send coins back to the users inside the coinbase transaction.
A fixed limit of 1 sat/vB may make spam attacks more expensive initially, but it also has the side effect of blocking legitimate transactions from users trying to use the network during times of low demand.
In general, low-fee transactions should be batched, and pushed on-chain as high-fee transactions. Which means, that 10 users, paying below 1 sat/vB, can consolidate their coins, and make a transaction, which would appear as at least 1 sat/vB on-chain. When we have 1 sat/vB, then miners are guaranteed to get at least 0.01 BTC in fees per block, as long as blocks are full, and users are willing to transact. By lowering that limit, it may cause problems, when next halvings will lower the basic block reward.
So, to sum up: I think it is better to leave 1 sat/vB limit unchanged, and focus on batching low-fee transactions instead. Because otherwise, it would mean, that people decided to scale only on-chain, and to allow decreasing minimal fee rates arbitrarily low in the future (or maybe even unlocking free transactions at some point in time; because even if you allow free transactions now, then other limits will still protect you from many DoS attacks).
When we have 1 sat/vB, then miners are guaranteed to get at least 0.01 BTC in fees per block
This is only correct if there are enough 1+ sat/vB transactions to fill the block. Miners are free to set their own minimum fee policy, and if some “fee market bidders” (transactors) are unwilling to pay 1 sat/vB and some “fee market buyers” (miners) are willing to mine at less than 1 sat/vB, miners who aren’t willing to mine at less than 1 sat/vB blocks would be mining less-than-full blocks instead when there are not enough 1+ sat/vB transactions in the mempool, leaving money on the table.
Furthermore, seeing as some miners are evidently willing to mine at less than 1 sat/vB, we should start seeing more and more transactions paying less. If the default mempool policy doesn’t align with the transactions being mined, this will reduce the effectiveness of compact blocks (one of the leading causes of the recent full-RBF change), since these transactions will not be present in most mempools and will therefore have to be retrieved during validation. It can also potentially cause miner centralization, since people will be sending these transactions directly to the miners that are known to mine them, while smaller miners might not see the transactions at all since they are being eaten by mempool policy, so they will not even have the option to mine them.
You could argue that changing the defaults might lower the average transaction fee during off-hours, but most transactions pay more than today’s minimum of 1 sat/vB, so it’s hard to argue one way or the other how significantly it would affect the average fee. And while everyone is entitled to their own opinion, with the current price, low-priority consolidation transactions at 1 sat/vB are on the order of 10 cents per input minimum with the most economic transaction types, which seems high to me.
What about rpc calls that currently only alow minimum value of 1 sat/vb?
eg: https://developer.bitcoin.org/reference/rpc/bumpfee.html Should those endpoints be changed at the same time as the min relay fee?
In general, low-fee transactions should be batched, and pushed on-chain as high-fee transactions. Which means, that 10 users, paying below 1 sat/vB, can consolidate their coins, and make a transaction, which would appear as at least 1 sat/vB on-chain. When we have 1 sat/vB, then miners are guaranteed to get at least 0.01 BTC in fees per block, as long as blocks are full, and users are willing to transact. By lowering that limit, it may cause problems, when next halvings will lower the basic block reward.
While batching transactions does improve space efficiency, it doesn’t bypass the minimum fee rate requirement — the total fee still needs to meet or exceed 1 sat/vB relative to the transaction’s size. So even when transactions are combined, users still effectively have to pay the same per-byte fee.
Additionally, there’s currently no practical or widely adopted decentralized way for users to coordinate such batching. Most batching today happens within centralized services like exchanges or custodial wallets, where a single party controls multiple outputs. Without centralized coordination, relying on batching doesn’t solve the problem of high minimum fee rates for ordinary users.
The mempool is already constrained by DEFAULT_MAX_MEMPOOL_SIZE_MB, which prevents unbounded transaction accumulation and significantly reduces the feasibility of relay-based DoS attacks. Historically, the network has operated reliably even during extended periods of mempool congestion, where dynamic fee pressure naturally evicts lower-fee transactions.
This proposed configuration provides a practical balance between usability and relay robustness:
0static constexpr unsigned int DEFAULT_MIN_RELAY_TX_FEE{100}; // 0.1 sat/vB
1static constexpr unsigned int DEFAULT_INCREMENTAL_RELAY_FEE{400}; // 0.4 sat/vB
No clear DoS vector is introduced by this change that doesn’t already require significant real-world cost and effort from an attacker.
Sure, though at the same time the situation being discussed here isn’t price up 10x means default down 10x. Compared to when this was last adjusted the price is up 500x and this proposes down by 10x. :P
Previous settings have been:
(Going by commit dates rather than merge/release dates)
These changes were largely irrelevant to people making transactions however, since most wallets were setting fees to a flat rate per transaction (eg, 10000 sats, independent of the transaction size) prior to 2016.
The rationale for the 5sat-to-1sat change was the cost of relaying a tx across the network – 1kB of data across 100k nodes is at least 100MB of data, at 10c/GB (contemporary ec2 bandwidth pricing) is 1c total; and 1000sats at $250/BTC 0.25c total. Today, ec2 prices don’t seem much different, and node counts aren’t much higher, so at current prices, paying for relay would be closer to 0.01sat/vb. A rate of 0.1sat/vb would cover growing the node count to 1M nodes, and 1sat/vb would cover growing the node count to 10M nodes. So from a “free relay” perspective, I think 0.1 sat/vb is likely fine, both for min-fee and min-incremental-fee. If the p2p network grows to much more than 1M nodes, that might not be true though.
A full block of min fee txs would currently set fees at 0.32% of the total block reward; dividing that by 10 will delay hitting 1% from being ~7 years away to ~20 years away. If you’re looking towards keeping hashrate reltively stable in an environment where the BTC price stabilises instead of continuing to more than double every four years, this is probably a step backwards, and setting an expectation that it fees will either decrease in BTC terms or stay stable in fiat/real terms is probably misleading, even in the medium term.
Likewise if you’re looking to maximise miner revenue: it’s better to mine 101kvB of 1sat/vb txs than 1MvB of 0.1sat/vb txs. But if miners want transactors to be subsidised even more than they already are, I guess that’s their business.
In any event, I think not accepting these txs for relay significantly affects block relay, both due to not already having the transaction data already downloaded and having to validate their signatures in the critical path to accepting the block.
I’ve started seeing CPU spikes on one of my nodes which I think is a result of this (I don’t find it particularly concerning since that node (a) runs a debug build which does extra processing, (b) accepts significantly more connections than the default, and (c) runs on a small/slow VPS); those spikes seem to have been resolved by accepting the lower fee txs, though time will tell.
Personally, I’m pretty disappointed at the lack of any attempt to justify and coordinate this change it in advance to avoid hitting problems in practice. Huge amounts of FAFO energy these days.
Reducing
DEFAULT_MIN_RELAY_TX_FEEonly makes sense to me in conjunction with reducingDEFAULT_BLOCK_MIN_TX_FEE.
Reducing the default minimum relay feerate is safe if we’re confident that plenty of hash power is in fact mining those transactions. The block minimum tx feerate default does not need to be tied to that change if you think of it in terms of a recommendation for profitability: while miners may choose to mine transactions with feerates so low that they may be losing subsidy revenue on stales, there’s no reason to do it by default. Besides, worst case is that your mempool will fill up with low feerate junk that no-one is mining, eventually hitting the size limit, and the problem will mostly fix itself as the minimum is increased automatically.
Meanwhile, decreasing the default relay feerate in a world where plenty of blocks do in fact have those transactions in them will decrease propagation time and reduce stales for everyone because it’ll improve block reconstruction rates.
So no, I don’t think we need to necessarily tie those two parameters together.
Finally, it’d be good to get some data on sub-1sat/vB-delta RBF replacements. My Alice and Bob OpenTimestamps calendars are producing them. But I don’t know if anything else is.
A full block of min fee txs would currently set fees at 0.32% of the total block reward; dividing that by 10 will delay hitting 1% from being ~7 years away to ~20 years away. If you’re looking towards keeping hashrate reltively stable in an environment where the BTC price stabilises instead of continuing to more than double every four years, this is probably a step backwards, and setting an expectation that it fees will either decrease in BTC terms or stay stable in fiat/real terms is probably misleading, even in the medium term.
This discussion is getting close to being off topic. You’re really discussing the wider problem of how to pay for mining security going forward. Given how many miners have started mining sub-1sat/vB transactions, even when no widely deployed fork of Bitcoin Core relays them by default, it’s clear that the forces at play here are purely economic. There’s nothing we can do in Core to entice higher fee revenue if market dynamics simply don’t provide a reason for that fee revenue to exist; we’ve done an excellent job of decoupling transactional use of Bitcoin with on-chain transaction fees, and we’re only going to do an even better job of that in the future as L2 systems like Lightning and Ark are even further deployed. Anything Core tries to do here is almost certainly going to take the form of some kind of censorship/filtering of low feerate transactions, and that clearly does not work.
Obviously, there’s another solution that has worked so far for reliably paying for mining security, taxation of BTC savings. But discussion of the economics of that (and fee revenue) really belongs on venues like the mailing list. Not this PR.
As hinted by @glozow above, mempool_opts.min_relay_feerate is set automatically to the minimum of incrementalrelayfee and minrelaytxfee, so to lower the minimum feerate for what is accepted into a node’s mempool, which means that either DEFAULT_INCREMENTAL_RELAY_FEE also has to be lowered or the two need to be decoupled. I would still maintain that relaying things that aren’t mined by default would be odd, and so it sounds to me that lowering the DEFAULT_MIN_RELAY_TX_FEE would entail also lowering DEFAULT_INCREMENTAL_RELAY_FEE and DEFAULT_BLOCK_MIN_TX_FEE.
The following PRs might be interesting to the people developing this PR: