pull down to refresh

Mom and Dad are Fighting....Again (Re: Bitcoin Core OP_RETURN Restrictions)

1794 sats \ 27 comments \ @unschooled 28 Apr bitcoin

If you were on Nostr or Bitcoin x today, you may have noticed some stirrings in the OP_RETURN debate. Recently @petertodd opened a pr to remove limits on OP_RETURN outputs.

To preface this, for those not aware, "OP_RETURN is a script opcode in the Bitcoin protocol that allows a transaction to store arbitrary data on the blockchain. It is a way to embed data, such as text, images, or other types of information, into a Bitcoin transaction."¹

To my understanding, it is this opcode that allows for ordinals.

In a recent bitcoindevs mailing list discussion, "Relax OP_RETURN Standardness Restrictions", a few heavy hitting bitcoin core devs, besides Todd, throw their weight around re OP_RETURN (pertinent quotes and a summary of their positions to follow).

Honestly, when I read this, and see the staunch oppositions, it feels like mom and dad are fighting. I am powerless and must be content to understand but little of what is actually happening. Perhaps they both want what's best for me, although, they clearly have differing points of view.

In sum, many of the devs contributing to the discussion support dropping the OP_RETURN limits, which has raised concern.²

At any rate, I used AI to help me understand better so you don't have to.

A summary of their positions

Antoine Poinsot proposes relaxing the restrictions on OP_RETURN outputs to stop encouraging harmful behavior and allow more flexible use of the blockchain.:

Since the restrictions on the usage of OP_RETURN outputs encourage harmful practices while being ineffective in deterring unwanted usage, i propose to drop them.

Sjors Provoost suggests dropping both the size limit and the limit on the number of OP_RETURN outputs per transaction to avoid repeating the discussion in the future.:

Increasing the OP_RETURN limit reduces harm compared to the two alternatives: 1. UTXO set bloating with fake public keys 2. Large scale bypassing of the (default) mempool...

Peter Todd agrees with dropping both limits at the same time.

I would suggest removing both limits at the same time. While multiple OP_Return outputs are more expensive than a single one for the same amount of total data. In some cases they're necessary for technical reasons, e.g. if signing with SIGHASH_SINGLE.

Pieter Wuille conceptually acknowledges (ACK) relaxing the OP_RETURN limits, including removing them entirely, due to the existing demand for such transactions and the potential for pushing that demand to bypass the public network.

Concept ACK on relaxing the OP_RETURN limits, including removing them entirely... I recognize the reality that demand exists, and the alternative of pushing that demand to bypass the public network is far more damaging.

Luke Dash Jr strongly opposes the idea, citing concerns about spam and abuse, and suggests that the bugs should be fixed rather than embracing the abuse.

It should be needless to say, but this idea is utter insanity... The bugs should be fixed, not the abuse embraced.

Antoine Riard mentions a potential downside of relaxing OP_RETURN restrictions, where a single transaction output with an "exogeneous" value could be worth more than the block reward, potentially leading to issues with double-spends and chain reorganizations.:

That could be an issue where a single transaction output owner with an 'exogeneous' value braodcast a tx for a double-spend where this condition can only be included if the block is reorged-out...

Vojtěch Strnad references a stack exchange post that explains his reasoning for how OP_RETURN restrictions are not effective in deterring unwanted usage.

Sjors Provoost and Pieter Wuille discuss the potential consequences of pushing demand for transactions to bypass the public network, including centralization and the loss of permissionlessness.

Written with the help of MapleAI ↩
Some @BitcoinMechanic 's comments on the Bitcoin Core Github resulted in him being banned ↩

view all related items

0 replies \ @unschooled OP 28 Apr

Correction the comment marked as abuse was not Mechanic's, but 1ma's.

41 sats \ 8 replies \ @Murch 23h

BitcoinMechanic was not banned; a comment of his was collapsed. It's still there, you just need to click it to expand it to read it.

342 sats \ 5 replies \ @optimism 21h

Hey Murch,

I (as an outsider to Bitcoin Core that for over a decade follows code, pull reqs and mailing list as time and abilities permit) have the feeling that currently there's a bit of re-prioritization going on with all the moderation, where the focus shifted from product excellence to people excellence.

