Core has not implemented this change this is a pull request from Peter Todd
Discussion
None of these guys address the point I have made about forcing as many node runners as possible to relay their spam. Itās not easy to make transactions that exceed the OP_ RETURN limit. Benās bot still has to comply and can only spam transactions that are under the 80 byte limit. They can only get these large spam transactions when a miner they coordinate without of band with finds a block. If all core node runners remove the limit then all miners would be able to include those large spammy transactions and it would occur more regularly which would decrease the average number of transactions per block over time.
nostr:npub1j5mp526z5fkz9wkrk6mt5nzu43xndyrwkr8mnqngdqwytgcpc5vqcnsd5c is answering question on stacker news
This guy Murch is basically saying we only need 10% of the node runners to pass around spam and then we are unstoppable so we should just remove the limit. Obviously they canāt do that grassroots style or libre relay or whatever Toddās spam blaster is called would be enough. They want to fire this on core node runners and are hoping that half of the runners on the latest version blindly update so their spam can be passed around.
Hey, dumb question. Given that is not possible to get large OP_RETURNs mined how come that more than twenty have been created this week alone?
Think you can get them mined if you go directly to a miner and ask them to include it, if I understood it right? Itās just a lot more hassle than submitting it to any node and let the network bring the spam out for you.
It's like three clicks on a website. https://opreturnbot.com/
Exactly, itās no hassle at all. But not relaying how much fee is paid for this will make lightning fees unpredictable
Important to state that this bot still enforces the 80byte op return limit.
It will become this easy if core removes limit
I think the bot just posts directly to mara's slipstream and ignores the limit.
No one had said it is impossible.
Your argument is fallacious. ( the All or Nothing fallacy)
No one is saying that the spam can be completely stopped or canāt be mined. I have been clear that this doesnāt prevent the spam but limits and throttles the spam.
What makes you so sure? Have you tried it? From what I hear and see, the OP_RETURNBOT creates larger OP_RETURN outputs just fine.
I checked a few and they were all under 80bytes can you share some that exceed the limit? nostr:note10w7zywg6880y97rr2kq480vfs0rjrkvwkvqhk6hkc2pa9enjp0js402fm2
Also I would appreciate if you or someone addressed my statements about why libre relay is not enough for team spam.
See e.g. https://mempool.space/tx/a527c6f4f4e7148f5b84cfb3a896dd02e9477fe9cf1f4b03c32f5c056c8a648c
https://mempool.space/tx/3183bd6ceebc2d39c0a3cfa0d06eb84d1161eaac1c26605e2eab62bfe48c1420
https://mempool.space/tx/64a4b1efaeedfe88596c118f7ba5b48cac498cbdb51bc3e8366edd0d20da2662
Could you clarify what you mean when you ask "why Libre Relay is not enough"?
Enough for what? What do you think is the goal here?
If spammers can already get their spam onchain via libre relay and tools like Ben's OP_RETURN bot then why do you and bitcoin core insist on removing node runners ability to set OP_RETURN limits?
I suspect it's because there is a still a low probabilty of getting the spam in the next block. Like i mentioned earlier MARA is only finding around 6% of blocks. If the spam is a 4mb tx then that means only 1 spam tx every few hours.
The goal is to force as many node runners as possible to propagate spam across the network.
If Bitcoin Core removes the OP_RETURN limits then all miners running the new version of core will see the spammy 80+ byte OP_RETURN txs and can include them in their block templates. This would significantly increase the likely hood of spam making it onchain.
If the whole point of this is to reduce UTXO bloat then why isn't core placing a limit on the size of the SW?
wait, are you in the Timechain Police Puzzl35 !?
https://wavlake.com/track/fbf9f568-4b98-417b-818d-8fdae2784f7b
Resisting is the opposite of policing. Core is the one forcing their preferences on their users.
bitcoin core users choose to run core.
knots users choose to run knots.
libbitā¦
btcd..
that sounds like a nice choice of software for node runners. š
Yeah, actually. Right now it's basically certain that transactions with larger OP_RETURN outputs get included. People that don't care how quickly it gets confirmed have no issue, but it happens unreliably, so users that feel the need to write time-sensitive data commitments may prefer writing them to payment outputs in fake pubkeys. So yeah, it would be better if Op_RETURNs got mined reliably.
Satoshi Disagrees
āPiling every proof-of-work quorum system in the world into one dataset doesn't scale.
Bitcoin and BitDNS can be used separately. Users shouldn't have to download all of both to use one or the other. BitDNS users may not want to download everything the next several unrelated networks decide to pile in either.
The networks need to have separate fates. BitDNS users might be completely liberal about adding any large data features since relatively few domain registrars are needed, while Bitcoin users might get increasingly tyrannical about limiting the size of the chain so it's easy for lots of users and small devices.ā
Blocks are generally full, so this cannot increase the size of the chain. In fact, since op_return data is written to output scripts, it may displace witness data and shrink blocks in average. Either way, Satoshi wrote that a decade ago, who knows what he would think today if he had been around to see everything that happened since then.
First off blocks are not full they have been on average 1.6MB since the last halving over 50,000 blocks ago. They would be full if we never changed from 1mb to 4mb blocks.
Satoshi was clearly in favor filtering out spam. He set the OP_RETURN to false before being spooked by your colleagues. 
Segwit limited the block weight to 4,000,000 weight units (WU). Blockspace has been almost fully demanded since Inscriptions started taking off around February 15th, 2023. Bitcoin Core reserves 4000 WU for the coinbase and block header, so Iāll count any block above 3,960,000 as full.
There have been 119,418 blocks since February 15th 2023. Out of those, 341 blocks were empty (below 2000 WU), 1155 blocks were non-empty up to 90% full (i.e. between 2001 and 3,600,000 WU), 292 were between 90% and 99% full (3,600,001ā3,960,000 WU), and 117,630 have been full (3,960,001 or more). In the past ~27 months, 98.5% of all blocks were using at least 99% of the block weight. I have no idea what you are talking about when you say that blocks are not full.
Mea culpa, reading my own post, two things come to mind. Until Bitcoin Core 29.0, we were reserving 8000 WU for the block overhead, it only went down to 4000 WU in 29.0., I should have been counting blocks as full starting at 3,992,001 weight units or more, i.e. 99.8% full (less than 8000 WU left). Per this metric, there were 117,100 blocks full instead of 117,630, which also letās us deduce that there were 530 blocks that were between 99% and 99.8% full.
Wouldnāt you expect 100% full blocks in BTC?
If there was no pilot in 1-2% of all planes you wouldnāt call them full either.
I am not sure I get your point. There are occasionally some blocks that are completely empty, and sometimes miners accidentally include less transactions than are available, e.g. because they build a block with a recently restarted node.
We also have recently cleared the mempool a few times, so at those times non-full blocks would have been expected.
Ah ok. I knew about completely empty blocks. Didnāt know the other reasons. Thank you for the explanation.
Witness data is not stored in the UTXO set. It's part of the input data. OP_RETURN data weighs 4 wu per byte. Blocks are limited to 4,000,000 weight, so a block full of OP_RETURN data is cannot be much more than 1MB.
Right I probably haven't phrased that right about it still being a PR, but my understanding was that Peter Todd put forward the PR and Core was looking to merge until things blew up, or at least I got that impression from watching Mechanics video
Antoine posted to the mailing list about fixing a problem with an L2 Citrea was developing (" I suggest to start by lifting the restriction on the size of the scriptPubKey for OP_RETURN outputs, as a first minimal step to stop encouraging harmful behaviour"), then Peter refiled his previously rejected PR to immediately lift all related restrictions and immediately remove related configuration options. That then engaged people, and got Peter invited onto conference panels to talk about himself.