Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions

[Nagaev Boris <bnagaev@gmail.com>]

On Mon, May 5, 2025 at 8:52 AM Greg Maxwell <gmaxwell@gmail.com> wrote:
>
> On Monday, May 5, 2025 at 9:27:24 AM UTC Nagaev Boris wrote:
>
> > There may also be users today who rely on datacarrier
> > behaviour/options without yet realizing they're scheduled for removal.
>
>
> How is it possible that anyone relies on it in a way that it will be a detriment to them?
>
> "I run bitcoind because I want to help centralize the network through incentives to direct miner submission and slower block propagation, and by encouraging utxo bloating 'fake addresses' outputs! I also like diminishing my own ability to anticipate the content of the next block using data on my own node" ? :P   Were that actually someone's opinion I don't think anyone would regret inviting them to run different software.
>
> I've been engaging 1:1 with people concerned about the change on forums for the last few days and I've haven't yet encountered any clear argument as to why someone would be harmed by the change.
>
> Rather, I've found that they've simply been fed an incorrect argument that this change is a product of "bitcoin core" being in favor of non-monetary (ab)uses of the Bitcoin network, and that it will radically increase the amount of it.  As far as I can tell this is a total falsehood both respect to motivations and credible effects, and allegations otherwise just don't survive the sunlight of a competent counterargument.
>

My point is that it's hard to foresee every possible use case. We
don't know how everyone's infrastructure is set up. Some users might
only realize this change affects them after it's already released. And
if they do need to adjust something in their workflow, it's a lot
easier if they can temporarily restore the previous behavior. Right
now, those users aren't speaking up,  because they don't yet know
they'll be affected.

For example, someone might be running a device with very limited
resources that can't afford to store the full mempool, but also can't
disable it entirely. If they're only monitoring certain types of
transactions that never use OP_RETURN, filtering those out is a simple
and practical optimization.

Or consider a system that pulls mempool transactions via RPC from
Bitcoin Core. It might assume certain things about OP_RETURN outputs,
maybe it allocates a static buffer for them, and crashes if one turns
out to be unexpectedly large. Fixing that kind of issue may take time.
Keeping the option available gives operators the flexibility to update
their systems without breaking things in the meantime.

This isn't about defending every edge case as critical. It's just
about recognizing that once an option is removed, anyone who runs into
a problem is stuck. Leaving the setting in place for one more release,
even in a relaxed or discouraged state, gives people a fair chance to
adjust before it disappears.


-- 
Best regards,
Boris Nagaev

-- 
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/CAFC_Vt6WU37OX5_92rWf5e-aesA%2BRa5Smh69d4P33-0YaGu6YQ%40mail.gmail.com.