I guess I'm still not following why Core decided to do this. Why open up this battle right now, was anyone actually asking for this? This just seems like a tactical error on Core's part, or theres something that they are trying to distract us from like covenants or something.

I don't see the upside for them, and it seems like the end result is more implementations of Bitcoin will get support - which I'm okay with, because if the others get some traction I would think they would all need to be somewhat in agreement on the big things or risk a fork. MAD for changes to Bitcoin.

Reply to this note

Please Login to reply.

Discussion

Core has not implemented this change this is a pull request from Peter Todd

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

nostr:nevent1qqsxthnhp9vx0aqqe92ceejfj33cwpstr8mmend6edyrelje9zhpjjszyzf8jfmtl7urem3nj3h9vnpkqz3jsspxn2pqd5qamaqvvset4g9ukqcyqqqqqqg5hq343

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.

If this is the case the throughput is limited to only when Mara finds a block which is like once a day?!

Seems like every two hours, but yeah.

F2Pool also mines transactions created by OP_RETURN_BOT

Yeah it’s exactly the same argument people make about illegal drugs. Considering it’s possible to sell some on the street, we should just let dealers sell in the supermarket.

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.

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.

Mara found 6% of blocks last week meaning a 16 block waiting period on average to get some spam on chain. And because the spam is large that means only a few big spam txs every few hours.

You would also count f2pool

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.

This discussion has taken up air for the last 11 years, it is not some spur of the moment kind of thing. No Bitcoin Core developer is asking for people to embed data on chain. Giving them the option to do so in a way that minimizes negative effects for node runners.

Search posts including the word "Citrea" here on Nostr, as well as on the GitHub discussion and the mailing list discussion about OP_RETURN.

Antoine addressed this at btc++. Not sure if it was recorded but I’ll try to dig it up.

My recollection of what he said:

He had a discussion with one of the jpegoors at a recent conference, was shocked at the extent to which the protocol was being abused to store data in the utxo set and came to the conclusion that a) core and spammers need more open communication lines and b) removing the limit was a concrete step that could be taken now.