policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee

glozow commented at 6:06 pm on July 31, 2025: member

ML post for discussion about the general concept, how this impacts the wider ecosystem, philosophy about minimum feerates, etc: https://delvingbitcoin.org/t/changing-the-minimum-relay-feerate/1886

This PR is inspired by #13922 and #32959 to lower the minimum relay feerate in response to bitcoin’s exchange rate changes in the last ~10 years. It lowers the default -minrelaytxfee and -incrementalrelayfee, and knocks -blockmintxfee down to the minimum nonzero setting. Also adds some tests for the settings and pulls in #32750.

The minimum relay feerate is a DoS protection rule, representing a price on the network bandwidth used to relay transactions that have no PoW. While relay nodes don’t all collect fees, the assumption is that if nodes on the network use their resources to relay this transaction, it will reach a miner and the attacker’s money will be spent once it is mined. The incremental relay feerate is similar: it’s used to price the relay of replacement transactions (the additional fees need to cover the new transactions at this feerate) and evicted transactions (following a trim, the new mempool minimum feerate is the package feerate of what was removed + incremental).

Also note that many nodes on the network have elected to relay/mine lower feerate transactions. Miners (some say up to 85%) are choosing to mine these low feerate transactions instead of leaving block space unfilled, but these blocks have extremely poor compact block reconstruction rates with nodes that rejected or didn’t hear about those transactions earlier.

While it wouldn’t make sense to loosen DoS restrictions recklessly in response to these events, I think the current price is higher than necessary, and this motivates us changing the default soon. Since the minimum relay feerate defines an amount as too small based on what it costs the attacker, it makes sense to consider BTC’s conversion rate to what resources you can buy in the “real world.”

Going off of this comment and this comment

Let’s say an attacker wants to use/exhaust the network’s bandwidth, and has the choice between renting resources from a commercial provider and getting the network to “spam” itself it by sending unconfirmed transactions. We’d like the latter to be more expensive than the former.
The bandwidth for relaying a transaction across the network is roughly its serialized size (plus relay overhead) x number of nodes. A 1000vB transaction is 1000-4000B serialized. With 100k nodes, that’s 0.1-0.4GB
If the going rate for ec2 bandwidth is 10c/GB, that’s like 1-4c per kvB of transaction data
Then a 1000vB transaction should pay at least 4c
$0.04 USD is 40 satoshis at 100k USD/BTC
Baking in some margin for changes in USD/BTC conversion rate, number of nodes (and thus bandwidth), and commercial service costs, I think 50-100 satoshis is on the conservative end but in the right ballpark
At least 97% of the recent sub-1sat/vB transactions would be accepted with a new threshold of 0.1sat/vB: #33106 (comment)

List of feerates that are changed and why:

min relay feerate: significant conversion rate changes, see above
incremental relay feerate: should follow min relay feerate, see above
block minimum feerate: shouldn’t be above min relay feerate, otherwise the node accepts transactions it will never mine. I’ve knocked it down to the bare minimum of 1sat/kvB. Now that we no longer have coin age priority (removed in v0.15), I think we can leave it to the CheckFeeRate policy rule to enforce a minimum entry price, and the block assembly code should just fill up the block with whatever it finds in mempool.

List of feerates that are not changed and why:

dust feerate: this feerate cannot be changed as flexibly as the minrelay feerate. A much longer record of low feerate transactions being mined is needed to motivate a decrease there.
maxfeerate (RPC, wallet): I think the conversion rate is relevant as well, but out of scope for this PR
minimum feerate returned by fee estimator: should be done later. In the past, we’ve excluded new policy defaults from fee estimation until we feel confident they represent miner policy (e.g. #9519). Also, the fee estimator itself doesn’t have support for sub-1sat/vB yet.
all wallet feerates (mintxfee, fallbackfee, discardfee, consolidatefeerate, WALLET_INCREMENTAL_RELAY_FEE, etc.): should be done later. Our standard procedure is to do wallet changes at least 1 release after policy changes.

DrahtBot commented at 6:06 pm on July 31, 2025: contributor

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/33106.

Reviews

See the guideline for information on the review process.

Type	Reviewers
ACK	caesrcd
Concept NACK	Retropex, luke-jr, 1ma, KurtisStirling
Concept ACK	delta1, benthecarman, jlopp, w0xlt, aeonBTC, fjahr, murchandamus, ArmchairCryptologist, darosior, petertodd, stickies-v
Approach ACK	ajtowns, jsarenik

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

Conflicts

Reviewers, this pull request conflicts with the following ones:

#28676 (Cluster mempool implementation by sdaftuar)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

glozow force-pushed on Jul 31, 2025

delta1 commented at 6:11 pm on July 31, 2025: none

Concept ACK

I have a wip branch where I’ve somewhat fixed a bunch of tests for this too, which I can share if you like @glozow

I was stuck on MockMempoolMinFee before having to do some dayjob work

(edit: wip branch: https://github.com/bitcoin/bitcoin/compare/master...delta1:bitcoin:reduce-minrelaytxfee)

DrahtBot added the label CI failed on Jul 31, 2025

DrahtBot commented at 6:12 pm on July 31, 2025: contributor

🚧 At least one of the CI tasks failed. Task lint: https://github.com/bitcoin/bitcoin/runs/47142796315 LLM reason (✨ experimental): The CI failure is caused by the lint check errors detected by ruff, specifically the Python code style issues that are currently unfixable, leading to lint test failure.

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.
A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.
An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

glozow added the label TX fees and policy on Jul 31, 2025

glozow added the label Mining on Jul 31, 2025

glozow commented at 6:54 pm on July 31, 2025: member

I have a wip branch where I’ve somewhat fixed a bunch of tests for this too, which I can share if you like @glozow

Thanks. Though I think I already fixed them, unless a fuzzer trips.

benthecarman commented at 7:01 pm on July 31, 2025: contributor

Concept ACK but I believe that the justification for this being the price went up is weak. This suggests also we may just lower it again in the future if the price goes down. Rather I think this is a good idea because it has become more common that blocks contain these transactions and this change makes bitcoin core’s mempool better reach its goals

glozow commented at 7:03 pm on July 31, 2025: member

Rather I think this is a good idea because it has become more common that blocks contain these transactions

See PR description, which includes both reasons. I also don’t think we should blindly lower the relay feerate to what miners seem to accept, as they can choose a price that is below what we determine the reasonable DoS threshold to be.

bitcoin deleted a comment on Jul 31, 2025

Retropex commented at 7:31 pm on July 31, 2025: none

NACK, without proper spam filters it will mostly be used by harmful spam.

jlopp commented at 8:00 pm on July 31, 2025: contributor

Concept ACK; this is effectively increasing economic scalability. If we can do so without reopening DoS vectors, that’s a win.

caesrcd commented at 8:04 pm on July 31, 2025: none

Concept ACK

The economic incentives are already evident: over 80% of the hashrate is mining transactions below 1 sat/vB, and the number of noderunners relaying transactions with fees below the current standard is increasing every day.

luke-jr commented at 8:30 pm on July 31, 2025: member

Again, 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 only increased relative to it. 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.

The minimum relay feerate is a DoS protection rule, representing a price on the network bandwidth used to relay transactions that have no PoW.

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

While relay nodes don’t all collect fees, the assumption is that if nodes on the network use their resources to relay this transaction, it will reach a miner and the attacker’s money will be spent once it is mined.

This assumption doesn’t hold without common-sense spam filters, that Core has neglected and begun to remove.

Contrast this with the dust feerate, which defines a value as “too small” based on Bitcoin’s protocol constraints on transaction volume (e.g. spend script size vs block space). The conversion rate is thus irrelevant or, at the very least, applies very differently in that context.

No, dust is defined as too small to be worth spending, which is a factor of fee rate to spend it. If the fee rate is 10x lower, the dust limit is logically 10x lower as well.

w0xlt commented at 8:41 pm on July 31, 2025: contributor

Concept ACK

caesrcd commented at 8:50 pm on July 31, 2025: none

@luke-jr

Everything below 1s/vB is spam.

That’s false. I recently made several consolidation transactions myself, all confirming at <1 sat/vB. Labeling everything below 1 sat/vB as “spam” ignores legitimate use cases like UTXO consolidation, which is actually beneficial for the network.

DrahtBot removed the label CI failed on Jul 31, 2025

aeonBTC commented at 9:20 pm on July 31, 2025: none

Concept ACK

In the past month, over 200,000 sub-1 sat/vB transactions were propagated and confirmed, despite a super majority of nodes not relaying them. This again demonstrates that market-driven blockspace demand and economic incentives consistently prevail over relay policies.

RobinLinus commented at 9:34 pm on July 31, 2025: none

It’s the USD that has fallen, Bitcoin has only increased relative to it.

Making such a bold claim—especially one that clearly contradicts observable reality—without any justification makes it seem like you’re just trolling. Bitcoin hasn’t only risen against the USD; it has also significantly outperformed gold, stocks, and nearly every other asset over the past decade.

in src/test/mempool_tests.cpp:538 in 7ed561063e outdated

537-    AddToMempool(pool, entry.Fee(1100LL).FromTx(tx6));
538-    AddToMempool(pool, entry.Fee(9000LL).FromTx(tx7));
539+    AddToMempool(pool, entry.Fee(700LL).FromTx(tx4));
540+    AddToMempool(pool, entry.Fee(100LL).FromTx(tx5));
541+    AddToMempool(pool, entry.Fee(110LL).FromTx(tx6));
542+    AddToMempool(pool, entry.Fee(90LL).FromTx(tx7));

fjahr commented at 9:39 pm on July 31, 2025:

This was reduced by a factor 100 and not by a factor 10 like all the other tests here. Probably a typo?

glozow commented at 1:55 pm on August 1, 2025:

Sharp, thanks!

fjahr commented at 9:39 pm on July 31, 2025: contributor

Concept ACK

in src/policy/policy.h:32 in 18dbc93f41 outdated

28@@ -29,7 +29,7 @@ static constexpr unsigned int DEFAULT_BLOCK_RESERVED_WEIGHT{8000};
29  * Setting a lower value is prevented at startup. */
30 static constexpr unsigned int MINIMUM_BLOCK_RESERVED_WEIGHT{2000};
31 /** Default for -blockmintxfee, which sets the minimum feerate for a transaction in blocks created by mining code **/
32-static constexpr unsigned int DEFAULT_BLOCK_MIN_TX_FEE{1000};
33+static constexpr unsigned int DEFAULT_BLOCK_MIN_TX_FEE{1};

murchandamus commented at 10:43 pm on July 31, 2025:

I was wondering why you decided to change the DEFAULT_BLOCK_MIN_TX_FEE to 1 s/kvB instead of 100 s/kvB and I couldn’t find a motivation in this commit or the main comment.

ajtowns commented at 4:50 am on August 1, 2025:

I think it makes sense (as a default) to always include things in blocks if they’re in your mempool. Otherwise having those txs in your mempool potentially blocks you from seeing txs you would include in your block (eg, double-spends that don’t pass rbf rules), and seems like something of a waste of memory/bandwidth (though not a DoS risk).

glozow commented at 1:14 pm on August 1, 2025:

I have this in the OP, but will add to commit message:

blockmintxfee shouldn’t be above min relay feerate, otherwise the node accepts transactions it will never mine. I’ve knocked it down to the bare minimum of 1sat/kvB. Now that we no longer have coin age priority (removed in v0.15), I think we can leave it to the CheckFeeRate policy rule to enforce a minimum entry price, and the block assembly code should just fill up the block with whatever it finds in mempool.

glozow commented at 2:12 pm on August 1, 2025:

added to commit message

murchandamus commented at 7:54 pm on August 1, 2025:

Thanks for the clarification and adding it to the commit message.

in src/test/util/setup_common.cpp:592 in 2872cb0bf5 outdated

582@@ -582,10 +583,11 @@ void TestChain100Setup::MockMempoolMinFee(const CFeeRate& target_feerate)
583     assert(target_feerate > m_node.mempool->m_opts.min_relay_feerate);
584 
585     // Manually create an invalid transaction. Manually set the fee in the CTxMemPoolEntry to
586-    // achieve the exact target feerate.
587+    // achieve the exact target feerate. The size needs to be large enough to avoid rounding problems in CFeeRate.
588     CMutableTransaction mtx = CMutableTransaction();
589     mtx.vin.emplace_back(COutPoint{Txid::FromUint256(m_rng.rand256()), 0});
590     mtx.vout.emplace_back(1 * COIN, GetScriptForDestination(WitnessV0ScriptHash(CScript() << OP_TRUE)));
591+    BulkTransaction(mtx, 4000);

murchandamus commented at 10:49 pm on July 31, 2025:

What sort of rounding problem were you seeing here? I thought that Fee Frac would essentially get rid of rounding issues.

glozow commented at 1:40 pm on August 1, 2025:

CFeeRate is a fraction. Prior to using FeeFrac, the denominator was always 1000. Now, it’s whatever you want it to be (in this case, the tx size). It still has to round, as it needs to output an integer number of satoshis when evaluating the fee for a given size.

The problem is that we weren’t rounding before when the fee was always a multiple of the size. Now we have to round; we want the number of satoshis for a size at 0.1sat/vB. I made all the numbers play nice by making the denominator 4000. Another way to fix this is to remove the assertion at the end of the function, but I preferred to keep it since it clearly helped catch this problem.

glozow commented at 2:12 pm on August 1, 2025:

I’ve elaborated in the comments on both BulkTransactions

in doc/release-notes-minrelay.md:13 in 7ed561063e outdated

 8+The default minimum relay feerate (`-minrelaytxfee`) and incremental relay feerate (`-incrementalrelayfee`) have been
 9+changed to 100 satoshis per kvB. They can still be changed using their respective configuration options, but it is
10+recommended to change both together if you decide to do so.
11+
12+Other minimum feerates (e.g. the dust feerate, the minimum returned by the fee estimator, and all feerates used by the
13+wallet) remain unchanged. The mempool minimum feerate still changes in response to high volume.

murchandamus commented at 10:57 pm on July 31, 2025:

At what precision does the minimum mempool feerate change? Could it be problematic if the mempool overflowed with transactions below 1 s/vB?

ajtowns commented at 4:44 am on August 1, 2025:

The precision when setting is sats/kvB so 0.001 sat/vb, since it’s just set to the highest fee rate of any tx evicted via TrimToSize().

https://github.com/bitcoin/bitcoin/blob/8712e074bb54eea9ccc4d2009d2150279c9d17ec/src/txmempool.cpp#L1132-L1138

glozow commented at 2:12 pm on August 1, 2025:

I’ve added a few words about it changing more gradually now that incremental relay feerate is lower

murchandamus commented at 11:01 pm on July 31, 2025: contributor

Concept ACK

rot13maxi commented at 0:17 am on August 1, 2025: none

Contrast this with the dust feerate, which defines a value as “too small” based on Bitcoin’s protocol constraints on transaction volume (e.g. spend script size vs block space). The conversion rate is thus irrelevant or, at the very least, applies very differently in that context.

No, dust is defined as too small to be worth spending, which is a factor of fee rate to spend it. If the fee rate is 10x lower, the dust limit is logically 10x lower as well.

Dropping the dust threshold by 10x is an interesting proposal. I am unsure if it should be in this PR or another one. Reason to be in another one would be to keep this PR just about fees and not price sensitive relay policy generally. Great suggestion though!

1ma commented at 1:34 am on August 1, 2025: none

NACK. I think the direction of this change makes sense in isolation, but interacts too badly with other default mempool policy choices.

Users will always prefer to transact at the lowest fee given the current demand for tx confirmation, and miners will always prefer to earn more fees by filling blocks with extremely cheap txs rather than mine half empty blocks. Both these market forces are set to intensify over the long run as fiat inflation goes on and Bitcoin’s block subsidy runs out. I don’t even believe it’s correct to think of tx fees as an anti-DoS protection: these forces virtually guarantee that in the long run miners will accept any tx paying at least 1 sat in total when they have nothing else to mine. Besides, if one was to argue that the minimum feerate acts as an anti-DoS mechanism like the OP does it would be contradictory to then propose cutting it down by a factor of 10x in the same breath.

Additionally the 1000 s/kvB floor arbitrarily discourages several kinds of large and beneficial txs when demand is low: super cheap coinjoins and super cheap dust consolidations (the latter is gaining importance because since Taproot activated the UTXO set tripled in size and 50% of outputs hold dust).

The problem then, obviously, is Core’s lack of mempool policies to keep datacarrying txs under control (a real DoS vector), which will even get worse once #32406 is released with Core v30. A cursory look at the mempool is enough to see that these parasitic txs are displacing coinjoins/consolidations and enjoying the low fee rates, even stalling the downwards trend on UTXO size that started in early 2025 (see above link).

Beyond the issue of this particular policy this episode laid bare once again the critical state of Bitcoin mining centralization. I find it baffling that a maintainer would conflate “Bitcoin miner” with “pool operator” by writing something as misleading as “Miners (some say up to 85%) are choosing to mine these low feerate transactions” when 99% of hashrate is still held captive by Stratum v1.

Today 5 or 6 pool operators just decided to ignore a hare-brained policy that never made sense in the first place, but tomorrow this handful of publicly-known operators might enforce a blacklist under duress. The prospect that so few mining nodes materially define what gets mined or not is sobering and scary.

The silver lining is that as I write this miners of any size (even BitAxe miners) can mine with their own nodes and set their own mining policies while still pooling their hashrate, and there are already 192 mainnet blocks mined in such a fashion. I encourage the wider dev community to treat the mining centralization problem with the seriousness it deserves and help evangelizing the solutions that are already available and proven to work.

ajtowns commented at 5:52 am on August 1, 2025: contributor

Contrast this with the dust feerate, which defines a value as “too small” based on Bitcoin’s protocol constraints on transaction volume (e.g. spend script size vs block space). The conversion rate is thus irrelevant or, at the very least, applies very differently in that context.

No, dust is defined as too small to be worth spending,

Luke is correct here that was the original rationale for the dust setting, and remains the rationale documented in the comments in policy.cpp. I don’t think that should be treated as the sole rationale, however; two other factors that should be considered are tht it’s also an effective (in practice) limit on utxo size growth, and that dust limits need to be taken into account by second layer protocols that build on Bitcoin, so we don’t have the same option to try decreasing them and then, if it turns out to be a bad idea, to re-increase them.

Even if it “worth the fees it will take to spend” were the only rationale, that’s still a good reason to have the dust rate set at a multiple of the minimum fee rate – both to take into account that there should be some value retained after fees, and to take into account the fact that sometimes the required fee rate will be above the default minimum fee rate. At this point, I would say that until we’ve had a few years demonstrating that 0.3sat/vb is enough to get your tx mined consistently, we shouldn’t even lower the dust limit to a level equivalent to 1sat/vb (vs the current 3sat/vb), let alone anything lower than that.

The cost to relay a transaction across the network is roughly its serialized size (plus relay overhead) x number of nodes.

I think of that more as “this cost to spam every node in the network with 1kB of data each if you did it by spinning up an ec2 node is [$x / GB] * [1e-6] * [number of nodes]”. The cost to do the same thing by relaying a valid 0.25kvB transaction and having nodes in the p2p network do the actual data transfer for you should be in the same range (preferably somewhat higher). With $120k/BTC and 90k p2p nodes, “the same” comes to 0.033sat/vb. The p2p nodes here aren’t being paid for their costs – miners collect the fees obviously, not p2p nodes – you’re just avoiding the p2p network providing attackers with a cheaper way of DoSing itself than commercial providers.

With mempool size limits enforced by a dynamic minimum fee, I don’t think we need anything more than that to keep the network functional as far as tx relay goes.

Concept ACK but I believe that the justification for this being the price went up is weak. This suggests also we may just lower it again in the future if the price goes down.

As far as I can see, using ec2 hosts to spam the network would be cheaper than sending 0.1sat/vb tx, even given a 67% reduction in the BTC price (to $40k/BTC), or a 3x increase in the number of nodes on the network (to ~270k). If we had more than either of those, I think this setting should be revisited. (OTOH, if the price goes up by 3x and the number of nodes goes up by 3x, and commercial bandwidth prices stay roughly the same, that’s a wash and there’s no need to revisit it)

I don’t think giving a 90% fee discount to low value inscriptions is in miners’ interests, and I don’t think block relay efficiency concerns should be used to either remove policy options from node operators or (more importantly) miners or as the primary controlling factor in determining policy defaults. I think there are better ways to address those concerns, though, and I’m satisfied that bandwidth DoS should be the main factor influencing the default minimum fee for tx relay.

Approach ACK.

ArmchairCryptologist commented at 10:32 am on August 1, 2025: none

Concept ACK, FWIW. The long and short of it is that mempool/relay (fee) policy is ineffective as a “spam filter”, since the node will have to accept the transaction anyway if it is mined, so trying to use it as such is futile. Meanwhile, rejecting transactions that are being mined is detrimental to block propagation in particular and overall node/network performance in general. As such, changing the defaults to match what is actually being mined is warranted as long as the DoS resistance is not compromised, and I believe @ajtowns and others have provided convincing arguments that it is not.

Today 5 or 6 pool operators just decided to ignore a hare-brained policy that never made sense in the first place, but tomorrow this handful of publicly-known operators might enforce a blacklist under duress. The prospect that so few mining nodes materially define what gets mined or not is sobering and scary.

You’re not wrong as such about miner centralization, but this is the opposite problem. The default mempool relay fee policy is preventing transactions that are being mined from being relayed by (most) nodes. Your hypothetical situation is where transactions are being relayed, but not mined by (some) miners. Presumably, if mining pools start censoring higher-paying transactions due to regulatory blacklisting, miners will migrate to pools in other jurisdictions that ignore them, if for no other reason than that they will be missing out on fees if they don’t. Either way, I don’t think this is really on-topic for this PR.

glozow marked this as ready for review on Aug 1, 2025

glozow renamed this:
~~[WIP] policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee~~
policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee
on Aug 1, 2025

glozow force-pushed on Aug 1, 2025

glozow commented at 2:27 pm on August 1, 2025: member

dust limits need to be taken into account by second layer protocols that build on Bitcoin, so we don’t have the same option to try decreasing them and then, if it turns out to be a bad idea, to re-increase them.

I’ve edited the OP to include this as the main reason for marking dust feerate out of scope in this PR.

avoiding the p2p network providing attackers with a cheaper way of DoSing itself than commercial providers.

Also reworded the pricing section with this framing.

Refactor CFeeRate to use FeeFrac internally

Co-authored-by: Abubakar Sadiq Ismail <48946461+ismaelsadeeq@users.noreply.github.com>

b2ff96371e

[test] check miner doesn't select 0fee transactions 2778e46916

[test] check bypass of minrelay for various minrelaytxfee settings d40de30fdf

[test] RBF rule 4 for various incrementalrelayfee settings 732e43775e

[miner] lower default -blockmintxfee to 1sat/kvB

Back when we implemented coin age priority as a miner policy, miners
mempools might admit transactions paying very low fees, but then want to
set a higher fee for block inclusion. However, since coin age priority
was removed in v0.15, the block assembly policy is solely based on fees,
so we do not need to apply minimum feerate rules in multiple places. In
fact, the block assembly policy ignoring transactions that are added to
the mempool is likely undesirable as we waste resources accepting and
storing this transaction.

Instead, rely on mempool policy to enforce a minimum entry feerate to
the mempool (minrelaytxfee). Set the minimum block feerate to the
minimum non-zero amount (1sat/kvB) so it collects everything it finds in
mempool into the block.

8a791e86f8

[prep/test] replace magic number 1000 with respective feerate vars 33246ea35e

[prep/util] help MockMempoolMinFee handle more precise feerates

Use a virtual size of 1000 to keep precision when using a feerate
(which is rounded to the nearest satoshi per kvb) that isn't just an
integer.

a69c6bc0b7

[prep/test] make wallet_fundrawtransaction's minrelaytxfee assumption explicit 27ee2836fb

[policy] lower default minrelaytxfee and incrementalrelayfee to 100sat/kvB

Let's say an attacker wants to use/exhaust the network's bandwidth, and
has the choice between renting resources from a commercial provider and
getting the network to "spam" itself it by sending unconfirmed
transactions. We'd like the latter to be more expensive than the former.

The bandwidth for relaying a transaction across the network is roughly
its serialized size (plus relay overhead) x number of nodes. A 1000vB
transaction is 1000-4000B serialized. With 100k nodes, that's 0.1-0.4GB
If the going rate for commercial services is 10c/GB, that's like 1-4c per kvB
of transaction data, so a 1000vB transaction should pay at least $0.04.

At a price of 120k USD/BTC, 100sat is about $0.12. This price allows us
to tolerate a large decrease in the conversion rate or increase in the
number of nodes.

b73be4b32a

darosior commented at 3:23 pm on August 1, 2025: member

A substantial portion of Bitcoin transactors and miners are already using the value which this PR sets as default. Over the past month we’ve seen a non-trivial amount of sub-1sat/vb transactions. As an illustration of this, in the past day of block more than 23% of transactions (!!) used a feerate lower than 1sat/vb. That one quarter of the average block’s content is not being relayed by default Bitcoin Core has a significant impact on block propagation, due to the additional time spent validating block transactions and additional roundtrips in block reconstruction. In fact if this trend continues i expect block propagation time will already be significantly impacted until the network adopts Bitcoin Core 30.0.

You can list all sub-1sat/vb transactions in the past day of blocks on your own Bitcoin Core node with the following jq-fu:

0bc="bitcoin-cli -datadir=your_datadir"; end=908109; start=$(($end - 144)); for h in $(seq $start $end); do hash="$($bc getblockhash $h)"; $bc getblock $hash 2 |jq '.tx[] | select(.fee != null) | {feerate: (.fee / .vsize * 1e8 * 100 | round | ./100), txid} | select(.feerate < 1) | "Transaction \(.txid) has feerate \(.feerate) sat/vb"'; done

To count the number of such transactions, just pipe it into wc -l. Running this on a local node i get:

0$ bc="bitcoin-cli -datadir=your_datadir"; end=908109; start=$(($end - 144)); for h in $(seq $start $end); do hash="$($bc getblockhash $h)"; $bc getblock $hash 2 |jq '.tx[] | select(.fee != null) | {feerate: (.fee / .vsize * 1e8 * 100 | round | ./100), txid} | select(.feerate < 1) | "Transaction \(.txid) has feerate \(.feerate) sat/vb"'; done |wc -l
193302

You can get the total number of transactions over this period by summing the nTx returned by getblock for all these blocks, or if you are lazy just drop the select(.feerate < 1) in the above command. Here i get:

0$ bc="bitcoin-cli -datadir=your_datadir"; end=908109; start=$(($end - 144)); for h in $(seq $start $end); do hash="$($bc getblockhash $h)"; $bc getblock $hash 2 |jq '.tx[] | select(.fee != null) | {feerate: (.fee / .vsize * 1e8 * 100 | round | ./100), txid} | "Transaction \(.txid) has feerate \(.feerate) sat/vb"'; done |wc -l
1401684

Therefore 93302 / 401684 * 100 = 23.23 % of transactions in the past day of block used a feerate lower than 1sat/vb.

Lowering the default minimum feerate does not, as detailed above, introduce a DoS vector and it allows Bitcoin Core’s relay policy to match a sizeable share of Bitcoin’s usage. Obvious Concept ACK.

[doc] release note for min feerate changes a43e1b28b2

glozow force-pushed on Aug 1, 2025

glozow commented at 3:29 pm on August 1, 2025: member

Rebased for #31385

caesrcd commented at 6:23 pm on August 1, 2025: none

tACK a43e1b28b2899e1707e7867fd46efe9fcc08f241

Compiled and tested on Arch Linux (kernel 6.15.8, gcc 15.1.1, clang 20.1.8). Build performed with CMake in Debug mode:

0cmake -B build_test -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang
1cmake --build build_test -j$(nproc)
2ctest --output-on-failure --stop-on-failure --test-dir build_test -j$(nproc)
3build_test/test/functional/test_runner.py

All unit and functional tests passed successfully.

DrahtBot requested review from darosior on Aug 1, 2025

DrahtBot requested review from murchandamus on Aug 1, 2025

DrahtBot requested review from fjahr on Aug 1, 2025

DrahtBot requested review from ajtowns on Aug 1, 2025

SomberNight referenced this in commit 63db1e78c2 on Aug 1, 2025

SomberNight referenced this in commit f6ff834648 on Aug 1, 2025

SomberNight referenced this in commit d8a6ed9b55 on Aug 1, 2025

SomberNight referenced this in commit 58af1c493d on Aug 1, 2025

petertodd commented at 1:42 pm on August 2, 2025: contributor

Concept ACK @benthecarman

but I believe that the justification for this being the price went up is weak. This suggests also we may just lower it again in the future if the price goes down.

We should consider increasing these defaults if the price goes down significantly! E.g. if miners consistently set higher defaults and we’re relying transactions that aren’t getting mined. Equally, we may want to lower these defaults yet again in the future.

chrisguida commented at 4:58 pm on August 2, 2025: none

This seems like it will only lead to more utxoset bloat.

Aren’t most of the transactions being confirmed now with <1sat/vB fees just inscriptions and other spam?

caesrcd commented at 6:08 pm on August 2, 2025: none

@chrisguida

Aren’t most of the transactions being confirmed now with <1sat/vB fees just inscriptions and other spam?

Inscriptions do not rely on wallets to create transactions with <1sat/vB fees. They are typically constructed and broadcasted by custom tools, independent of standard wallet behavior.

The fact that many low‑fee transactions are inscriptions does not imply that regular users are not interested in paying lower fees.

chrisguida commented at 6:51 pm on August 2, 2025: none

@caesrcd you’re missing the point. The point is that inscriptions have proven extremely destructive to the utxoset, and lowering the minimum fee rate makes bloating the utxoset even easier than it was before.

Of course everyone is interested in paying lower fees; the point is that the minimum was set how it is in order to prevent relay spam and utxoset bloat.

If the majority of demand for such transactions were, for example, consolidations, then it would be a different story. But the fact is that this feature is mostly only popular with spammers.

KurtisStirling commented at 7:42 pm on August 2, 2025: none

Concept NACK

No one asked for this; 1 sat isn’t even 1 cent yet. This is a non-starter because it’s non-issue.

Fix utxo set bloat instead of fiddling with things you don’t need to please.

caesrcd commented at 7:47 pm on August 2, 2025: none

The scope of this PR does not concern the impact on the UTXO set, nor the question of whether inscriptions are destructive.

The fact is that the number of nodes choosing to relay lower‑fee transactions continues to grow, and currently more than 80% of the network hashrate is mining sub‑1sat/vB transactions. This shows that the mechanism already works in practice and that user interest in taking advantage of lower fees is likely to increase.

However, not all users know how to create transactions manually without relying on wallets, or how to modify the source code of their preferred wallet to enable this functionality.

Restricting this feature merely because inscriptions already benefit from it would ultimately prevent regular users from also taking advantage of low‑demand periods to pay lower fees.

stickies-v commented at 3:31 pm on August 4, 2025: contributor

Concept ACK

Protecting against DoS / bandwidth usage should be the primary concern of this policy. The calculations and rationales presented in this thread, mostly by @ajtowns (e.g. here, here) make sense to me, and a 10x decrease seems like it’s in the right ballpark.

Even though I don’t think this policy should be used to artificially support miner revenue, I was initially concerned that miners might not be sufficiently incentivized to adopt this lower minimum feerate, thus creating a gap between a node’s mempool and what would actually get mined. Looking at recently mined blocks across pools it seems that’s not happening, so I don’t see any reason anymore not to go ahead with this change.

Will follow-up with a code review soon.

jsarenik commented at 4:02 pm on August 4, 2025: none

Approach ACK

in src/policy/feerate.cpp:42 in a43e1b28b2

48 
49 std::string CFeeRate::ToString(const FeeEstimateMode& fee_estimate_mode) const
50 {
51+    const CAmount feerate_per_kvb = GetFeePerK();
52     switch (fee_estimate_mode) {
53-    case FeeEstimateMode::SAT_VB: return strprintf("%d.%03d %s/vB", nSatoshisPerK / 1000, nSatoshisPerK % 1000, CURRENCY_ATOM);

jsarenik commented at 4:11 pm on August 4, 2025:

Even though this was clean in the code before, there were (and maybe still are) historically some wallets which divided by 1024 rather than 1000 and so were never able to pay really the minimum fee that already made the default nodes relay the transaction.

in src/policy/feerate.cpp:33 in a43e1b28b2

50 {
51+    const CAmount feerate_per_kvb = GetFeePerK();
52     switch (fee_estimate_mode) {
53-    case FeeEstimateMode::SAT_VB: return strprintf("%d.%03d %s/vB", nSatoshisPerK / 1000, nSatoshisPerK % 1000, CURRENCY_ATOM);
54-    default:                      return strprintf("%d.%08d %s/kvB", nSatoshisPerK / COIN, nSatoshisPerK % COIN, CURRENCY_UNIT);
55+    case FeeEstimateMode::SAT_VB: return strprintf("%d.%03d %s/vB", feerate_per_kvb / 1000, feerate_per_kvb % 1000, CURRENCY_ATOM);

jsarenik commented at 4:13 pm on August 4, 2025:

Thanks for keeping it clear and obvious still!

jsarenik commented at 4:37 pm on August 4, 2025: none

Looks good to me. Thanks!

0xB10C commented at 3:12 pm on August 5, 2025: contributor

I’ve published a chart showing the share of sub 1 sat/vByte transactions on mainnet.observer/charts/fees-sub-1-sat-vbyte-transactions.

I also generated a recent export of my stats on compact block reconstructions over the last two months:

Since #32582 we also log the number of bytes that we requested to reconstruct the block. I plot the average kB requested per block in the following new chart. In June, we were requesting less than 10 kB worth of transactions per block on average for about 40-50% of blocks. Now, we are requesting close to 0.8 MB worth of transactions per block on average for about 70% of blocks.

darosior commented at 3:19 pm on August 5, 2025: member

In June, we were requesting less than 10 kB worth of transactions per block on average. Now, we are requesting close to 0.8 MB worth of transactions per block on average.

Crazy. Although this is a significant diff we might want to backport this PR at least to 29.

glozow commented at 6:43 pm on August 5, 2025: member

Yeah compact block reconstruction looks horrendous. Thanks @0xB10C!

I looked a little bit at the distribution of sub-1sat/vB feerates to try make sure we’re capturing the ones that are causing poor reconstruction. If a significant portion of transactions are even lower, I think we could lower this to 50sat/kvB while staying solidly within the DoS budget, but it doesn’t seem necessary.

This is individual feerate from the last day’s worth of blocks, showing 97% of them are >= 0.1sat/vB.

In the 3% of transactions that are below 0.1sat/vB, virtually all of them are 0-0.01sat/vB. My hunch is that these are often exactly 0 fee TRUC packages or miners’ own transactions. I’m only seeing a small handful of transactions that are below 0.1sat/vB but not 0-0.01. In any case, I don’t think we should go as low as 0.01sat/vB.

0bc="bitcoin-cli -datadir=abc"; end=908760; start=$(($end - 144)); for h in $(seq $start $end); do hash="$($bc getblockhash $h)"; $bc getblock $hash 2 |jq '.tx[] | select(.fee != null) | {feerate: (.fee / .vsize * 1e8 * 1000 | round | ./1000), txid} | select(.feerate < 1) | "Transaction \(.txid) has feerate \(.feerate) sat/vb"'; done > lowfeetxs.txt

 0Overall Fee Rate Statistics (sat/vB):
 1----------------------------------------
 2count          : 99122.0000
 3mean           : 0.3538
 4std            : 0.1819
 5min            : 0.0000
 625%            : 0.1530
 750%            : 0.4030
 875%            : 0.4520
 9max            : 0.9990
10
11Detailed Fee Rate Distribution:
12----------------------------------------
130.00 - 0.01 sat/vB:  2,979 txs (  3.0%)
140.01 - 0.05 sat/vB:     16 txs (  0.0%)
150.05 - 0.10 sat/vB:     23 txs (  0.0%)
160.10 - 0.20 sat/vB: 26,387 txs ( 26.6%)
170.20 - 0.30 sat/vB:  4,531 txs (  4.6%)
180.30 - 0.40 sat/vB:  7,352 txs (  7.4%)
190.40 - 0.50 sat/vB: 38,554 txs ( 38.9%)
200.50 - 1.00 sat/vB: 19,280 txs ( 19.5%)
21
22Whether 0.1sat/vB is a good threshold:
23------------------------------------------
24Zero fee transactions: 2,979
250 < feerate < 0.1: 39
260.1 ≤ feerate < 1.0: 96,104

shocknet-justin commented at 7:00 pm on August 5, 2025: none

But the fact is that this feature is mostly only popular with spammers.

Important context is the prevalence of scaling scammers, fake L2’s etc that claim to be “scaling ownership” by way of centralized transaction pooling to lower the cost-per-transaction.

Word games around “unlilateral exit” are the basis of these scams, these fake L2’s target users who literally cannot afford a unilateral exit and so end up in these centralized schemes in the first place. By lowering the actual cost of transacting it expands the number of users that can afford to unilaterally transact and avoid these fake L2’s altogether. It should be noted that these centralized fake L2’s are also fantastic tools for surveillance and censorship.

If a concern with this PR is further enabling bad actors, it should be noted that it more importantly undermines the business models of other bad actors and is itself the final scaling frontier for sovereign ownership.

policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee #33106

Code Coverage & Benchmarks

Reviews

Conflicts