From: Bob Burnett <bob.burnett@barefootmining•com>
To: PandaCute <pandacute12345678@gmail•com>,
Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
Date: Fri, 2 May 2025 13:58:44 +0000 [thread overview]
Message-ID: <BY5PR03MB5171138582C249F82228689A968D2@BY5PR03MB5171.namprd03.prod.outlook.com> (raw)
In-Reply-To: <68cdce0e-9030-4a6b-92a4-d48d05be3e80n@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 17159 bytes --]
This is my first response/comment on this mailing list. I think there are several issues that have risen to the surface here including this one on a broken communication link (well written message btw).
1. Those outside of the dev community are perplexed by the process and feeling discounted, unheard, and/or rejected. Most of the issues/PRs/BIPs that the dev community deals with are beyond the ability of the general population to understand, but occasionally there are ones that they grasp (at least somewhat) and for which they have opinion. I’ve certainly learned that when someone has an opinion it is really important to let them express it, otherwise, the pressure inside them builds and they erupt like a volcano. The Bitcoin ecosystem and its members are radically different today than 5-10 years ago – it is bigger, wider, and has broader interests now - it appears that process and communication mechanisms currently used by Core are not capable of reaching the community properly anymore. Note that communication means two-way as well.
When someone buys Bitcoin or starts working within the ecosystem, there is no membership guide, owner’s manual, or employee on-boarding process. It comes off very badly when someone trying to engage is told that they don’t count or aren’t using proper channels, especially when they don’t even know where to go learn the rules of engagement. That isn’t necessarily anyone’s fault, but I’ve been involved in Bitcoin since 2017 and even now am still learning new things about the engagement process, and there definitely have been several surprises and frustrations for me over the past handful of days.
1. The ecosystem is much more complex than ever before with people and companies developing products and services with assumptions of how Bitcoin will operate. Many of these are being done in stealth-mode as well. Some people are pouring their heart and soul (and money) into their projects and the expectation of a standard is often crucial. I am one of these folks, beyond what I do in mining (CEO of Barefoot Mining) and as a board member at Ocean, I have been working for two years on a project related to enhancing block space access. This proposed change in standardness may impact my project in a negative manner, and, it is certainly possible others might be in a similar position. Regardless, changes to standardness are HUGE. I spent most of my career within the Personal Computer space and learned the hard way that changes to a standards are a dangerous game. I expand a bit on this in this X post:: https://x.com/boomer_btc/status/1917687830148526095
2. The proposed change also appears to be reduction in flexibility and configurability. In general, this is never a good thing. IMO, we should be going in the direction of giving people more choices and flexibility (although it is fine to make suggestions, set defaults, or provide general guidelines.) How someone configures their node and creates their mempool is akin to free speech within Bitcoin. The same goes for those like me that are miners and create our own block templates – this is also part of our free speech (and our business). In the end though, whether you are a user or a miner, the more choices you have, the more freedom of speech you have.
Side note: Ultimately, as a miner I am in the business of creating block space – at least that is my view, and contrary to popular belief, miners are not always motivated to simply pick transactions that generate the highest block reward in the immediate block, and as time goes by this will become even more common and apparent. I’ve spoken a lot on this recently in public forums, so I won’t dwell on it here.
1. Finally, there is the issue of an OP_RETURN change, if it encourages more spam, and if we are just caving into an inevitability. I am against the proposed change and, even if that is true that the spam will ultimately find a way, I feel we are acquiescing way too early. Enough has been said on this topic in other forums so I won’t go further.
From: bitcoindev@googlegroups.com <bitcoindev@googlegroups.com> on behalf of PandaCute <pandacute12345678@gmail•com>
Date: Friday, May 2, 2025 at 7:11 AM
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
You don't often get email from pandacute12345678@gmail•com. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
I think this debate is missing one important part: a communication link between the developers and the users. The developers are speaking with the developers, the users are speaking with the users, and no one is really trying to understand where the other side is coming from. It's been a lot of aggressive, unproductive back-and-forth, with both sides accusing each other of bad intentions and completely dismissing each other's points.
This is a technical mailing list aimed at devs, so I'll try to summarize what I've seen in normal_users_land, and the general feeling out there right now. Obviously, I'm not trying to suggest that users *feelings* should be dictate the technical direction of Bitcoin. However, it is important that there is mutual respect and trust between users and devs.
Right now, trust is pretty broken. It can be regained, but not without understanding what went wrong in the first place.
I saw on IRC some devs suggesting they spend time on podcasts and social media to explain the motivations behind this proposal *before* merging it, instead of merging now and hoping people just accept it. I think that’s a fantastic idea, and the way to go. I particularly liked jonatack's message - “if Core shows humility and patience, it would surprise people and improve things.”
Now, about the proposal itself and what it *feels* like: It’s a big change that came out of nowhere, especially at a time when spam doesn’t seem like a big issue. It’s a bit… shocking? Normally Bitcoin changes are discussed for ages, PRs take so long to get merged, because of all the care that devs put into considering the pros and the cons, but here? We get a mailing list post (that no user is reading, let’s be honest) and a PR with a lot of contributors saying “yeah, let’s do this!”. There should be a bit more research. (Maybe there was, but behind closed doors?). We want to know about all the protocols that are bloating the UTXO set and that could be using OP_RETURN instead. We want to know how many transactions like these are in each block, and how many there will be once the new protocols start getting deployed. We want to see that you did your homework for weeks before trying to change the policies.
It feels weird—like some sort of attack or a bribe. One protocol is mentioned that would benefit from this change, and then an investor ACKs the PR. Someone points out a potential conflict of interest, and their comment gets hidden. That’s shady, no denying it.
And then, it feels that users have no say. It's a ""technocracy"", where devs have all the power in their hands and can decide where the protocol goes, while completely dismissing users' concerns.
Users do have concerns—lots of them. And I encourage devs to step out and talk to "regular" Bitcoin users. It’s not just a “loud minority”—there are many people genuinely worried: “Can we trust Core devs anymore? Is there even another option?”. But their concerns are dismissed, their comments deleted or hidden, they're treated like "bullies" that devs should ignore, devs should "merge Todd's PR and call it a day".
Without understanding all the technical details, I'd say there's a pretty good chance that the very smart people that work on Core are right once again. Statistically, it's very likely. Communicate to users, explain your motivations, and show that you want to listen to our concerns.
Lastly, as irritating as that might be, users freaking out and holding core developers accountable and flooding Github is a feature, not a bug. Devs aren't the Bitcoin gods, they are humans, and humans can be bribed, can be coerced, can have conflict of interest, can fck up.
Users care and want to protect Bitcoin. Be grateful.
Respectfully,
A Bitcoin Dev
On Friday, May 2, 2025 at 12:46:20 AM UTC+2 Antoine Poinsot wrote:
As i have repeatedly asked people to take conceptual discussions to the mailing list, i am circling back to this thread to answer objections. I have also written my point of view and reasons for proposing this change in a blog post which goes into more details: https://antoinep.com/posts/relay_policy_drama.
Going through the emails in order.
Am I the only one left on this list who actually cares about Bitcoin's survival?
Thanks Luke for your measured take. It's refreshing to see we have adults on both sides of this "debate".
With that history in mind, removing limits on OP_RETURN standardness size is pointless.
Yes, it is pointless for people who want to store massive amount of data. It is not for people who want to store a small amount of data in a time-sensitive transaction's output. Because they need their transaction to be relayed on the p2p network, and are therefore pushed to use unspendable outputs instead.
Relaxing OP_RETURN size limits without dealing with the inscriptions
This is orthogonal. The harmful behaviour described in OP is possible today regardless of inscriptions.
There's little to no incentive to use OP_RETURN for data storage when using the 'inscriptions' exploit costs 4x less in transactions. What's the point of having a "standard" way to store arbitrary data if the exploit method is 4x cheaper? And the nonstandard version of the exploit allows 4x the data?
You have obviously not properly read or understood OP. There is no need to speculate about what would happen or not. People are using outputs to store data today. The only question now is harm reduction: given that people are storing this data in outputs today, do we want to offer a way to do it that does not force every single full node on the network to store their data forever?
That said i agree that this is not going to change anything for people who try to store large amount of data onchain, they already have a 4x cheaper way of doing so.
For example, let's say I want to distribute malware. Well, might as well just store it in an OP_RETURN.
The point about storing data on everyone's disk was addressed by others: it's already possible and that's why Core XOR's the content of third-party-controlled data it writes to disk. But an interesting fact on this specific point about malware and OP_RETURN outputs is how they have already been used in the past to resiliently update the domain of a malware's C2 servers: https://news.sophos.com/wp-content/uploads/2020/06/glupteba_final-1.pdf .
This is a fundamental change to the nature of what the Bitcoin network itself is in its entirety. [...] Bitcoin as we know it changes forever in the most fundamental way imaginable
Wild emotional claims with no ground whatsoever don't convince anybody and only hurt your credibility.
and we might as well give up on Bitcoin ever being a thing if this is the path chosen
Well if you believe the whole system is as brittle as relying on people playing nice for security, you might as well give up now.
Have the courage to reject this type of thing for the sake of the overall project.
Right. We do that, and you go outside and touch some grass for the benefit of all subscribers to this mailing list.
If you don't have confidence in the Bitcoin Core developers, instead of insulting them, you could also just (help) maintain a fork of the project. I obviously think you're misguided here, but at least it's better to channel this distrust into something constructive. Given the number of people who share your sentiment, such a project should be perfectly viable.
Doubt.
It was suggested in two different PRs ([0] and [1]) that the conceptual discussion take place in this thread, so I am submitting my comments here.
Thank you for taking conceptual discussion to the mailing list. AJ already addressed your claims, so i won't repeat it here.
This is just a temporary cease-fire while the spammers reload their ammunition. There is obviously about to be another wave
Between this one and your previous email, you certainly do know a lot about the future! How's your trading going?
otherwise what is the point of eliminating OP_RETURN restrictions?
To not force people to bloat the UTxO set to store a trivial amount of data in the output of a time-sensitive transactions. On the specifics, Citrea stores a zk-proof verifying Bitcoin's longest chain composed of a 128-byte Groth16 proof and 16-byte total accumulated work (sauce: https://x.com/ekrembal_/status/1918008476552356202). I don't know and don't care why they do it in this way in particular, i just wish they did so in pruneable OP_RETURN outputs instead of unspendable Taproot outputs as they do today. Or worse, start thinking about bare multisig.
Yes, and then the money printer makes sure that there is always enough easy money sloshing around in the economy so that more pop up where the old ones dropped out. This can and will continue indefinitely if we do nothing.
Money printer financing working people forever certainly isn't something i expected to read on the Bitcoin dev mailing list!
My proposal is not to counter literally every type of spam. Just the ones that have protocols relying on consistent transaction formats. Creating specific filters against just these worst offenders should
This is veering off-topic for this thread. If you want to argue that Core should filter inscriptions could you take it to the appropriate thread? This thread is just about damage control for people storing data in transaction outputs.
I believe you greatly overestimate the skill and competence of the people who would do this type of thing. You could accomplish what you've laid out. I could accomplish it.
Your hubris gives me second-hand embarrassment. I hope the C2 domain update i shared above gives you a clue that there does in fact exist other smart people in the world. Threat actors would laugh pretty hard at your arrogant emails and emotional breakdowns, but they probably don't care about your filters in the slightest anyways.
After reading the whole thread i have yet to read a single sound objection to lifting the OP_RETURN restrictions.
On Thursday, April 17th, 2025 at 2:52 PM, Antoine Poinsot <daro...@protonmail•com> wrote:
Hi,
Standardness rules exist for 3 mains reasons: mitigate DoS vectors, provide upgrade hooks, or as a nudge to deter some usages.
Bitcoin Core will by default only relay and mine transactions with at most a single OP_RETURN output, with a scriptPubKey no larger than 83 bytes. This standardness rule falls into the third category: it aims to mildly deter data storage while still allowing a less harmful alternative than using non-provably-unspendable outputs.
Developers are now designing constructions that work around these limitations. An example is Clementine, the recently-announced Citrea bridge, which uses unspendable Taproot outputs to store data in its "WatchtowerChallenge" transaction due to the standardness restrictions on the size of OP_RETURNs[^0]. Meanwhile, we have witnessed in recent years that the nudge is ineffective to deter storing data onchain.
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. 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, and to then proceed to lift the restriction on the number of OP_RETURN outputs per transactions.
Antoine Poinsot
[^0]: See section 6.1 of their whitepaper here https://citrea.xyz/clementine_whitepaper.pdf
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com<mailto:bitcoindev+unsubscribe@googlegroups•com>.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/68cdce0e-9030-4a6b-92a4-d48d05be3e80n%40googlegroups.com<https://groups.google.com/d/msgid/bitcoindev/68cdce0e-9030-4a6b-92a4-d48d05be3e80n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/BY5PR03MB5171138582C249F82228689A968D2%40BY5PR03MB5171.namprd03.prod.outlook.com.
[-- Attachment #2: Type: text/html, Size: 41936 bytes --]
next prev parent reply other threads:[~2025-05-02 15:28 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 18:52 [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 12:03 ` Sjors Provoost
2025-04-18 12:54 ` Greg Sanders
2025-04-18 13:06 ` Vojtěch Strnad
2025-04-18 13:29 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-18 21:34 ` Antoine Riard
2025-04-20 8:43 ` Peter Todd
2025-04-26 9:50 ` Luke Dashjr
2025-04-26 10:53 ` Sjors Provoost
2025-04-26 11:35 ` Luke Dashjr
2025-04-26 11:45 ` Sjors Provoost
2025-04-26 12:48 ` Pieter Wuille
2025-04-28 16:20 ` Jason Hughes (wk057)
2025-04-29 14:51 ` Sjors Provoost
2025-04-30 15:37 ` Nagaev Boris
2025-04-30 16:30 ` Sjors Provoost
2025-04-29 19:20 ` Martin Habovštiak
2025-04-30 0:10 ` Jason Hughes
2025-05-01 17:40 ` Andrew Toth
2025-04-30 5:39 ` Chris Guida
2025-04-30 16:37 ` Anthony Towns
2025-05-01 4:57 ` Chris Guida
2025-05-01 19:33 ` Nagaev Boris
2025-05-02 6:34 ` Anthony Towns
2025-05-02 18:29 ` Peter Todd
2025-05-01 3:01 ` Anthony Towns
2025-05-01 22:40 ` [bitcoindev] " 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-05-02 0:14 ` PandaCute
2025-05-02 11:16 ` [bitcoindev] " Sjors Provoost
2025-05-02 14:37 ` 'nsvrn' via Bitcoin Development Mailing List
2025-05-02 16:43 ` Greg Maxwell
2025-05-02 13:58 ` Bob Burnett [this message]
2025-05-02 20:03 ` [bitcoindev] Removing OP_Return restrictions: Devil's Advocate Position Peter Todd
2025-05-02 22:58 ` [bitcoindev] " Greg Maxwell
2025-05-03 2:02 ` Martin Habovštiak
2025-05-02 6:29 ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Greg Maxwell
2025-05-02 9:51 ` Anthony Towns
2025-05-02 17:36 ` Greg Maxwell
2025-05-02 20:43 ` Peter Todd
2025-05-02 19:04 ` /dev /fd0
2025-05-02 20:10 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BY5PR03MB5171138582C249F82228689A968D2@BY5PR03MB5171.namprd03.prod.outlook.com \
--to=bob.burnett@barefootmining$(echo .)com \
--cc=bitcoindev@googlegroups.com \
--cc=pandacute12345678@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox