Here's some history of Bitcoin Policy changes that were controversial at the time:
Basics: Policy is not Consensus. Satoshi's first client did not relay all transactions that were valid according to consensus. This is necessary so an attacker cannot just flood the network with zero fee (consensus valid) transactions to himself at no cost to him but high cost in bandwidth and CPU to all nodes. Still, even the the early policy filters led some to shout "censorship" when trying out things that were consensus-valid.
2013 the Dust Limit was introduced. Transactions sending 1sat to somebody were not relayed anymore. While this was a reaction to "Satoshi Dice" which permanently spammed the UTXO set with "notification transactions", it also forced other projects like "Colored Coins" back to the drawing board.
2014 OP_RETURN Data Carrier Size Limits were introduced. Before, OP_RETURN accidentally allowed spending any funds on chain which was fixed in 2010 by Satoshi, establishing the OP_RETURN as we know it today. It was limited to 40B (8175c79) and then 80B (a930658) via Policy.
2016 Replace-by-Fee (RBF) was introduced. Before that and especially in the early days, users assumed transactions to be final when they showed up in their mempool aka "wallet". "first-seen-safe" was a thing and shaking that up was perceived as an attack on Bitcoin by many. In 2016, RBF wasn't even activated for all transactions. It was an opt-in feature but still, emotions ran high.
2017 the concept of "Priority Transactions" was removed. Up until then, transactions with no fee at all were relayed and actually mined if they were "priority transactions" meaning for example to spend from old enough UTXOs.
2022 Full-RBF was introduced, enabling any unconfirmed transaction to be replaced. This somewhat revived the FUD from 2016.
2025 OP_RETURN is scheduled to be opened up to 100kB which sits at the core of the recent "Knots vs. Core" drama.
Login to reply
Replies (17)
What's your evidence for "mass protest"?
Well sir,
I would say the largest client flag exodus from the mainline implementation in bitcoin’s history since and possibly exceeding the UASF ?
Is that the “evidence” you are demanding?
If not for OP_RETURN limits, we would have Ethereum built on top of Bitcoin. Do you want to go back to $50+ transaction fees, so some retards can put monkey jpegs on it. Then we can have the blocksize wars again? #Enshitcoinification
If there would be demand for this change, nodes could already change that. But on the contrary a significant portion of the network even changed proactively their node implementation.
People tend to read that from
I see Core maybe lost 3k nodes since the sudden up-tick of Knots in 2025 but the number is also trivial to fake, especially on TOR. It's really hard to find out if 100 TOR nodes are actually distinct nodes or all the same. I don't know what to make of the much more modest up-tick in Knots numbers since a year prior. Was the conflict already brewing? Did somebody pump the Core numbers in order to opportunely let them drop at the right time? I'm looking at April 2024 to April 2025. Both implementations grew, Core by 3k or 20%. Knots grew 600% in that time! So clearly, something was afoot.

Coin Dance
Coin Dance - Bitcoin Nodes Summary
I see Core maybe lost 3k nodes since the sudden up-tick of Knots in 2025 but the number is also trivial to fake, especially on TOR. It's really hard to find out if 100 TOR nodes are actually distinct nodes or all the same. I don't know what to make of the much more modest up-tick in Knots numbers since a year prior. Was the conflict already brewing? Did somebody pump the Core numbers in order to opportunely let them drop at the right time? I'm looking at April 2024 to April 2025. Both implementations grew, Core by 3k or 20%. Knots grew 600% in that time! So clearly, something was afoot.Much to unpack there.
OP_RETURN is deliberately the most stupid of all op-codes. It does nothing but with lots of data. Nodes do not enforce whatever you want to do on top of OP_RETURN, so no, it doesn't turn Bitcoin into Ethereum.
$50+ transaction fees will be required for Bitcoin's success at some point but the monkey picture spammers moved on. They don't have that deep pockets to sustain this attack. They started with pictures on Bitcoin but quickly realized that it has to be some launch date events to actually drive fees in a disruptive way. That made nobody rich and the few stories where it did - are probably just money laundering, so the attackers can't bet on gullible people falling for this indefinitely. They would need other deep pockets for a sustained attack.
Increasing the blocksize is not a fix ever. We need to improve layers on top of the base chain if we want more people to have actual self-custody. With covenants enforced by miners we could scale Bitcoin by x100 without needing 100MB blocks and therefore with improved privacy.
Datacarriersize is currently, as of Core v29, 83B and it can be set to any other value. Sadly there is no way to just ask nodes about that setting, right? I'd love to see if people use the setting to increase or decrease the value currently. Guess, nodes could track transactions they receive and from where they got them to defer that setting over time but did anybody do that?
To limit the datacarriersize to 40B as Knots, you can just use Core v29 with that setting. Running Knots is really a form of protest and not the expression of a datacarriersize preference. That said, I don't see clear evidence for "a significant portion of the network even changed proactively their node implementation" as the numbers we see at coindance are easily and cheaply faked.
Grasping intellectual dishonesty does not befit an honorable man.
How about when pro change propaganda posted by reputable people like Calle get ratiod by the masses?
And what steps have Core taken to learn if there is a mass protest? They should care right?
Your question implies it would be important if there was such protest.
I'm not aware of how "Vitalik ... would've built Ethereum on top of Bitcoin" with just OP_RETURN. Ethereum carries much more state that's being checked by the miners than what you could do with just OP_RETURN.
I suspect, monkey jpegs trading is an illusion kept alive for the purpose of hiding this attack as some sort of "for the artists" legitimate project. It never was legitimate.
Which criminal would pay for 100kB of block space at even 1sat/B for something being in the blockchain forever if it wasn't simply to harm Bitcoin? CSAM certainly isn't worth that much.
I think, Core's strength isn't diplomacy. They did in the past take the right decisions and for example full RBF was introduced in a much more diplomatic way. Opt-in at first, full later. With OP_RETURN they went full-rbf in one swoop.
I think that is the crux of the concerns. The change in behavior.
He's using the word "criminal" where I think he should have used "adversarial".
So what stops an adversary from embedding CSAM in the Bitcoin blockchain? Nothing really. They could do this since day one and since many years with a 100kB OP_RETURN. Coming policy changes did not affect that one bit.
On the other hand, the claim that some CSAM sharing group is using Bitcoin for their stuff is totally ridiculous and transparently just an attack against Bitcoin.
Can you put an occasional CSAM on the blockchain? Sure!
Can you use it for an unstoppable file sharing protocol? No!
And if illegality was the issue: There are many OFAC sanctioned transactions on the blockchain already and nobody, not Core, not Knots intends to block them.
So you're telling me, recklessly increasing the blocksize was a bad idea, executed by an incompetent team?
I don't think, this is in any way comparable with what might happen on BTC.
I have no concern over OFAC sanctions and I doubt many people would. Those are monetary transactions and inline with the purpose of Bitcoin. Permissionless payments, not file storage.
Lack of diplomacy and totalitarianism are not the same thing. One can be forgiven.
They have made it clear that miners are higher on their list than node runners. I'm not seeing evidence that node runners are even on their list of priorities.