Do you know of any plan to prevent this new "feature" from resulting into a consolidation of people/perspective? I.e. how are the people that enforce the moderation or benefit from it defending this power against their own interests? I'm asking because we're all humans and we're all fallible (and we can all get rubber hosed) and I'm getting a bit worried at this point.

Apologies in advance to bother you personally; you're someone I've built up huge respect for over the years so I figured I'd just ask.

600 sats \ 4 replies \ @Murch 18h

Hey @optimism,

moderation starting to get used for political purposes sounds like a fair concern to me, although I don’t think that people excellence and product excellence are necessarily at odds. We have had a few contributor problems in the past years, one of which just got too hard to ignore recently, most others eventually normalizing.

We also have had a few topics over which the repository had been brigaded, especially in the vicinity of ordinals, inscriptions, and null data outputs. The repository is our workplace. When people brigade the repository, it adds a lot of noise and distraction to our workday. I’m happy that we have moderators this time around.

As you know, we work in public with all of our code contributions, reviews, and most of our conversations being publicly visible. I think we have overall remained open to constructive disagreement and engage with opinion-based discussions in other venues like the mailing list, delving, and social media, but I will admit that we have become less tolerant to nonconstructive and unwanted contributions in our repository. If you see a concrete case of moderation being used to squash minority opinions (rather than just make less visible noisy comments that don’t add new information), please feel free to reach out to share your concern.

1442 sats \ 1 reply \ @optimism 16h

Thank you for replying.

We also have had a few topics over which the repository had been brigaded, especially in the vicinity of ordinals, inscriptions, and null data outputs.

Yes. It's kind of cringe when brigading happens. The emojis on comments are cringe too - also in Peter's PR mentioned here - but imagine each emoji being a message: that would be truly obstructive, especially since GitHub's issue comment system is horrible for large discussions. It can always be worse!

However, remember that "we" are working on the software that is considered the leading implementation for a protocol that literally enables the 7th largest asset by marketcap in the world. There will be brigades. There will be fights. There will be drama. Because people can be angry, are seeing threats to the idea they just had, or generally - and this is an observable trend since the global 2020 trauma we've all lived through - do not feel a responsibility to be polite.

The repository is our workplace.

Is it "yours" though? I think this is the crux of the issue and the reason why I refer to this as a people excellence vs product excellence kind of thing.

When discussions were moving away from the mailing list to delving, that was sort of a flag to me but at the same time understandable and acceptable, especially if the mailing list would still be used for detailed proposals after they've been worked out in a more controlled and still public setting. The latter doesn't happen really because most of the time proposals are presented as a (symbolic?) announcement, but okay, we still have the repository. There will be a chance to reply to things; flag up concerns on a platform that has many eyes.

However, the privilege of writing a comment on a pull request seems to be taken away from some people now; to my knowledge this happened twice or thrice this month on higher profile people, including a former maintainer? I don't always (and in a few cases, I absolutely don't, depends on the content) agree with the people that are now silenced, but is this truly the noise that needs to be filtered for the greater good of Bitcoin? Or is this for the greater good of the maintainers? This is my concern.

The reason why I have never contributed to Bitcoin Core code was because back when I was interested (and a decade+ more eager), Gavin was captaining a super tight regime and it was really hard to be heard at all if you weren't part of the in-crowd, or at least that's how I, and some others like me, experienced that. There's plenty of documentation of that sentiment around the web - some people actually became shitcoiners because of the extreme gatekeeping.

However, post "war", it felt as if Bitcoin Core became one of the (if not the) most thoroughly reviewed software in the world. We've seen people rise through the review club to become maintainers. People from outside coming in and doing spectacular work - and often sticking around too.

I'd beg everyone involved to harden their skin in times of controversy, not engage in ad-hominem, but also not fight fire with fire in that regard: silencing people, especially former colleagues that didn't leave but were removed, carries across a bad vibe to the public. Perhaps, in an effort to find a middle ground, the moderation rules can be made much more explicit and reduced in scope?

300 sats \ 0 replies \ @Murch 14h

Is it "yours" though? I think this is the crux of the issue and the reason why I refer to this as a people excellence vs product excellence kind of thing.

