pull down to refresh

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."1
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.2
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.

Footnotes

  1. Written with the help of MapleAI
  2. Some @BitcoinMechanic 's comments on the Bitcoin Core Github resulted in him being banned
Correction the comment marked as abuse was not Mechanic's, but 1ma's.
reply
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.
reply
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.
reply
600 sats \ 9 replies \ @Murch 29 Apr
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.
reply
1442 sats \ 5 replies \ @optimism 29 Apr
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?
reply
300 sats \ 4 replies \ @Murch 29 Apr
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.
reply
486 sats \ 3 replies \ @optimism 5h
Alright. I don't really disagree with conflict arbitrage by rules and timeouts in principle. It's a tool.
However I can't help but feel that the spirit of CONTRIBUTING.md and the spirit of what you're saying above
Yes, the repository is, quite literally, our workplace
are a bit different. Specifically this:
First, in terms of structure, there is no particular concept of "Bitcoin Core developers" in the sense of privileged people. Open source often naturally revolves around a meritocracy where contributors earn trust from the developer community over time. Nevertheless, some hierarchy is necessary for practical purposes. As such, there are repository maintainers who are responsible for merging pull requests, the [release cycle](/doc/release-process.md), and moderation.
The way I read it is: it's everyone's workplace that wishes to contribute (after all it's the integration tree?) but for practical reasons, not to protect the workplace of maintainers, maintainers/moderators are needed.
That means that this sounds more like a narrative issue, and maybe a little of a philosophical issue. But, since this narrative is literally the basis to temp ban people from the entire org, meaning both bitcoin/bips AND bitcoin/bitcoin, perhaps it's an idea to think this through a bit more and fix the narrative (and I'd beg y'all to reconsider doing incrementally larger bans, especially when the increment is an order of magnitude).
The current narrative will not only upset a bunch of people, I also worry that it will be used against maintainers. I really don't want that to happen (or actually for that sentiment to grow even further, because let's be real: it's already there) because in the end we all benefit from broad support on BIPs and Bitcoin Core: collaboration beats competition and eroding collaboration seems unnecessary - even in the face of adversity.

I’m not sure who you mean when referring to a former maintainer.
Yes, my bad for misformulating, apologies: a former org member.
I support the former moderation action and the latter seems perhaps a tad heavyhanded, but 24h pass quickly.
Alright. I don't really care too much about the who, but very much about the why and the how long. Bans are always subjective, echo chambers don't help either. I think discussion like dariosor's question helps so I was truly happy to see that happening.

IMHO, Bitcoin Core contributors generally have tough skin
Maybe. But look at meta#18 once more, and now read it as your own future ban report instead of that of someone you really dislike. How much of it would you say is precise and fair interpretations in rationale? And how much is a stretch?
I've discussed this with many bitcoiners f2f the past couple of days, because I needed to be sure it wasn't just me overlooking something. Most of the people I asked to read the drama think among the lines of "there's something fishy going on here". Even if that's not true (which is what I personally subscribe to), that's still how it's perceived right now, at least in the circles I move in nowadays. Please, if you can get any validation for that signal from elsewhere, don't ignore it.

Bottom line, I truly don't intend to shoot the messenger here, nor do I want to escalate this towards you personally. Therefore, thanks for hearing me out. I hope that this will be discussed much more and that you will be granted a lot more (hopefully at least a bit constructive) feedback than just my walls of text.
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."
reply
100 sats \ 0 replies \ @Murch 12h
Everyone gets to decide for themselves and our moderators decide for the repository. How about these for a starting point: before posting, read all of the previous comments. If the comment you're in the process of writing only repeats prior points, leave a reaction on the corresponding comments instead. If your comment is about politics or conspiracy theories keep it on social media. If you find yourself attacking people instead of ideas, take a walk before taking another stab at your comment.
reply
our repository.
It's microsoft's
reply
"Collapsed" - That's a nice euphemism.
you just need to click it to expand it to read it.
--Why is it so?
reply
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.
reply
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.
reply
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.
reply
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.
reply
Jason Hughes is saying on X that merging this turns bitcoin into a shitcoin 👀
55 sats \ 8 replies \ @Modus 29 Apr
What is "bypassing the public network"?
reply
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).
reply
Could you explain a bit further how Luke is being strawmanned? I would like to better understand that point.
reply
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?
reply
100 sats \ 0 replies \ @Murch 4h
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.
I guess you could describe it that way. I would say that it’s based on a non-emotional assessment of what’s happening on the network. Since Ordinals, Inscriptions, and Runes have started, these transactions have paid about ~$286M (7,050 ₿) in fees and occupied between 5–40% of blockspace.
One of the tenets of Bitcoin is censorship resistance, and in this case, it works well for the NFT-enthusiasts: about 10% of nodes accepting and forwarding their transactions is sufficient for transactions to ~reliably propagate to miners. Miners have a big financial incentive to include these transactions, miners that do not include them take a paycut and increase the revenue of other miners. (I believe this to be self-evident: taking only a subset of the juicy transactions means that the average fees collected by your blocks being lower, and leaves more high feerate transactions to the next block.) When the Ordinal craze started in early 2023, the reachable node count jumped up by several thousand nodes. This implies that even if Bitcoin Core started releasing node software that filtered Inscription transactions, there would likely be sufficient nodes that forward them, simply by those people not updating their nodes. Beyond that, the business with these pictures is probably in the billions if they already pay hundreds of millions in transaction fees, and that is plenty money to organize a patched client that forwards the transactions. That means that even a majority of nodes filtering these transactions would not make any dent into their likelihood of making it to miners.
The Bitcoin community could try to bring out the big guns and soft-fork the transactions out, but with soft forks generally taking months to years to deploy, and there being many different ways how such data carrying transactions could be created, the NFT enthusiasts would likely be more nimble and simply switch to another script. We could restrict transactions just to a small set of whitelisted output scripts, but data could still be embedded in the hashes used by those output scripts, and losing the ability to have programmable money would be too big of a price. There is an argument here, that forbidding one type of NFTs might be sufficient pushback to make the community feel unwelcome, but I doubt that it would turn out that way, if I look at the resurgence of Stamps when Ordinals were popular and consider that there are three more such protocols since.
So, trying to "filter" these transactions so they don’t get into my node’s mempool, while I still accept them in my blocks doesn’t seem useful to me. I don’t buy that it actually saves bandwidth, because I still have to download the transaction once and will forward it with any blocks I relay. It might actually increase the traffic, because almost all of my peers will still announce the transaction to me. It makes my node a less useful peer and makes it minusculy slower for me to receive blocks because it causes the compact block relay to never succeed fully. On the other hand, I no longer have a complete picture of the mempool, to see what my own transactions should be competing with, I cannot predict the next block accurately anymore. Out of these advantages and disadvantages, it seems at best like a toss-up unless I have some sort of emotional reaction about sticking it to the funny picture people by not having their transaction in my mempool (but still in my blockchain). Anyway, it seems useless to get all wound up about this, especially now that it has mostly run its course. It’s not exactly new anyway, we’ve had multiple waves of colored coins, timestamping schemes, and NFTs on Bitcoin in the past ~13 years that I have been around—they just taper out when the respective set of people learn that blockchains don’t work well for data storage and get tired of paying for it.
Regarding the classification of doing inscriptions as "bugs": characterizing the possibility of doing Inscriptions as a bug seems silly, unless you are advocating to remove all custom scripting, and I have already explained why that doesn’t seem right to me above. On the other hand, the datacarrier configuration option was specifically introduced to regulate the size of OP_RETURN outputs, so suddenly claiming that it should apply to any transaction pattern that might be used to put data in transactions even while the methods’ costs are wildly different is charitably at best a new idea—I am not aware of any other Bitcoin Core contributors that share that interpretation.
So yeah, the whole Ordinals, Inscription, Runes, and whatever stuff is not great, but if there is significant demand for creating those sort of transactions and they already show up in blocks, instead of trying censor part of the bitcoin users and thereby incentivizing them to start running private mempools or building tools for direct submission to the bigger miners, I’d very much prefer relaying their transactions on the open network so that all miners get them into their mempools.
reply
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?
reply
0 sats \ 1 reply \ @Murch 4h
What "bug" are we referring to? AFAIK, Luke is the only Bitcoin Core contributor that thinks that a configuration option that was introduced twelve years ago to allow configuring specifically the OP_RETURN size a node accept in their mempool should obviously refer to any new patterns that are used to insert data in the blockchain, and classifies the appearance of new patterns that are not yet handled by the code as a "bug". I really don’t get how that position got picked up by Bitcoin Twitter so broadly—it’s a comically absurd representation.
reply
I won't try to defend Luke's usage of the term.
Although it may seem "absurd" to you, for reasons you outlined clearly and cogently already (#967847), to the user-level understanding, a "bug" would seem to indicate that there's something that may not be working as intended, which "new patterns" of use generally can reveal to developers is not being handled by the code.
Your reply also illustrates in detail the context and means by which op_return standardness limits may be ineffectual, but I still feel that there's a paucity of explanations (not only from you, but from the clerical caste in general) as to the urgency and rationale for removing a part of Core's implementation that has been there for so long (twelve years, as you said), and, to boot, whose vulnerabilities seem to have already been capitalized upon by the ordinals and nft people.
Maybe I'm being naive, but I'm failing to see a logical defense for removing the limits that goes further than saying, "they aren't doing everything we want them to do." One might think that, given the amount of vehemence with which this pr is being defended, keeping the limits threatens the network in some novel way, but so far I've not been able to see how/why that might be the case.
I understand the work-arounds that are being found, and i concede these are problematic; nevertheless, it is still incumbent on those proposing the changes to at least try to forecast the problems they foresee taking form were the they not implemented. In other words, if the rationale cannot be phrased as, "by removing the limits, we are addressing (a)", and instead is always put, "the limits aren't doing (b), so they're not needed," then you can expect backlash from a community that has so much invested in these decisions. While it might be up to debate what (a) problems need to be addressed, at least then we're having an honest conversation about the motivation. With the latter rhetoric, (b) might be something that everybody agrees is needdd, yet those users who are not intimately up to date on all the gritty details are left wanting as for what the a priori cause for the change actually is.
I appreciate your patience and good-faith discussion, Murch. Please don't misunderstand my remarks as an attack on anyone.
I think that his "bypassing the public network" refers to users "submitting valid but non-standard transactions directly to miners that accept them".
reply
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.
reply
I'll be honest I haven't followed too closely the github thread, but I also find that equally....worrisome.
reply
The solution: Bitcoin Knots --> https://bitcoinknots.org/
reply
Guides for switching to Knots here of anyone is interested:
reply