Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions

[Anthony Towns <aj@erisian.com.au>]

On Fri, May 02, 2025 at 10:36:44AM -0700, Greg Maxwell wrote:
> On Friday, May 2, 2025 at 10:33:18 AM UTC Anthony Towns wrote:
> Hmm, I don't actually think this is a good rule -- if followed strictly,
> it prevents ever making relay rules more restrictive, even for cases
> which are provably harmful for the network.

Err, the text/plain alternative in your email apparently doesn't include
quote markers for the things you're quoting. :( I guess this is some
Google Groups innovation? I'll fix it manually in the other things where
I'm quoting you quoting me below.

I meant to mention this last email, but had forgotten where to find
the link. Personally, I think Greg's "relay extra transactions via weak
blocks" idea [0] from a year ago is an approach that should be considered
here. The TLDR is that if there are miners out there with different
relay policies than your node that are accepting transactions you'll
reject (eg, lower fee, new tx versions, more complicated dependencies,
...) then once they find a relatively high PoW share, have the network
relay that as a weak compact block, with full round-trips to gather
any transactions that weren't in your mempool and add those txs to your
extra pool to help with block reconstruction in the near future.

[0] https://delvingbitcoin.org/t/second-look-at-weak-blocks/805/1

That approach would also help improve block relay where standardness
policies are made less restrictive, for things like pay2anchor, package
rbf, or soft forks, when many nodes haven't upgraded to support the
new feature.

> Though even if were true, it's not clear to me that reductions in
> permissiveness are particularly interesting.  It's not a one way valve, but
> kinda.

I believe the Great Consensus Cleanup invalidates some transactions
that would currently be standard: the 2500 executed sig operations
limit is only claimed to avoid making **non-pathalogical** transactions
non-standard; I believe there are some pathalogical transactions that
would be standard today that will be invalid when/if BIP 54 is enforced
on chain.

> At least historically the community hasn't considered it
> particularly appropriate to restrict already accepted transactions, this
> is affirmed when we look at the counter examples.

