Subject: Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions

From: Greg Maxwell <[email-masked]>
Date: Fri, 2 May 2025 10:36:44 -0700 (PDT)

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. 

Not so, deploy the restriction to mining behavior first.  The fact that it 
classically hasn't been separately configurable is an artifact of assuming 
that it's the same (and acknowledging that it needs to be!).

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.  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.

Consider High-S signatures.  There were active attacks this blocked, and 
yet it was still important to the discussion that third parties could run 
code to automatically convert users High-S signatures to low-S, and then 
people *did* run nodes that did precisely that for a long time.

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.

And it will be critical for any proposal that violates the general 
principle to explain why it's reasonable to do so.  I mean they should 
already, because I think it's a good criteria an it's still a good one even 
if no project has said outright that they intend to follow it! :)  So for 
example, if it's violated as part of a credible transition to a new state 
where the behavior is again consistent then fine.

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. 

Alternatively, if it's a rule with exceptions, then it's those exceptions 
that are the important factor and should be figured out. 

Exactly.

For example, the reason mining a "quadratic hashing bloat txn" is bad 
because it causes delayed block validation on its own, potentially in 
ways that aren't even sufficiently mitigated by running your node on 
extremely high end hardware. Transactions like that should really be 
removed from consensus validity not just prevented at the relay level, 
and BIP 54's consensus cleanup hopefully does that. 

Indeed.  When I considered this idea the examples I could come up where 
you'd really want to violated it were mostly ones where the consensus rule 
really needed to be fixed.

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.

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. 

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.  The choice you have at that point is to allow their 
non-standard transactions to have collateral harm or not.

Forward compatibility is fragile like that.  In a world where miners were 
behaving adversarial to the network in such a manner additions to consensus 
rules would just cause short lived consensus forks w/ associated disruption.

One could, of course, adopt a revised form of my statement that exempts 
forward compatibility.   I kinda feel like this is missing the point a bit, 
but OTOH, one could switch to allowing them once it was clear that 
filtering them wasn't providing any value anymore.

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 think 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!

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.

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. 

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.
... and for most of them making them consensus rules has been considered 
and rejected.

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.

* 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".

* 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

Yes, that's what the capacity limit is for.

 (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.

* one is that for that to only be "occassional" means that even 
vaguely legitimate use cases should have a supported way of 
being exercised via standard transactions without being much more 
expensive: eg, instead of consolidating 4000 transactions in a 
270kvB transaction, you might use consolidate 1333 transactions 
in each of three 91kvB transactions. That limits the amount of 
excess profits the miner can generate, in this example the 3kvB 
of savings would only justify paying about 1.1% higher than the 
going feerate for standard transactions, eg. 

* the other is that if you want to disallow this from happening 
even occassionally, then you want to have relay and consensus rules 
be the same; but that effectively means that any functionality 
upgrade needs to be done as a hard fork, which in turn likely has 
highly centralising effects around the developer team, as running 
old versions of the software becomes infeasible 

Right, my view is that one-offs aren't an issue. Relay policy can differ 
from mining policy for one-offs.  If that weren't my view then I would say 
that there should be no relay policy at all, anything consensus valid 
should relay.

And you hit on basically the primary example of why relay policy exists-- 
because some rules would be overly restrictive as consensus rules.

I don't agree with that at all: giving people what they ask for, even 
if it's literally a punch in the face, isn't disrespectful, it's the 
opposite. (Respecting other people isn't always the highest virtue, 
of course) 

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!)
 
But your point is received.

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!

-- 
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 [email-masked].
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0b6ac4cf-1f58-42b4-823a-8b35fad9f17fn%40googlegroups.com.