Current sub-1sat/vbyte minrelayfee and historical precedent

[NotATether]

I browsed through some old Bitcoin history by accident while making edits to the Wiki. Apparently, in Bitcoin Core 0.11.0, the 1000 sats minrelayfee configuration default was introduced because some anonymous person was spamming large volumes of tiny transactions into the network.

https://blog.lopp.net/history-bitcoin-transaction-dust-spam-storms/

RIP Bitcoin Attack
A few weeks after the CoinWallet spam ended, a new flood started. These transactions tended to have 102 outputs each with a value of 0.0001 BTC.

At the time when the attack started, an anonymous user wrote “RIP Bitcoin” in one of the Bitcoin development IRC rooms. In response, Bitcoin Core developers instituted a minimum transaction relay fee of 1,000 satoshis in the 0.11.0 release.

It turns out that some researchers were monitoring the network for suspicious activity during this time and later published this research paper. They performed cluster analysis of the spammy-looking transactions and identified 10 different clusters of UTXOs - likely 10 different wallets that were automated to generate the transactions.

My question is what exactly has changed in the last 10 years that has made Core developers decide to reverse course and lower the default minrelayfee?

[ABCbits]

My question is what exactly has changed in the last 10 years that has made Core developers decide to reverse course and lower the default minrelayfee?

You can see discussion on pull request that change the default value, https://github.com/bitcoin/bitcoin/pull/33106.

[ertil]

what exactly has changed in the last 10 years

Mining pools started confirming these transactions, instead of blindly following Bitcoin Core.

If you have a block template, that you can get through "getblocktemplate", then it contains transactions, that are flying in different mempools. As long as this template is identical in most nodes, you have all transactions already validated, when the new block is mined. Then, verifying a given block is very fast.

However, if some mining pool produces a block, which contains transactions, that were never broadcasted before, then nodes have to download these transactions, and verify them, to know, if a block is valid or not.

And this is the main reason, why developers decided to lift more limits. Because they are already lifted by mining pools. So, keeping them does not change anything, and only makes everything slightly slower, if some node actively rejects some transactions, and they are later downloaded again, when a new block is produced.

Which also means, that there is a new attack, that can be done, and that cannot be easily stopped: miners could decide to produce 4 MB blocks, with self-transfers, which would be costly to validate, and which would break any standardness rules, while also being valid, when it comes to consensus rules. And then, if miners will keep breaking next limits, then developers will keep lifting them. And then, the end result would be a chain, where only consensus rules are enforced, and there is no longer any concept of "non-standard transaction", so there is no obvious way to make new soft-forks, without burning someone's coins.

[d5000]

There is of course another reason: the Bitcoin price multiplied by more than 100 in the last 10 years. That means that even taking into account the witness discount, a spam attack at the current 0.1sat/vByte is more costly than at 1sat/Byte back then. That was also mentioned in the PR discussion.

It was thus a bit "logical" that miners and nodes have reduced the minrelayfee once non-full blocks were getting common.

In general the standardness values seem to try to set a common standard most miners/nodes would be happy to follow, and I interpret this change in this way. If this change was not made, then perhaps too many miners and nodes would have set their minrelayfee to less than 0.1 and we'd have a mess of different configurations.

I'm not an expert about the "compact block" issue (see also @ertil's comment), but it seems that a situation where nodes have very diverging standardness/policy values leads to increased network traffic: if a node receives blocks with transactions he has rejected before due to standardness policy, it would have a significantly higher bandwidth consumption than if it accepted them because it wouldn't benefit from the compact block mechanism (BIP 152).

[Alvin_talk]

Well, I think the core relay rules does not just focus on setting fees rather they are put in place to maintain the network general health.

It was reversed because it no longer matched the real world conditions. Remember that satoshis had become more valuable so the previous rate was unnecessary high as it obstructed some legitimate transactions. Moreover, miners were already including rates below 1 sat/VB which made core developers to adjust the node policy with miners behavior.

[philipma1957]

I browsed through some old Bitcoin history by accident while making edits to the Wiki. Apparently, in Bitcoin Core 0.11.0, the 1000 sats minrelayfee configuration default was introduced because some anonymous person was spamming large volumes of tiny transactions into the network.

https://blog.lopp.net/history-bitcoin-transaction-dust-spam-storms/

RIP Bitcoin Attack
A few weeks after the CoinWallet spam ended, a new flood started. These transactions tended to have 102 outputs each with a value of 0.0001 BTC.

At the time when the attack started, an anonymous user wrote “RIP Bitcoin” in one of the Bitcoin development IRC rooms. In response, Bitcoin Core developers instituted a minimum transaction relay fee of 1,000 satoshis in the 0.11.0 release.

It turns out that some researchers were monitoring the network for suspicious activity during this time and later published this research paper. They performed cluster analysis of the spammy-looking transactions and identified 10 different clusters of UTXOs - likely 10 different wallets that were automated to generate the transactions.

My question is what exactly has changed in the last 10 years that has made Core developers decide to reverse course and lower the default minrelayfee?

it is an effort to help with smaller block rewards. the hope is it will drive up price of the coin

2024 3.125                       100,000 a coin   $ 312,500 a block
2028 1.5625                     215,000 a coin    $ 335,973 a  block
2032 0.78125                   445,000 a coin    $ 347,656 a block
2036 0.390625                 900,000 a coin    $ 351,562 a block
2040 0.1953125            1,850,000 a coin    $ 361,328 a block
2044 0.09765625          3,950,000 a coin    $ 385,742 a block

