Understanding why so many bitcoiners are angry at core.

[PepeLapiu]

Around the turn of the decade, most of the original founding developers at core were replaced by newer, younger, less experienced developers.

In 2022 the documentation of core was changed. The description of "Bitcoin as  an experimental digital currency that enables instant payments to anyone, anywhere in the world." is changed. All mentions of bitcoin as money or currency have been removed. They simply removed the definition of "what is bitcoin" and replaced it with "what is bitcoin core". Some asked why the definition of bitcoin had to be replaced, why not have the two of them. The answer provided was basically that nobody really needs a definition of Bitcoin.

Later in 2022, the definition of -datacarriersize in the core documentation was changed so it applied only to raw OP_RETURN outputs. -datacartiersize is basically the variable that constrained the amount of arbitrary data. In 2022, it was changed to mean only arbitrary date in op_return outputs.

Early 2023, Cassey Rodamor exploited a bug he found instead of reporting it. The ordinal malware is launched on Bitcoin around February 2023.

Sep 4 2023 - Luke Dashjr submits a pull request. Effectively a way to filter out ordinals. It is rejected as too controversial, and also based on the new definition of -datacarriersize.. Had core implemented this filter in their next release, over 80% of the nodes would be running this filter today.

A PR requests that Segwit and Taproot inputs be included in the definition of -datacarriersize. It's rejected.

May 8 2024 - In a podcast, lead core maintainer Gloria Zhao says she doesn't think it's productive to discuss if jpegs in the chain are good or bad. This indicates she doesn't really have any objection to posting jpegs on the bitcoin blockchain.
source: https://youtu.be/VsUyjFkkp4E

Between the launch of ordinal malware and now, several other malware protocols are launched on Bitcoin: stamps, BRC tokens, runes, rare sats, you name it.

Every time, core devs and core taking heads repeat the sane nonsense:

- They paid their miner fees.
- Those are valid transactions.
- We can't stop them, and even if we could, that would be censorship.

And gradually, the narrative is being shifted. Core talking heads no longer claim Bitcoin is money, but rather, the users decide what Bitcoin is.

March 2025, a PR requests that -datacarriersize be expanded from 83 B to 100,000 B, or virtually no real limit. The PR is merged into core 30, amidst the controversy and push back from the community.

What was a limit of 83 bytes in a transaction since 2015, was now completely evicerated. First it was redefined as specific to outputs only, than it was blown open.

Since the malware attack started with ordinals in 2023, all excuses to do nothing about it have been used. Framing any attempt as censorship, or bound to fail. It's always the same excuses: bitcoinnis just a database, they can't be stopped, they might use more harmful ways to attack Bitcoin if we don't cater to them, the fees are the only filter allowed and acceptable, bitcoin is a free market everything, not just a free market money....

It's quite clear, to anyone who pays attention, that core has absolutely no desire to do anything about the increasing amount of malware on the Bitcoin blockchain. One would even wonder if it's not a coordinated attack, enabled from within core.....

Save Bitcoin from captured core, run BIP110 on your node.

[ertil]

Had core implemented this filter in their next release, over 80% of the nodes would be running this filter today.

I am not so sure about that, because having a filter is decreasing node's performance, because that node first rejects a given transaction, and then tries to re-download it again, when it appears in the block. Which is also why many Knots nodes request more data from the network, than they should.

There was even a bug submitted, but of course, nobody was going to do anything about it, or test it more carefully, and it was simply closed later: https://github.com/bitcoinknots/bitcoin/issues/312

[PepeLapiu]

Had core implemented this filter in their next release, over 80% of the nodes would be running this filter today.

I am not so sure about that, because having a filter is decreasing node's performance, because that node first rejects a given transaction, and then tries to re-download it again, when it appears in the block. Which is also why many Knots nodes request more data from the network, than they should.

This is absolutely false for 3 reasons:

- First, if the majority of nodes enforce the filters, considerably fewer people even attempt to even broadcast those malware txs. It's kinda like a locked bike. If you leave your bike locked, fewer people will try to steal it as they clearly see it's locked. But if you leave your bike unlocked, every bad actor who sees it is more likely to attempt to steal it. Same with filters. Once they are widely implemented, they result in fewer of the offending malware.

- Secondly, Knots is not nearly as wasteful as core. When my node filters out malware, it doesn't get deleted, so that it has to get downloaded again if it gets in a block, like retarder wasteful core nodes do. What my Knots node does when if filters out malware, is it goes into my second mempool dedicated for malware. Which prevents me from having to download it again if it gets in a block.

- Thirdly, slowing down nodes when relaying a block with malware they filtered is the whole point of filters. Slower block propagation speed hurts the miner who fills his blocks with junk.

I actually has a discussion with Luke about this very subject. I was complaining that his second mempool pretty much negates the entire point of running filters. And he replies that the second mempool is optimized for miners or for people with limited bandwidth. And he added that the filters still would not relay the malware to others, and I have the option to turn off the second mempool if I'm not a miner or if I'm not concerned with bandwidth.

In any case, if core was so worried about users bandwidth, they would implement that second mempool too. But they don't want to do that, so they can use their own wasteful design flaws as an excuse to enae more malware on Bitcoin.

There was even a bug submitted, but of course, nobody was going to do anything about it, or test it more carefully, and it was simply closed later: https://github.com/bitcoinknots/bitcoin/issues/312

That ticket was created by someone who did not understand how the second mempool works. And it illustrates exactly how Knots is more efficient, less wasteful than core. In spite of having more filters than core.

[ABCbits]

Had core implemented this filter in their next release, over 80% of the nodes would be running this filter today.

I am not so sure about that, because having a filter is decreasing node's performance, because that node first rejects a given transaction, and then tries to re-download it again, when it appears in the block. Which is also why many Knots nodes request more data from the network, than they should.

OP probably talking about filtering Ordinal when it just starting gaining popularity. That way, compact block is still mostly useful due to low percentage of ordinal TX. While i support treating OP_FALSE OP_IF ... OP_ENDIF as non-standard since many years ago, who knows what actually would happen if Bitcoin Core actually do it.

There was even a bug submitted, but of course, nobody was going to do anything about it, or test it more carefully, and it was simply closed later: https://github.com/bitcoinknots/bitcoin/issues/312

In first place, what technical change could be done without also accept TX that already filtered on mempool?

[ertil]

who knows what actually would happen if Bitcoin Core actually do it

Miners will include these transactions anyway, just like they included for example transactions with fees below 1 sat/vB. Which would simply centralize the whole system even further, because then, to have an actual view of what is mined, you would need to ask mining pools, instead of just getting it in P2P way.

what technical change could be done without also accept TX that already filtered on mempool?

The problem is not that they are filtering these transactions. Any node can accept or reject anything on relay level. The main problem is that Knots requests the rejected transaction again, when it is confirmed in a block. Which means, that they can do, what they do, but they simply didn't handle all edge cases, which is why resource usage is higher for Knots connections, than for Core. You can observe it, if you use "getpeerinfo", and check "bytessent_per_msg" for all of your peers.

[PepeLapiu]

OP probably talking about filtering Ordinal when it just starting gaining popularity. That way, compact block is still mostly useful due to low percentage of ordinal TX. While i support treating OP_FALSE OP_IF ... OP_ENDIF as non-standard since many years ago, who knows what actually would happen if Bitcoin Core actually do it.

You guys are really really bad at logical analysis, or you are being deliberately deceptive.

Running filters on ordinals would have resulted in fewer ordinals, even before the filter is widely adopted. Because these malware assholes would be lessikely to keep doing business on Bitcoin, knowing that their scams will increasingly get filtered out with filter adoption.

And other scammers (runes/stamps/whatever) would also be less likely to set up shop on Bitcoin when they see how hostile we are toward their bullshit, and willing to filter them out and be assholes to them.

