Nostr Web Client

Definitely. The OP_RETURN’s existence is what made Vatalik not build eth on Bitcoin.

Real talk, don’t trust verify!

𝕞𝕪𝕡𝕒𝕥𝕙𝕥𝕠𝕗𝕚𝕣𝕖 8mo ago

Yes, something with their upcoming bridges they are planning, they don't want to have to use a workaround it looks like.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 8mo ago

i believe there's still plenty of nodes running old versions and i don't see them upgrading on the whim of influencoors on X

but it's worth talking about because they are playing at getting their spam on as many nodes as possible

i certainly am not upgrading core now because of this, and i'm probably already running the second newest version, i think i also set some settings to reject a lot of data transactions, after lukedashjr posted instructions

Yes this is a numbers game they need to get as many nodes as can they can to remove the limit so they ultimately throttle the throughput of the network and inject maximum spam.

This change is not likely to increase that behaviour. It is meant to shift behaviour.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 8mo ago

psychological warfare

Yeah because spammers are going to pay MORE to stuff their spam in the OP_RETURN You must really be a charlatan to think spammers will pay more because they care are about the network.

I don't think they will either if the choice is there. Some want/have to embed their data in non-discounted outputs. I'd rather have them put it into a OP_RETURN than in some fake key output.

Sorry I shouldn’t check Nostr when I wake up before I drink my coffee, I clearly misread your comment!

unknown 8mo ago

Man. I need to talk this through with someone. I’ve been trying to dip in and out of the comments for the last couple days, and I’m still a bit lost.

CarteBlanche 8mo ago

You are on the right side of history.

Crizzo 8mo ago

I've been following this as best I can as a non technical person, but I don't think you need to be technical to see that the arguments in favor are weak when considering the potential tradeoff of allowing unlimited arbitrary data to be recorded on chain. I really get a sense that there is an ulterior motive from core devs and others pushing this change and they are not being honest about their reasoning.

Mike Tidwell and I have collected a bunch of questions and answers around the OP_RETURN debate here: stacker.news/items/971277

I would hope that this collection helps with understanding the perspective of Bitcoin Core contributors.

Crizzo 8mo ago

These are way better explanations than anything I've found on nostr. Thank you for the link.

Bitpunk 8mo ago

Is there currently a discussion going on about the witness discount as well, since it seems quite related to this whole saga?

These guys continuously move the goal posts. Once you bring up the fact that spammers are not going to voluntarily pay more to stuff spam in the OP_RETURN they shift the conversation.

How so? The observation that OP_RETURNs are more expensive for larger data payloads has been a central argument why "spam" is unlikely to increase overall by this change.

Spammers are not going to stop using SW for OP_RETURN. The UTXO sets will continue to bloat.

The only things this change will do is help spammers propagate their spam and create new types of spam.

Not that I know

jgbtc 8mo ago

I read through that and it made me less supportive of this change. The motivation of core devs is clearly to make spam cheaper at the request of a company that is paying the same core devs to make this change. These devs have sold out, plain and simple. It's disgusting.

Gavin Green 8mo ago

Thanks guys, super usefull to get a quick summation of the situation.

Aida 8mo ago

Euro-Corn in an hour and half. You can tell us all about it. #eurocorn

Big Barry Bitcoin 8mo ago

Here's what I've collected. I feel like it boils down to this.

For:

1. Users want to degen and they are creating unprunable dust.

2. An OP_RETURN limit removal might incentivise them to use prunable utxos.

3. Unofficial relay alternatives already exist for non standard transactions and may continue to develop, reducing the transparency of bitcoin, (making it harder to identify attempts of real censorship?)

Against:

1. Filters are decentivising degen in general.

2. Removal might increase non-monetary usage of our Bitcoin nodes.

3. This does not prevent spammers from intentionally creating unspendable dust.

4. Non standard transactions has always been a thing, we can add to the standard list or expand the definition of standard when we need, but we don't have them for no reason. Why not make any valid transaction standard?

I put a part of it in brackets because I haven't heard anyone explicitly say this, I've heard "it will make it less decentralized" which is a sweeping statement IMO. But I feel like this is what the devs are pointing out, they're just not saying it. Regardless, it is something to consider.

Nice assessment! The only thing that will be more decentralized would be spam. They are arguing that the spam itself is not decentralized. Like you mentioned there is a reason for the limit. It’s a feature not a bug. The other thing is storing data in the SW is cheaper but more harmful why would spammers voluntarily pay more to spam the network?

Big Barry Bitcoin 8mo ago

I don't think that is their argument, IMO those words in that order makes no sense. "Spam itself is not decentralized"?

Are you saying point blank that they WANT more diverse types of transactions on the blockchain?