at .1 sats the fee is small in 2044

0.00000011 btc is under a dollar if btc is 3,950,000 a coin

which means by 2048 a coin could be 8 million and fees would still be under a dollar.

So the thought behind it is the belief that coins could be at 8 million in 2044 and only cost around 90 cents to move a tx

[ABCbits]

I'm not an expert about the "compact block" issue (see also @ertil's comment), but it seems that a situation where nodes have very diverging standardness/policy values leads to increased network traffic: if a node receives blocks with transactions he has rejected before due to standardness policy, it would have a significantly higher bandwidth consumption than if it accepted them because it wouldn't benefit from the compact block mechanism (BIP 152).

Not only more network traffic, but also could lead to longer time needed to verify a block. In this way, miner/pool who choose to include non-standard TX (along with TX that never broadcasted) have disadvantage regarding block propagation time. Although since some mining pool already does that, i would guess the difference is relative small.

[satscraper]

My question is what exactly has changed in the last 10 years that has made Core developers decide to reverse course and lower the default minrelayfee?

I'm sure you don’t assume that mining is all beer and skittles.. The equipment used in mining, especially in a competitive pool, must be constantly upgraded to keep up with more advanced pools. In addition to electricity, miners also face other costs related to their hardware, maintenance, and infrastructure. Thus ^{to support individual miners}, I believe the decision was made to prioritize full blocks over half-empty ones by lowering the default minrelayfee, because there's growing concern that the mining industry could become fully government-controlled in the future.

[Mia Chloe]

~snip

Actually the decision to reverse course on the default 1000 satoshi minimum relay fee wasn't a reduction of a single magic number but kinda like a fundamental shift from a blunt anti spam measure to a kinda granular rate based system.

The original 1000 sat/kB minimum fee rate (I think  was introduced in 0.11.0) was more of a hammer to protect nodes from resource exhaustion  by indirectly enforcing a high dust limit against transactions with many tiny outputs that increased the size of the UTXO set.

The reversal was actually possible because developers introduced  protections like automatic size limited mempools in later versions and policy separations like decoupling the dust limit from the relay fee.

Most importantly the elimination of Coin Age Priority actually closed the free transaction loophole making feerate the only entry requirement which literally combined with the efficiency gains of SegWit's vByte accounting and allowed nodes to safely lower their effective policy floor to 1sat/vB which is more like the current standard without risking a spam recurrence.

[NotATether]

The reversal was actually possible because developers introduced  protections like automatic size limited mempools in later versions and policy separations like decoupling the dust limit from the relay fee.

Most importantly the elimination of Coin Age Priority actually closed the free transaction loophole making feerate the only entry requirement which literally combined with the efficiency gains of SegWit's vByte accounting and allowed nodes to safely lower their effective policy floor to 1sat/vB which is more like the current standard without risking a spam recurrence.

This is actually very helpful and I can actually see this being used in a video explanation of the topic. Thanks!

I'm sure you don’t assume that mining is all beer and skittles.. The equipment used in mining, especially in a competitive pool, must be constantly upgraded to keep up with more advanced pools. In addition to electricity, miners also face other costs related to their hardware, maintenance, and infrastructure. Thus ^{to support individual miners}, I believe the decision was made to prioritize full blocks over half-empty ones by lowering the default minrelayfee, because there's growing concern that the mining industry could become fully government-controlled in the future.

I've never mined before... so they just throw out all the old ASICs after they upgrade their farms?

Or do they mine testnet?

They don't seem like they are useful for anything else besides scrap metal.

[Donneski]

My question is what exactly has changed in the last 10 years that has made Core developers decide to reverse course and lower the default minrelayfee?

From what I’ve read, the main driver wasn’t just “Core decided to be nice.” Over the years miners were already including low-fee transactions via block templates, which meant keeping a high minrelayfee on nodes only forced them to re-download the same transactions later when a block arrived (hurting propagation/compact blocks).

Also, the rise in Bitcoin's price and the shift to measuring in vbytes with SegWit changed the economics of spam so the old default wasn’t really serving its original purpose anymore. The PR linked above has a good discussion of the reasoning.

[LoyceV]

I've never mined before... so they just throw out all the old ASICs after they upgrade their farms?

I assume they'll dispose of them, but your post made me curious so I looked up some Antminer progress specs (I believed the first Google result for each item on this list):
S1: 0.18 TH/s
S2: 1 TH/s
S3: 0.478 TH/s
S4: 2 TH/s
S5: 1.155 TH/s
S6: 3.1 TH/s
S7: 4.7 TH/s
S9: 14 TH/s (1 kW)
S11: 19.5 TH/s
S15: 28 TH/s
S17: 53 TH/s
S19: 82 TH/s
S21: 200 TH/s
S23: 318 TH/s (3.5 kW)
(they seem to have skipped some numbers)

The power requirement keeps going up, but the hashrate goes up much faster. So I expect miners to have some overlap between old and new hardware, but the moment older hardware isn't earning more than it costs to run (in electricity), they'll unplug them. They may still keep them for a while in case the market situation changes, but I don't expect anyone to still be using an S9 for instance (or at least not making a profit with it).