If you put a sign outside your town that reads "No redhead assholes allowed" you will end up with fewer redheads in your town, even if you don't enforce that rule at all.

But core has been doing the EXACT opposite of being hostile to malware. They removed the definition of bitcoin as money from their docs, they changed the definition of -datacarriersize to exclude ordinals, they rejected an ordinal filter, they refered to malware as "use cases" and they treated these assholes as if they were genuine users, not the grifters and assholes they really are.

And to top it all off, they actually removed a filter for these assholes.

Miners will include these transactions anyway

That's the old "filters don't work" bullshit trope. Okay, so if policy doesn't work, moving the filters at the consensus level with BIP110 will work. [/mic_drop]

The problem is not that they are filering these transactions. Any node can accept or reject anything on relay level. The main problem is that Knots requests the rejected transaction again, when it is confirmed in a block.

I already explained to you how this is false. Because Knots operates a second mempool for txs we filter out, so that we don't have to download them again and verify them again if they get in a block.
Retarded backwoods inneficient core nodes do that, not Knots.

Which means, that they can do, what they do, but they simply didn't handle all edge cases, which is why resource usage is higher for Knots connections, than for Core. You can observe it, if you use "getpeerinfo", and check "bytessent_per_msg" for all of your peers.

Stop spewing bullshit. Knots nodes are more bandwidth efficient than retarded malware core.

[pooya87]

That is a sad but true summary of recent history

I remember some people were even arguing that if we ignore the Ordinals Attack, it will just go away on its own! Well it didn't, it metastasized. And the burden is now heavily increased on nodes and UTXO set is so much bigger thanks to the massive number of garbage outputs the attackers created.

I said this a million times 3 years ago and this is the millionth and first time because it still baffles me: We used to prevent many of similar abusive transactions that exploited the protocol (eg. multisig dummy item) to inject arbitrary data into the chain, and for over a decade nobody called that "censorship". In fact everyone supported it.
So what happened to the community that all of a sudden a portion of the same community decided that preventing this particular attack is "censorship"?!

[PepeLapiu]

So what happened to the community that all of a sudden a portion of the same community decided that preventing this particular attack is "censorship"?!

I see there are two things going on at once that changes the community.

First, as expected, as bitcoin grows, the original anarchists and liberatians are getting dilluted by ETF/SMTR holders. Let's face it, we can't expect the whole world to all become libertarians.

And secondly, core inviting in all those malware assholes, that definitely changes what the community is becoming.

The saving grace is that none of those people are likely to run a node. Only hardened toxic maxis are doing that. But make no mistake, Bitcoin is on life support. That's going to change with BIP110.

[Dogedegen]

That is a sad but true summary of recent history

I remember some people were even arguing that if we ignore the Ordinals Attack, it will just go away on its own! Well it didn't, it metastasized. And the burden is now heavily increased on nodes and UTXO set is so much bigger thanks to the massive number of garbage outputs the attackers created.

This is not true and I do not know why you write this. The ordinals attack wave is gone, it has very little use now and nobody cares about ordinals. I think I have seen some user posting data on ordinals or OP return and it is clear that it is no longer that interesting. This means that it was just a passing trend and it created nothing of significance. If you had banned ordinals and if someone wanted to attack the network through the UTXO set, they could have just done dust transactions instead or some other approach. The filter would not have achieved anything except block certain uses of Bitcoin that you do not like, but at the same time the attack vector that you speak of would still be possible.

I said this a million times 3 years ago and this is the millionth and first time because it still baffles me: We used to prevent many of similar abusive transactions that exploited the protocol (eg. multisig dummy item) to inject arbitrary data into the chain, and for over a decade nobody called that "censorship". In fact everyone supported it.
So what happened to the community that all of a sudden a portion of the same community decided that preventing this particular attack is "censorship"?!

We learned to stop censoring people and how they use Bitcoin and that short-term solutions often have worse long lasting effects. If you run the filter game, it is clear that users would use worse methods that do more harm since they would have no other way of doing what you want. So the attempt at censoring would even cause more damage than good, and in that case what is the point of doing that? It is better to not do anything at all that do something that creates more harm than the current situation..

