The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/32959.

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

No conflicts as of last run.

DEFAULT_INCREMENTAL_RELAY_FEE should be decreased along with this as well.

Looks like p2p_ibd_txrelay.py test needs updating.

DEFAULT_INCREMENTAL_RELAY_FEE should 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?

Looks like p2p_ibd_txrelay.py test needs updating.

Dropped in a PR here to add testing so this passes.

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?

Concept ACK

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.

small nit: The PR description should rather point to this commit: 9e93640

Better to (also) point to #6722 as it has the discussion from back then.

DUST_RELAY_TX_FEE should be decreased along with this as well...

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.

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

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.

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 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:

static constexpr unsigned int DEFAULT_MIN_RELAY_TX_FEE{100};       // 0.1 sat/vB
static constexpr unsigned int DEFAULT_INCREMENTAL_RELAY_FEE{400};  // 0.4 sat/vB

• Allows low-priority transactions to be relayed when mempool space is available during low-demand periods.
• Keeps RBF functional in low-fee environments without requiring large fee bumps.
• Remains protected by eviction policies, ancestor/descendant limits, and the overall mempool cap.

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:

• 2015/10/13 - 5sat/vb to 1sat/vb
  • $250/BTC
  • 1sat*200vb = 0.5c
  • 1sat/vb*1Mvb/25BTC = 0.04% of block reward
• 2015/10/09 - 1sat/vb to 5at/vb
  • $250/BTC
  • 5sat*200vb = 2.5c
  • 5sat/vb*1Mvb/25BTC = 0.2% of block reward