I believe PR#1718 (0 value outputs are non-standard), PR#2577 (dust
outputs are non-standard) and PR#5000 (execution of undefined NOP opcodes
is non-standard) are examples of doing that. (There might be others,
I didn't look very hard)

https://github.com/bitcoin/bitcoin/pull/1718
https://github.com/bitcoin/bitcoin/pull/2577
https://github.com/bitcoin/bitcoin/pull/5000

(The high-S vs low-S example you gave is a case where an even better
solution was available; but that isn't always possible, obviously)

> So I would say that reductions in relay permissiveness are uncommon and
> exceptional, and if they happen at all will be on some case by case basis
> and justification and so the general principal need not apply.

I don't think promoting general principles where you need to be a top-tier
expert to figure out the exceptions is very helpful: there are plenty
of non-experts with an interest in bitcoin and who wish to be involved
in protecting bitcoin's functionality as decentralised money, who'll
simply be misled by that sort of principle.

I think it is probably sufficient to phrase the principle backwards:
"relay/standardness rules can be made more restrictive, but there better
be a damn good reason for it".

I think that still gets the right message across, without having to
go through a "you're breaking the rules", "the rules have exceptions",
"that's dumb, they shouldn't", "yes they should", cycle.

> My view is that a principle like this is an objective, not an exact
> edict.   "Here is what we're trying to accomplish".  And that absolutely
> can get overridden by circumstance specific exceptions.

Yeah; I think we should be aware that there's a fair number of otherwise
well intentioned bitcoiners out who'll mistake these things for edicts,
however.

> > Miners have accepted out-of-band relay of spends of unknown
> > segwit versions (which I presume is similar enough to the "unused
> > opcode/successcode/version number or whatever" case), in particular
> > txid b10c007c60e14f9d087e0291d4d0c7869697c6681d979c6639dbd960792b4d41
> > in block 692261 (the taproot exception block). Even though that was not
> > done by mistake or out of technical ignorance, I think doing such things
> > extremely rarely through out of band mechanisms is pretty much fine.
> > (Even if miners do it for profit, rather than as a 0-fee tx where the
> > outputs are a donation to a developer funding group)
> Indeed, I don't think one-offs have any relevance to the idea I'm
> suggesting.

Anything that you can do as a one-off, you can automate and repeat. If
you're going to react in some predictable way as soon as someone sets
up the automation, you might as well do it for the one-offs as well.

> > If adopted, a policy like that would be fairly easy to use to hold the
> > network hostage: find a miner who doesn't much care and has perhaps
> > 0.1% of total hashrate, get them to mine txs spending segwit versions 2
> > through 16, and forward a handful of such transactions to them every day.
> > The transactions are getting mined regularly and reliably (at a rate
> > of about once a week), the transactions aren't immediately damaging the
> > network, the miner is making excess profits, and by your relay argument,
> > the miner is gaining a slight advantage in being able to potentially
> > mine two blocks in a row due to the block relay delays caused by not
> > relaying spends of future segwit versions.

Just to note: if everyone else was in agreement, a 0.1% hashrate miner
would not block a soft fork activation (which usually requires something
like 90%-95% hashrate), and would not cause any meaningful risk of a
chain split even for light clients after activation. So I think under
traditional analysis you wouldn't expect such a miner to be able to
block the introduction of a new segwit version, given everyone else on
the network thinks it's a good idea.

> I don't follow: If someone is doing that then the version numbers are toast
> for forward compatibility use. It doesn't matter what relay does, they're
> already toast.

I don't believe that's true for segwit versions. Any such spends will take
the form of someone sending some funds to an undefined segwit address,
followed by someone spending from that address in an unverified way,
moving whatever funds were there to someone else. Because the spend is
unverified, whoever mines that transaction can steal those funds if they
choose, so will either be doing that and sending the funds to somewhere
they choose (eg the Brink donation address), or will, in general, have
been paid even more in fees (whether in-band or out-of-band) to send
the funds to somewhere specific, purely as theatre.

Adding verification rules on top of such spend attempts doesn't cause any
additional harm -- people wanting to fund miners can already do so more
efficiently by just paying fees, and people wanting to spam the utxo set
if everyone else doesn't comply to their demands can also already do so.

AntPool currently has about 20% hashrate, even ignoring the pools that
mine the same block templates. If its operators want to prevent future
soft forks, do we really want to establish that regularly mining garbage
transactions is a perfectly effective way of doing so?

> The choice you have at that point is to allow their
> non-standard transactions to have collateral harm or not.

If they continue to make such transactions, despite it no longer
transferring value to miners the way it did before, then that probably
serves to spam the utxo set, but if that's their goal, then there are
already plenty of ways to do that. I don't think preventing one particular
way of doing that is worth allowing them to hold upgrade paths hostage
at almost zero cost.

The same argument doesn't necessarily apply to every upgrade method --
segwit versions and OP_SUCCESS are essentially explicit "pay to miner"
in ways other upgrade methods aren't. But I don't think we should be any
more concerned with people losing access to funds they've encumbered via
undefined upgrade methods, any more than we were concerned with people
accepting unconfirmed transactions getting double spent.

> > I'd describe that class of policy as something of a "popularity contest"
> > approach -- it's a policy that says that anything that's sufficiently
> > popular is good/permissable. I think that makes sense as a check/balance
> > approach -- "this thing is popular, is there really a good reason why
> > it's not permitted?" -- but not as the first thing we think about.
>
> Mining *policy* is inherently a popularity contest, particularly for
> restrictions since they don't work unless ~everyone does them.  They will
> always be vulnerable to someone convincing miners to ignore them.  Covering
> our ears and eyes w/ relay policy doesn't change that!

That's a fine attitude if you're willing to just follow the current
fashion, and defer to others as to what that fashion is and how it will
change in the future. Given the complaints and lawsuits that can result
from trying to set a direction from Bitocin, I can certainly understand
the appeal of that attitude.

But there are plenty of people around who will attempt to influence what's
considered acceptable; the people making the complaints and filing the
lawsuits, in particular. More concretely, both Knots and Libre Relay
are putting themselves out there as taste makers and trend setters in
exactly that way, and are both happy to defend their respective views
on the merits.

> When a fragile tool is the best tool we have ... it's still the best tool
> and we should enjoy its benefits when we can.  But when it doesn't work
> anymore we shouldn't delusionally pine for the old days when it did at a
> cost of creating relay/mining inconsistency.
>
> I'm not speaking in favor of popularity contests but rather in favor of
> acknowledging reality.

Again, the distinction I'm making here is on how the judgement is made; whether
it's:

  * "well, this is popular, so we should give up and just accept it", or
  * "huh, this is popular, we should reconsider it on its merits"

If we're settling on the former (with the constraint that we only make
rules less restrictive) then I think we're very quickly going to move
to the "relay rules = consensus rules" approach [1], and from there to
"whoops, we can't make standardness rules more restrictive (because
that would likely be confiscatory), therefore can't make consensus rules
more strict via a soft fork, but we want to do an upgrade, so time for
a hard fork".

[1] eg, as advocated at https://x.com/0x_orkun/status/1918744573251121575

If we're settling on the latter, then the fundamental thing we're judging
our rules on is still their underlying merits, not their popularity,
and that should be the main thing we spend time discussing/evaluating.

> > As a check/balance, I think that argument holds water, and should cause
> > us to ask if your existing policies make sense. I think it's fair to
> > say Bitcoin Core's existing policies (as expressed by its code, and not
> > necessarily matching the policies of various forks of Core) are (in no
> > particular order):
> A number of your examples are consensus rules, not relay policy.  That is
> an entirely different kettle of fish.