[PepeLapiu]

The ordinals attack wave is gone, it has very little use now and nobody cares about ordinals.

The ordinal malware attack could very well be fading away. And who knows how much of it is due to the community finally reacting and getting hostile to malware assholes, we can't ever measure that.

What we do know is that while malware such as ordinals are all scams, and yes, scams all have a shelf life. But the harm they cause is permanent. The 90,000 modes will forever have to carry the malware in their drives, and the 40% of malware dust will forever have to be carried in the UTXO set.

Doing nothing about malware scams on bitcoin and praying they will just go away on their own is just a retarded approach. Such a retarded approach sends the signal to other malware scams to coke set up shop on Bitcoin. So it should be of no surprise that shortly after core basically told the world tgeybwon't donanything about ordinak malware, other malware scams came on Bitcoin: stamps, runes, rate days, BRC token, you name it....

I for one, am not willing to wait until the world runs out of malware assholes and retarded idiots who buy into their scams.

I think I have seen some user posting data on ordinals or OP return and it is clear that it is no longer that interesting.

Whatever you read, must have been about ordinal malware, because abuse of op_return malware, both large and small, are on the rise.

This means that it was just a passing trend and it created nothing of significance.

The harm caused by those "passing trends" will forever remain on the bitcoin block chain. Node runners in 100 years will still suffer the harms caused by those attacks we fail to address today.
And doing nothing about every "passing trend" just results in more "passing trends" getting invited to Bitcoin.

As for the rest of your message, it's all coretard/shitcoiner slop. The fact that you frame attempts at preventing malware as "censorship", that you portrait those malware assholes not as attackers, but as "people who use Bitcoin", and that you just claim malware is merely "certain uses of Bitcoin that you do not like", that all betrays you are a core/malware apologist and a shitcoiner.

You can't see the problem because you are the problem.

[ABCbits]

what technical change could be done without also accept TX that already filtered on mempool?

The problem is not that they are filtering these transactions. Any node can accept or reject anything on relay level. The main problem is that Knots requests the rejected transaction again, when it is confirmed in a block. Which means, that they can do, what they do, but they simply didn't handle all edge cases, which is why resource usage is higher for Knots connections, than for Core. You can observe it, if you use "getpeerinfo", and check "bytessent_per_msg" for all of your peers.

Interesting point. But without requesting the filtered/rejected TX, it means Knots node can't do full block verification.

We used to prevent many of similar abusive transactions that exploited the protocol (eg. multisig dummy item) to inject arbitrary data into the chain, and for over a decade nobody called that "censorship". In fact everyone supported it.

Do you have more information about it? I thought adding arbitrary data on P2MS or P2SH multisig is still possible today.

That is a sad but true summary of recent history

I remember some people were even arguing that if we ignore the Ordinals Attack, it will just go away on its own! Well it didn't, it metastasized. And the burden is now heavily increased on nodes and UTXO set is so much bigger thanks to the massive number of garbage outputs the attackers created.

This is not true and I do not know why you write this. The ordinals attack wave is gone, it has very little use now and nobody cares about ordinals. I think I have seen some user posting data on ordinals or OP return and it is clear that it is no longer that interesting. This means that it was just a passing trend and it created nothing of significance. If you had banned ordinals and if someone wanted to attack the network through the UTXO set, they could have just done dust transactions instead or some other approach. The filter would not have achieved anything except block certain uses of Bitcoin that you do not like, but at the same time the attack vector that you speak of would still be possible.

What? It's true that total UTXO and UTXO growth rate was faster when Ordinal was popular, https://statoshi.info/d/000000009/unspent-transaction-output-set?orgId=1&from=now-5y&to=now&timezone=browser&refresh=10m. It's also known to make initial sync slower on device with low RAM (not enough to store all UTXO set) and without good SSD to allow fast UTXO read/write.