See, you fall for Slopp's manipulations.
Spam forms currently more than 40% of Bitcoin's transactions.
Large OP_RETURNs just give more options to the spammers. It does not fix inscriptions or ordinals or any other form of spam.
Discussion
Did you miss the “since” part?
> since block height 930,600 (Core v30 release)
How is that “manipulative”? It seems very clear to me.
Why did spammers go to all of the trouble of creating inscriptions, which store data in non-prunable UXTO records, instead of OP_RETURN, which can be pruned off?
Because that is meaningless comparisson.
If you compare number of OP_RETURNs larger than 83 Bytes before Core V30 and now you will see huge increase in the numbers now.
by meaningless its meant manipulative, Slopp picked it on purpose of course
I don’t think it’s meaningless. The fear mongering about increasing the default limit size in the client has been proven to be nonsense so far, since only 0.001% of transactions added have used it, and Bitcoin is not destroyed.
It’s going to take awhile to scan the blockchain data for transactions with OP_RETURN data >84 bytes before and after block 930600.
To clarify your claim, do you think that there is a greater number of transactions whose OP_RETURN data is >84 bytes after block 930600 than there was before that block, or by “huge increase in numbers”, do you mean a greater amount of data is stored in OP_RETURN after block 930600 than there was before?
Until September 2025 there were in total around 15? OP_RETURNs larger than 82 Bytes.
Now will be multiples of that amount and if we don't do anything the numbers will continue to grow.
If you can't comprehend that more than 40% of Bitcoin transactions are spam, and now in addition large OP_RETURNs are possible and you think thats fine, then you are not a Bitcoiner. Jameson Slopp for example is an evil shitcoiner.
You just acknowledged that there are transactions with >83 bytes in the blockchain added before v30. But then you immediately contradict yourself by saying, “and now in addition large OP_RETURNs are possible”.
Clearly, they were already possible, if there were already “around 15” added before v30 (I think there is a lot more, and my query is still running). So how do you reconcile this contradiction in your mind, while still believing that the change to the default settings in the v30 client makes a difference?
I can help you out: it doesn’t. Changing the default settings in a client does not affect consensus rules. All valid transactions can and will be added to the blockchain. Client settings are not consensus rules.
What is your preference, spam in a prunable field, like OP_RETURN, or spam in permanent ones, such as UTXOs? As BitMex research showed by storing images in private keys, everything in Bitcoin is data, so it will always be vulnerable to abuse.
https://www.bitmex.com/blog/the-unstoppable-jpg-in-private-keys
You need to study Bitcoin better. Before the malware Core V30 large OP_RETURNs were possible only when compromised miners directly added them because the node network was rejecting them on policy level. Now Core V30 allows them in the mempool. What I am saying is not contradiction.
My preference is no spam.
Incorrect. Users have always been free to change the default datacarrier setting from 83 bytes to whatever they want. Core v30 just changed the default setting.
> My preference is no spam.
Yeah you and pretty much everyone. So should we ban private keys, or what is your solution to the problem that BitMex Research proved?
First we should BIP110 then we will see. If is pretty much everyone against spam then BIP110 should have full support.
Don't forget the compromised Core devs also wanted to deprecate the option to set your datacarrier size.
No. Changing client settings does not affect consensus rules. Only consensus rules determine what a valid transaction is. Since everything in Bitcoin is data, everything can be used for spam. Read this ffs:
https://www.bitmex.com/blog/the-unstoppable-jpg-in-private-keys
The compromised Core devs under the influence of shitcoiners VC money like Jameson Slopp, Citrea, Peter Thiel and others removed the filter in the malware Core V30 and tried to deprecate the option to set own limits to datacarrier size. The defaults matter.
Now that invites more spam. Currently more than 40% of the transactions on Bitcoin are spam.
That can be fixed with BIP110 that will limit arbitrary data on consensus level.
Are you so fanatical that you refuse to learn new information? No, you cannot limit arbitrary data, because Bitcoin *is* data.
1. The datacarrier size field for OP_RETURN data is and always has been a setting that users of the client software can change. The default setting was 83, and as of v30 it is 100000. Users (of any version) can change it to 83 if they want. Or 300000. Or whatever. It is up to the user. Only the default value changed.
2. If by "removed the filter" you mean the option to relay transactions with arbitrary data, you are wrong - the option is still there in v30. I just verified on my node.
3. The client software (there are several available) merely relays transactions from the mempool, it does not control what miners can include in blocks. Miners can use any client software they want, with any settings they want, and are incentivized to compose blocks with the highest fees. Once valid blocks are added, all nodes will add them to their copy of the chain.
4. The BitMex article that you refuse to read proves that spam can be stored in *any* area, even private keys. We cannot ban private keys. Ergo, we cannot ban spam. It is a moot discussion, because Bitcoin is made of data, and therefore data can be stored in Bitcoin. Get over it.
So the question is one of incentives: do we want to incentivize storing of arbitrary data in a non-essential field that can be pruned, or in non-prunable, essential fields like UTXOs? You seem to want permanent spam instead of prunable spam.
As weak as client settings are for incentivizing, maybe it will make a difference in the long run to suggest a prunable field for arbitrary data, so that nodes can choose a smaller data footprint by enabling the pruning option. Unfortunately inscriptions have already been invented, so the technology is available for storing data across UTXOs, permanently.
I'll never understand how people become so enamoured with drama queen narcissist losers like Roger and Luke, who revel in the attention they get from their stupid, ill-advised causes. Restricting data sizes willy-nilly out of blind spite for spam *will* break functionality for important technology like the Lightning network, and complex signature structures that will be important for business operations in the future. Let's not throw the baby out with the bathwater, and undermine confidence in Bitcoin, just as it is becoming part of the global financial system.
Are you so blind that you can't make a difference between financial data on Bitcoin and spam data / jpegs?
Speaking about fees, didn't you see this?
... also nothing will brake, don't need to FUD
We can start with BIP110 and the tackle other challenges.
We literally can’t. If BIP110 were implemented, the technique shown by the Bitmex Research article would still work. And there is no limit to similar techniques for any other bit of Bitcoin data structures. The more restrictions placed, the more insidious the data injection techniques will become. And the more difficult it will be to build needed layer 2 & 3 technologies on Bitcoin.
It is not FUD to say that arbitrary changes to data limits and relay policies are likely to break L2/3 technologies. Lookup “Lightning network ephemeral anchors” for a pertinent example.
Thats complete BS.
First of all Bitcoin is not "data". Bitcoin is P2P ecash - Freedom Money.
Second, BIP110 will contain the major issues with spam. If we reduce it with 90%, that will still be good.
Third, there are other solutions to contain spam.
Is “P2P ecash” made of wood? Glass? No, it is made of bits of data. Fundamentally, the Bitcoin blockchain is data. It represents financial transactions, contracts, identity, and unfortunately, spam.
Being made of data, there is no way to police what every bit of data represents at a macro level, in the external world. Proof of this is here, if you care about the truth.
https://www.bitmex.com/blog/the-unstoppable-jpg-in-private-keys
wrong, there is a way
There is also a Cat that chases spam using the spammers own rules.
BIPS are discussed/assessed here:
Here’s the PR:
So far, I have found 13,574 OP_RETURN outputs > 83 bytes, before v30 was released. ~25,300 blocks left to be checked.
My scan of the blockchain data for OP_RETURN outputs > 83bytes, prior to block 930600, when the default size setting was updated to 100000 bytes, is complete. I started at block 290,000, since thats about where the OP_RETURN field was introduced.
```
=========
RESULTS
=========
Scan range: blocks 290,000 to 930,599
Time elapsed: 27.56 hours
Average speed: 6.5 blocks/second
Blocks scanned: 640,600
Transactions scanned: 1,258,073,612
Transactions with OP_RETURN > 83 bytes: 577
Total OP_RETURN outputs > 83 bytes: 13,962
Size distribution by frequency (top 20):
142 bytes: 4,833 outputs
140 bytes: 2,931 outputs
138 bytes: 1,950 outputs
111 bytes: 420 outputs
137 bytes: 378 outputs
143 bytes: 247 outputs
122 bytes: 246 outputs
129 bytes: 237 outputs
139 bytes: 223 outputs
121 bytes: 198 outputs
118 bytes: 164 outputs
120 bytes: 140 outputs
131 bytes: 121 outputs
135 bytes: 76 outputs
141 bytes: 69 outputs
128 bytes: 65 outputs
132 bytes: 64 outputs
133 bytes: 62 outputs
153 bytes: 53 outputs
145 bytes: 46 outputs
... and 474 more distinct sizes
Size range: 84 - 984593 bytes
```
It is notable that the vast majority of outputs are using less than 150 bytes, so probably used by various scripts, rather than jpeg data.
This means that almost all of the spam is in non-prunable, permanent records, probably inscriptions.