At least some of those consensus rules were previously enforced
differently by policy, and could be again. For example the current
4GB/week limit was formerly 1GB/week by consensus, but prior to that was
250MB, 350MB and 750MB by miners sticking with core's default mining
policy.

I don't think core changing the default alone would have any effect there,
but if there were good reasons to reduce that number, then discussing
those reasons with miners, including how they would benefit as a result,
seems to me like it would have a good chance of working out, even without
consensus changes. (At present, I don't think there are good reasons
for such a reduction)

> Consensus rules have force even when some miners or even ~all miners don't
> agree.  So they do not have the problem that they're mooted when some miner
> eschews them.
>
> The ones that aren't could be justified or refuted on their own merits but
> *regardless* of what anyone thinks of them, so long as they're policy they
> are moot if some miners ignore them. And that remains the case unless
> they're turned into consensus rules.

Not every policy needs 100% enforcement to have a meaningful effect. For
example, if 99.9% of miners mine 250kB blocks, and 0.1% of miners mine
4MB blocks, that still limits the block size to 256kB on average.

This might be a rational/incentive-compatible policy for all of those
miners, if fees are a large component of block reward, and the capacity
constraint pushes the average fee paid by transactions up by more than 4x,
and the majority of miners are either taking a long term view themselves
or are in a large pool with signficant constraints on exit.

> There are some like lowS rule in legacy transactions which was always
> intended to become a consensus rule, but just hasn't due to low importance
> while it's not being broken by miners and due to general dysfunction in
> updating consensus rules which has allowed vulnerabilities in the consensus
> protocol to remain for years.

The lowS rule was part of BIP 62 (dealing with malleability) which was
withdrawn around the time segwit was proposed. Part of it was re-proposed
by Matt as part of the Great Consensus Cleanup (push-only scriptSig),
but that wasn't one of them. I wasn't aware there was any particular
interest/need in upgrading lowS to a consensus rule, for instance.

In any event, the "general dysfunction in updating consensus rules"
largely takes the form of "I don't have confidence that we'll be able to
get consensus to agree to this change, which after all, isn't strictly
necessary". That's why the current BIP 54 doesn't include a restriction
on push-only scriptSig, eg -- disabling it isn't strictly necessary to
avoid the DoS attacks that we know about.

