Out of over 1,500,000 OP_RETURN outputs created since block height 930,600 (Core v30 release) only 0.001% have been larger than 83 bytes.
So much for "blowing out the OP_RETURN limit" killing Bitcoin, eh nostr:npub13xk3uj6xj8c70du3stwzhhmchhfmxy9x0dakw04fh5gxwavl8lpsegef92?
👀
Wrong npub bruh
Bitcoin was supposed be to be dead by now
So much for Jamaeson Slopp's disgusting manipulations.
Spammers use all possible ways to bloat the Bitcoin blockchain and Core V30 is the spammers highway.
Core V30 is malware and an attack on Bitcoin.
nostr:nevent1qqs84l697rzr9uafmgna0ntuxxwzhhfk69yfdgudna2flm0dru6xz7gppemhxue69uhkummn9ekx7mp0knq2a8
So much for Jamaeson Slopp's disgusting manipulations.
Spammers use all possible ways to bloat the Bitcoin blockchain and Core V30 is the spammers highway.
Core V30 is malware and an attack on Bitcoin.
0.001% of transactions are larger than 83 bytes, on a prunable field, is bloat, in your view?
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.
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.
Also notice how the scammer Jameson Slopp is pointing to a scammer account that impersonates Matt's Kratter.
Matt Kratter real account is nostr:npub1s33sw6y2p8kpz2t8avz5feu2n6yvfr6swykrnm2frletd7spnt5qew252p
(but of course Slopp did that "unintentionally")
Dishonesty to your core. (Pun intended)
You know damn well that that is not nostr:npub1s33sw6y2p8kpz2t8avz5feu2n6yvfr6swykrnm2frletd7spnt5qew252p you tagged.
You are a real piece of shit.
/hat
🧡👊🏻💩
Still with this shit bro ?
I thought everyone already figured out that your corrupt
lol
Another entry in the Bitcoin obituaries 😅
Looks like you touched a nerve nostr:npub17u5dneh8qjp43ecfxr6u5e9sjamsmxyuekrg2nlxrrk6nj9rsyrqywt4tp . ;)
All it takes is one.
So it's an unnecessary threat to Bitcoin that only benefited less than 0.001% of the network?
Dishonesty to your core. (Pun intended)
You know damn well that that is not @BitcoinUniversity you tagged.
You are a real piece of shit.
/hat
🧡👊🏻💩
What? 1.5m? 10x more
You can search through all of them on opool.space
At least 16m op_return written on Bitcoin. You can now explore all OP_RETURN with opool.space
"only 0.001%"
Does that mean that v30 was a fLopp?
How about reversing that shit show (V30) to how it was, and tell that 0.001% to start using shitcoins again.
Rug the Scammers
It's now the most used node software version. So no.
Blocks are not big enough
Fees are too high
Bitcoin is boiling the oceans
Ordinals!
Nothing changed and somehow also those went away.
So you're saying it didn't needed to be increased. agree.
Core started a war because of 0.001% of op_returns user needs, if we think of all txs the percentage is way smaller. Thanks for Lopp for bringing this up.
Knots proponents:
Wonder what the next ‘current thing’ will be
Yeah. Nobody even uses it (for good or bad things yet)
Meaning we didn't even need it and it shouldn't have been done.
No Bitcoin University degree for you.
#40HPW🎧
Can you guys stop fighting, you're waking the neighbors
It is not a coincidence that ATH was the day core v30 was released.
You and your friends installed a killswitch on bitcoin.
Your are compromised
Forgot about this already lmao
Then why increase it you stupid spammer faggot?!
Wasn't the whole point to encourage spammers to use "less harmful" op_return over other options? So your idiotic change is completely useless, but you made your friends at citrea happy. You are truly a piece of shit.