Yes, the repository is, quite literally, our workplace. We encourage other people to also make it their workplace. We are happy for people to follow along or constructively contribute, but people that don’t work there are guests. We expect some minimum decorum from our guests. We handle disagreement well, and disagree among each other often enough, but someone standing in your office repeatedly shouting crackerbarrel talking points at you without making an effort to understand their discussion partners’ view points doesn’t cut it.

However, the privilege of writing a comment on a pull request seems to be taken away from some people now; to my knowledge this happened twice or thrice this month on higher profile people, including a former maintainer?

I’m not sure who you mean when referring to a former maintainer. I’m aware of ariard getting banned recently, and BitcoinMechanic being banned for a day to cool off. I support the former moderation action and the latter seems perhaps a tad heavyhanded, but 24h pass quickly.

[…]is this truly the noise that needs to be filtered for the greater good of Bitcoin? Or is this for the greater good of the maintainers?

I don’t think anyone is making claims about the moderation being for the benefit of Bitcoin, IMHO the moderation is for the benefit of all participants in that pull request. Collapsing repetitive and vacuous comments improves the signal ratio of the discussion and makes it easier for people to catch up to the content of the discussion.

I'd beg everyone involved to harden their skin in times of controversy, not engage in ad-hominem, but also not fight fire with fire in that regard: silencing people, especially former colleagues that didn't leave but were removed, carries across a bad vibe to the public. Perhaps, in an effort to find a middle ground, the moderation rules can be made much more explicit and reduced in scope?

IMHO, Bitcoin Core contributors generally have tough skin, and most don’t seem to have trouble sticking to "criticizing ideas instead of people". Working in public can be rough and frequently being wrong in public is humbling. That doesn’t mean that we need to subject ourselves to gratuitous abuse, or that it should be required for us to read dozens of crackerbarrel quality comments on every controversial topic to keep abreast of discussions.

0 sats \ 0 replies \ @itsrealfake 7h

our repository.

It's microsoft's

0 sats \ 0 replies \ @unschooled OP 17h

noise and distraction to our workday.

Isn't this one of the expected consequences of working on a project that is of such vital importance to the public? Who gets to define what is "noise," anyway?

I am not a software engineer, but my job also has "noise and distraction."

0 sats \ 1 reply \ @unschooled OP 23h

"Collapsed" - That's a nice euphemism.

you just need to click it to expand it to read it.

--Why is it so?

0 sats \ 0 replies \ @Murch 18h

Sorry, I was out of date, apparently BitcoinMechanic did later also get banned for one day. It was collapsed because it was not about the code review for the pull request.

1509 sats \ 4 replies \ @optimism 29 Apr

To my understanding, it is this opcode that allows for ordinals.

Incorrect. OP_RETURN is not usable for ordinals because the outputs are unspendable. So you cant transfer that rare numbered sat because it will error out when you try. What this allows is inscription of data other than transactional data, without needing the script interpreter (it basically errors out on the first byte of the script, which is OP_RETURN itself)

The important thing is that you can, after hashing, completely discard the UTXO because its not spendable. And thus it doesn't pollute Bitcoin Core's (and forks like knots and libre) utxo db. From memory I do think that libbitcoin indexes them but even if, would be easy to prune them if you don't need them.

The current limit was imposed because it was deemed enough for counterparty back in the day. The reason to expand it (or drop the limit) is because Citrea threatens to circumvent it and fill up the utxo db with fake keys.

133 sats \ 3 replies \ @unschooled OP 29 Apr

So I'd wrongly assumed... Thanks for correcting me on that score. I guess I'm still just trying to make out what this script is used for. At any rate, this is a great learning opportunity, as I find the controversy makes it hard to look away.

99 sats \ 2 replies \ @optimism 29 Apr

It's literally used to tag transactions with data. It's still bloat. But it's pruneable.

The biggest risk besides the bloat is the same as with ordinal inscriptions though, what @theariard underlined: "value" that is not native to the L1. However, its debatable if that is prevented with 80 bytes - counterparty still operates on 80b today and your rare pepe transaction with exactly that externally perceived value "fits" in there.