But if we aren't able to have the confidence to make standardness rules
more restrictive, I don't see why we should have any expectation of ever
cleaning things up in consensus: if a standardness change is adopted
by the network, it's still possible to get exceptions through in cases
where someone would have lost funds even if it requires paying exhorbitant
fees to a miner to special case your transaction; for a consensus change,
even that's not possible.

> > * encouraging data storage people to use commitments (7) didn't really
> >   work, and given that could be done via documentation or blog posts
> Oh I dunno about that, I've seen first hand quite a few discussions that
> basically went,  "I want magical free file storage!" "It doesn't provide
> that, you can have a commitment to prove your file existed, and that
> doesn't require stuffing the whole file in" "oh but I don't really want a
> commitment, I guess this doesn't do the thing I wanted".

(If you prefer, replace "didn't really work" with "worked for a time,
but that time has passed")

The key argument against using bitcoin for "magical free file storage"
is that it isn't free, or even as cheap as just paying for storage on
S3, not that you have to do ridiculous encoding tricks when your file
size passes various thresholds. In any event, those encoding tricks
have already been standardised and publicised, so I'd expect that the
normal response today to "it doesn't provide that" is "actually it does,
see <url>".

Alternatively, if you believe there's still some potential there, we
could perhaps resurrect ideas like restricting the OP_RETURN pushdata
[2], perhaps to at most 80-bytes (same as now, just allow more of them),
256-bytes (ie, anything that only needs PUSHDATA1), 520-bytes (matching
inscription chunking forced by MAX_SCRIPT_ELEMENT_SIZE), or 4096-bytes
(matching how much data you could stuff contiguously in a taproot control
block via fake merkle leaves).

[2] https://github.com/bitcoin/bitcoin/pull/5286#issuecomment-65671770

> > * people with legitimate concerns about their node being overloaded
> >   should probably be concerned more by the "limit maximum block size
> >   growth to ~4GB/week" policy (6)

> >   or prefering prunable data (2):

> Well there I don't follow, you flip a switch and then operating a full node
> goes from requiring a terabyte to requiring 30GB.  This is quite important
> and absolutely makes a difference in ability to run a node.

That's because you somehow tore up my quote and dropped the "rather
than". In full, I wrote:

> > * people with legitimate concerns about their node being overloaded
> >   should probably be concerned more by the "limit maximum block size
> >   growth to ~4GB/week" policy (4), rather than commitments vs data (7),
> >   complicated scripts (6) or prefering prunable data (2):

that is, "they should be concerned with [the capacity limit], rather
than being concerned with [the witness discount and other things]". So
I don't think we're disagreeing.

> Even if they're asking for a punch in the face because click-baiters on
> youtube convince them it would cure their cancer?  I'd rather tell them no
> thanks, get your punch elsewhere if you're that convinced.  (also, have you
> not punched someone? it hurts!)

I think a lot of people won't be convinced something's stupid until
they've actually tried doing the stupid things themselves, and found it
really doesn't work. For that example, if getting punched in the face now
lets them go get tested to prove/disprove their theory, and, assuming the
punch in the face didn't work, go move on to a real treatment ASAP, then
if it was someone I cared even slightly about, I'd probably be willing
to deal with some hand pain, yes. Hopefully the youtube conspiracy allows
you to wear a boxing glove, though.

> > Even if they're fundamentally wrong, I think it's respectful to people who
> > haven't yet given that up as a lost cause to leave them with a knob that
> > gives them at least a chance to continue the fight for sometime longer.
> But better still to help them be effectual on it!

For me, saying "sorry, this has reached a threshold of popularity, you
have to give up and accept it now" makes me want to oppose it just as a
knee-jerk reaction, even things I otherwise think of as a good idea. I
expect the contrapositive "sorry, your idea isn't popular enough,
you have to give up on it" likewise gets a knee jerk rejection from
many bitcoiners.

For me, arguments of the form "this is actually good for bitcoin because
..." are much more helpful than "sorry, a minority of miners have already
decided this is okay, therefore your opinions just don't matter".

Cheers,
aj

-- 
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/aBiCgRIRikR0MPei%40erisian.com.au.