From: Greg Maxwell <gmaxwell@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
Date: Fri, 2 May 2025 10:36:44 -0700 (PDT) [thread overview]
Message-ID: <0b6ac4cf-1f58-42b4-823a-8b35fad9f17fn@googlegroups.com> (raw)
In-Reply-To: <aBSVn7nJnrheLy5Z@erisian.com.au>
[-- Attachment #1.1: Type: text/plain, Size: 10784 bytes --]
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 bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/0b6ac4cf-1f58-42b4-823a-8b35fad9f17fn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 13894 bytes --]
next prev parent reply other threads:[~2025-05-02 19:11 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 ` [bitcoindev] " Bob Burnett
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 [this message]
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=0b6ac4cf-1f58-42b4-823a-8b35fad9f17fn@googlegroups.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.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