People will abuse it. It will hurt. Will that hurt more than abuse of data structures in practice? Probably not, because ordinals already does this anyway.

0 sats \ 1 reply \ @unschooled OP 17h

Jason Hughes is saying on X that merging this turns bitcoin into a shitcoin 👀

0 sats \ 0 replies \ @nitter 17h bot

https://xcancel.com/wk057/status/1917235710781690171

55 sats \ 5 replies \ @Modus 19h

What is "bypassing the public network"?

0 sats \ 0 replies \ @Murch 18h

I think that his "bypassing the public network" refers to users "submitting valid but non-standard transactions directly to miners that accept them".

0 sats \ 3 replies \ @unschooled OP 19h

Also, I'm not sure what Wuille means by this. I basically read it as, to exploit a more damaging workaround than the low-filter limits.

I feel like Luke's opposition is getting strawmanned; from his discussions it would seem he wants to fix the bugs with the current filters.

I'll admit, however, I haven't fully groked the purpose and effect that removing the filters would have.

More interesting to me is seeing how these talks are playing out, where voices that are being charged with wanting to "censor" network transactions are simultaneously being throttled (or "collapsed" cf #966183).

0 sats \ 2 replies \ @Murch 12h

Could you explain a bit further how Luke is being strawmanned? I would like to better understand that point.

0 sats \ 0 replies \ @unschooled OP 25m

Respectfully, perhaps you can point me to a relevant discussion and/or spell out the harm of leaving the op_return restrictions and addressing the "bug" instead?

Is there a grand plan for addressing non-financial transaction data being stored on people's nodes, or is it simply a, 'wait until they get priced out?' strategy Core is following?

0 sats \ 0 replies \ @unschooled OP 11h

Sure, I can try to explain what I meant.

To start, I would never claim to have very much credibility on topics relating to core development (as the naive title and nature of my post might indicate), but only to speak in generalities. I'm glad to admit I'm curious and trying to learn.

I think that the general sentiment is that his projects are overly-idealistic. Attacks against him accuse him of 'burying his head in the sand,' and that he and his camp would cut off their nose to spite their face--to use your expression. This doesn't really get to the crux of the issues he is raising. I generally like when figures like Dash who present a counter-narrative to conventional wisdom.

Wuille engaged with his points in the thread, which I'm confident you have read by now, at a level I can't really claim to rebut. No doubt, and this goes without saying, he gave intelligent response to Dash's 'whitlist approach'.

My left-of-the-curve take is this. By removing standardness restrictions, core-devs are taking a taoist, be like water, sort of approach; these restrictions are largely ignored since there exist cheaper alternatives for such "nonstandard" or "spam" transactions. But the initial charge against restrictions is that they "encourage" harmful practices (i.e. for non-financial transactions to find alternative rails to the miners directly). Myself, and perhaps Dash would sympathize, I question the semantics of saying this encourages undesirable transaction outputs being included.

If the financial incentive is there for these actors to find rails that bypass the network, is a feature that was intended to curb this behaviour actually "encouraging" it? Does removing them not feel unlike throwing the baby out with the bathwater?

149 sats \ 1 reply \ @Artilektt 29 Apr

I don't know where I stand quite yet either but it's ridiculous that Mechanic got banned for "abuse" for pointing out Lopp's undisclosed conflict of interest. Have the debate, don't start banning people from the discussion.

5 sats \ 0 replies \ @unschooled OP 29 Apr

I'll be honest I haven't followed too closely the github thread, but I also find that equally....worrisome.

10 sats \ 1 reply \ @eduardopro 29 Apr

The solution: Bitcoin Knots --> https://bitcoinknots.org/

100 sats \ 0 replies \ @unschooled OP 15h

Guides for switching to Knots here of anyone is interested:

#488960

0 sats \ 0 replies \ @BITC0IN 21h

The reddit thread on this topic where nullc weighs in: https://www.reddit.com/r/Bitcoin/comments/1kab15o/bitcoin_cores_github_mods_have_been_banning_users/

0 sats \ 0 replies \ @nitter 28 Apr bot

https://xcancel.com/GrassFedBitcoin/status/1916907944551321608

A summary of their positions

Footnotes