• 2013/04/13 - 10sat/vb to 1sat/vb
  • $120/BTC [edit: found a different price source that doesn't seem as crazy]
  • 10sat*200vb = 0.024c
  • 10sat/vb*1Mvb/25BTC = 0.4% of block reward

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

@RobinLinus do you plan on addressing review here? Reminder that feature freeze is less than a month from now.

@murchandamus

Reducing DEFAULT_MIN_RELAY_TX_FEE only makes sense to me in conjunction with reducing DEFAULT_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.

@ajtowns

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:

• Lower default relay fees #13922
• Allow fee estimation to work with lower fees #13990

Since similar arguments keep coming up: The sole purpose of the minimum relay fee should be DoS protection. Trying to fix the security budget by imposing administered prices on block space seems misguided—market forces will likely circumvent such price controls and make things worse in the process.

Maybe the intent of my comment wasn’t clear. We are seeing that blocks including lower feerate transactions take significantly longer to get propagated, and the way I’m reading the sentiment here, a lot of people do not share my concern over a potential DoS protection reduction. In so far, it seems that there is at least interest in this PR being further developed. My suggestion is that if someone were to address the review feedback here, they should probably lower all three settings, not just the one. However, this breaks a dozen tests or so, there seem to be some more missing that it should be breaking, and feerate estimation currently doesn’t do below 1 s/vB, so this PR might be more involved than it seems at first glance.

Regarding the expectations around feerates, my concern is rather that overly cheap blockspace fosters the creation of some use cases that will inherently get priced out in the long run again, so facilitating the oddly low feerates at this time may set us up for a social backlash later down the road. OTOH, people getting outspent is a pretty clear signal that might speak for itself clearly enough.

feerate estimation currently doesn’t do below 1 s/vB, so this PR might be more involved than it seems at first glance

IMHO it would probably be reasonable to stagger changes to wallet/fee estimation for one release, and only change the thresholds for mempool/relay and possibly mining initially. Based on some stats from my own nodes, I would assume that relaying sub-1 sat/vB transactions will still be spotty for some time after a new version with changed defaults is released.

Node 1: Of 199 connected nodes, 146 set a minfeefilter; 141 are using the default, while 5 are 100 sats/vkB or below. 45 nodes are running 29.x

Node 2: Of 188 connected nodes, 138 set a minfeefilter; 134 are using the default, while 4 are 100 sats/vkB or below. 42 nodes are running 29.x

In other words, 95%+ of nodes are using the default relay thresholds, and ~25% are on 29.x three months after release. So for nodes with fewer connections, lower-fee transactions might not reliably propagate for some time unless you actively seek out nodes that will accept them. (For comparison, Bitnodes is reporting 16.95% on 29.0.0.)

There are quite a few nodes that do not set a minfeefilter, but I would assume that most of those are either non-relaying spy nodes that I failed to block, or older nodes that predate this filter but that still won't relay transactions with lower fees.

@RobinLinus, are you planning on working on this?

@RobinLinus, are you planning on working on this?

I'm interested in working on this, but I'm currently too busy moving apartments. I plan to revisit it in about two weeks. In the meantime, it would be greatly appreciated if someone could help fix the tests that fail when adjusting DEFAULT_BLOCK_MIN_TX_FEE.

should probably lower all three settings, not just the one. However, this breaks a dozen tests or so, there seem to be some more missing that it should be breaking, and feerate estimation currently doesn’t do below 1 s/vB

@murchandamus I'm busy with this to make some progress while @RobinLinus is away, what's the process - create a new PR as a continuation of this one?

When you say "there seem to be some more missing that it should be breaking" - what do you mean?

Concept ACK.

@delta1 i would suggest picking up #13990 and #13922. In this order, or make a good argument why it would be fine to lower the settings without first making the fee estimation be compatible.

Feel free to ping me for review, i think this is important it makes it into the next release. I'm managing expectations however since, as it's been pointed out multiple times already, this is a lot less trivial than some people in this thread seem to assume.

@darosior thanks I intend to make fee estimation work correctly as well

should probably lower all three settings, not just the one. However, this breaks a dozen tests or so, there seem to be some more missing that it should be breaking, and feerate estimation currently doesn’t do below 1 s/vB

@murchandamus I'm busy with this to make some progress while @RobinLinus is away, what's the process - create a new PR as a continuation of this one?

Given that this branch is on Robin’s repository, it would be the easiest to create your own branch and PR (unless you are working with Robin on it and are talking about making a pull request to his branch). Please be sure to address the comments from this PR on your new PR.

When you say "there seem to be some more missing that it should be breaking" - what do you mean?

I was referring to what instagibbs said above:

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.

@delta1 i would suggest picking up #13990 and #13922. In this order, or make a good argument why it would be fine to lower the settings without first making the fee estimation be compatible.

I don't think fee estimation should be a blocker for the relay change. If anything, the reverse: while sub-1sat/vb txs don't relay well, it would be annoying if your fee estimates dropped resulting in your txs also not relaying well.

You could get the best of both worlds by fixing fee estimation first, then having a hardcoded flag day when the default relay fee automatically drops, but that ship has probably sailed.

Concept NACK. Everything below 1s/vB is spam. There's no reason to change the default.

Over that period the USD price of BTC has risen by roughly 2-3 orders of magnitude,

It's the USD that has fallen, Bitcoin has remained more or less the same.

This maintains DoS resistance without discouraging low-value UTXO consolidation.

DoS resistance is clearly insufficient even at 1s/vB.

Also, this logically implies a reduction of the dust limit, making spam attacks even worse on that front.

Actually, Bitcoin probably hasn't even kept up its value, so if anything we should be looking to increase the default relay fee, if maintaining the same actual-value cost is the goal.

Luke isn't wrong if runes and inscriptions are considered spam. Minimum fee is still above 1 sat/vbyte in most blocks and sub 1 sat/vbyte fee rate is mostly used by runes and inscription transactions.

It's irrelevant whether or not anyone considers any transaction "spam", all that matters is if miners are mining them, and they are. At the time of this writing, looking back at the last three days worth of blocks, there are about 100 blocks containing <1 sat/vB transactions, and the only pools that have mined blocks with empty space instead of these transactions are ViaBTC and WhitePool.

All you accomplish by rejecting transactions that are getting mined is slowing down block propagation, and potentially wasting CPU cycles and bandwidth by downloading and processing the transaction twice. People who really want to do this are of course free to override the config, but doing it by default is detrimental.

It's irrelevant whether or not anyone considers any transaction "spam", all that matters is if miners are mining them, and they are.

Of course it's relevant if we're discussing what we relay and what we don't.

All you accomplish by rejecting transactions that are getting mined is slowing down block propagation, and potentially wasting CPU cycles and bandwidth by downloading and processing the transaction twice.

Completely false. It's sad to see such obvious dishonesty in here.

Closing this, in favour of #33106 (this can't be merged as is, and author is unavailable).