That might be so.

Either way, I lean your way honestly. It is concerning that there is not a lot of different use cases being thrown around other than Citrea as far as I can tell.

Big Barry Bitcoin 8mo ago

So new context...

When mentioning decentralization, I have heard a clarification explaining that they were thinking about miner decentralization.

Still, I can't shake the feeling that you can't call a PR purely technical when it is a change that affects game theory. In this case the game theory as to whether a minority of miners will gain an advantage by capitalising on a private market that the overall network applies friction too otherwise.

This wasn't just a change from an int to a long, or the parallelisation of actions. This is a change that has external effects and that should affect whether you ack or nack.

sudocarlos 8mo ago

What's your counter to "if they cant use op_return then they will include it in the witness and thats worse because witness it cant be pruned and creates an unspenable output, further bloating the utxo set" ?

Ľḭṿḙśƫṟãɖãṁṹṧ💫#RunCoreV30 8mo ago

Yeah am also curious about this in the discussion

This argument is a decoy.

1. It’s cheaper to spam in the SW

2. No guarantee that spammers voluntarily pay more to spam in the OP_RETURN

3. The people pushing this so called solution are the same people who created this problem.

The real agenda is to force as many node runners to relay their spam.

Right now they are only able to include these spammy txs in a small percentage of blocks. If all core node runners removed the limit on OP_RETURN size there would be significantly higher chances of their spam being included in blocks. This could also be used to throttle the network throughput ultimately lowering transactions per block.

sudocarlos 8mo ago

#3 👌

1. It is not cheaper for all data sizes.

2. Some embed data in multiple fake key outputs. There is no stopping that. OP_RETURN gives them an alternative.

3. Not sure what you mean here, but I don't think any regular Bitcoin Core developer has gone and inflated the UTXO set with data?

48

482d28d8... 8mo ago

Spammers are incentivized to use the witnessspacee, therefore removing a spam filter will only give them more opportunity to spam.

Witness data is counted at 1/4 of the data in the legacy part of the transaction. OP_RETURN lives in the non-witness scriptPubKey, so even if you allow arbitrary large OP_RETURN each byte still cost 4 weighted units, whereas the very same but pushed into the witness costs only 1 weighted unit.

Core knows this. They are compromised.

BaronBurdock 8mo ago

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.

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

https://x.com/peterktodd/status/1919082738629398772

https://x.com/lopp/status/1919104031114367293

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:nevent1qqsxthnhp9vx0aqqe92ceejfj33cwpstr8mmend6edyrelje9zhpjjszyzf8jfmtl7urem3nj3h9vnpkqz3jsspxn2pqd5qamaqvvset4g9ukqcyqqqqqqg5hq343

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.

nostr:nevent1qqsvm8jq3ly4sdllfwrs53deqmmgjyu278q682ra5eqtvllpm82f94szyqzvj9w6alhrsvtl5u6ygjkwuwg2sf5lukqskgjpuhnd6dpal0kvjqcyqqqqqqgprpmhxue69uhhqun9d45h2mfwwpexjmtpdshxuet5qyvhwumn8ghj7um9dejxjapwdehhxenvv9ex2tnrdaksz9nhwden5te0wfjkccte9ec8y6tdv9kzumn9wschmt3e

I just posted a reply in that thread.

nostr:note1h8cmvxfgg64t9uaz2y5r7jvd3ddmejz68njh6duax38ee4w2w0gscrzkvg

My bad 😂

All good 👍

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?

stian 8mo ago

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/

Kevin Ravens₿erg ⚡️ ☁️ 8mo ago

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.

https://mempool.space/tx/0f1a21afa721c9c8269529d301f964b5b5121f94071004720f6bcbcc3e4048da?mode=details

F2Pool also mines transactions created by OP_RETURN_BOT

70

Deleted Account 8mo ago

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.

M0053 8mo ago

No one had said it is impossible.

Your argument is fallacious. ( the All or Nothing fallacy)

DarthCoin ₿⚡️ 8mo ago

LOL check this one

chrizzz 8mo ago

Lmfao

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?

https://wavlake.com/track/fbf9f568-4b98-417b-818d-8fdae2784f7b

wait, are you in the Timechain Police Puzzl35 !?

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. 😊

https://mempool.space/block/00000000000000000000c2a3e7f770a0617ac8693946ed7c62d895300f88e79d

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.

average Joe 7mo ago

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.

Murch 7mo ago

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.

average Joe 7mo ago

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

BaronBurdock 8mo ago

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

aj 8mo ago

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.

BitcoinIsFuture 8mo ago

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

aidan 8mo ago

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.

Kayne 8mo ago

Clearly core devs are out of touch.