From: Greg Maxwell <gmaxwell@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
Date: Thu, 1 May 2025 23:29:35 -0700 (PDT) [thread overview]
Message-ID: <9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com> (raw)
In-Reply-To: <rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 5897 bytes --]
On Thursday, April 17, 2025 at 7:09:23 PM UTC Antoine Poinsot wrote:
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.
The situation is even somewhat worse than that: There are a number of
design decisions where it's generally assumed that relay and mining policy
generally match, or at least that mismatches are short lived.
When relay policy is more restrictive than what is actually being mined
there are at least two serious negative effects.
The first is that the latency of block propagation is greatly harmed, a
single missed transaction causes a tripling of the per hop transmission
delay. If the missed transaction(s) are larger than the TCP window then
the increase may be many round trip times. Also if the missed data is
large the currently unused prefill mechanism in compact blocks wouldn't
help (and would instead likely make things worse as then nodes will get
several times the same transaction data from different peers and you cannot
decode the compact block until all the prefill data has been received due
to the message checksum. Delays in block propagation can have a
disproportionate effect on mining centralization because they cause larger
miners to have improved profitability over smaller ones. This happens
regardless of which party was on which side of the delay, no matter which
side is delayed its the smaller miner's expected profits that are
diminisned and the nature of mining competition means that less profitable
miners go bankrupt.
This also encourages the establishment of direct miner submission which can
undermine the permissionless nature of bitcoin and in particular again
shifts profits towards larger miners because e.g. few would bother
connecting to a 1% miner's direct submission interface (if they could even
afford to make one).
There are also a number of less significant harms, e.g. more restrictive
relay policy makes fee estimation less accurate/complete (though at least
estimation is designed to be fairly robust in that direction).
So on this basis I suggest a principle for these sorts of policy: Relay
rules should admit all transactions which are reliably being mined.
I think node software should adopt this principal as a general rule.
Admitting the transactions is not endorsing them, it's just a recognition
of reality. This policy or equivalent is also the requirement to not
suffer from the downsides of relay being more restrictive than mining. If
we imagine that a miner is mining some kind of harmful attack transaction
e.g. a validation DOS attack, then the miner needs to be convinced to stop,
the implementation changed to not have bad performance, and/or consensus
rules must be changed ... but relay policy can't address it.
By general rule I mean that should something like a miner begin mining e.g.
quadratic hashing bloat legacy txn, or using unused
opcode/successcode/version number or whatever by mistake or technical
ignorance there is no need to rush off enabling their relay. A general rule
isn't a suicide pact. But if it were the case that transactions misusing a
particular forward compatibility feature were reliably getting mined then
that feature would just no longer be useful for forward compatibility
regardless of what relay policy says about it and it would be better to
relay them than have the downsides of not doing so.
As Antoine Poinsot points out, the existent rule is entirely ineffectual:
Parties current bypass these rules with other transaction forms (such as
very harmful address stuffing which is impossible to block) or by direct
miner submission, which will continue considering the millions of dollars
miners have received mining transactions with violate the relay rules.
Because of this it will not become effectual with time or tweaking. It is
a dead parrot^policy. This is no surprise, since it's a product of
Bitcoin's anti-censorship properties that *generally* filtering will not
work except on the fringes. As such there isn't practical upside to
keeping filtering beyond what miners currently perform.
Some Bitcoiners are of the opinion that they still want a knob, I think
doing so is a disrespectful placebo[*] but I don't have a strong opinion if
an option remains-- the code is safer and cleaner without some filtering
rules that few users would use but that really just a question between
software maintainers and users. That said, Bitcoin core has generally not
had knobs to adjust relay policy as distinct from mining policy in large
part because of the design assumption that the two need to be the same.
But in this case if there were a knob here I think would make more sense
for it to control mining policy rather than relay policy, since it would
actually have some effect in the mining context (in excluding the txn from
your own blocks) while as a relay only thing it is impotent.
[*] It doesn't even conserve their resources meaningfully. They'll still
receive and process the txn, then discard. Then they likely have to fetch
it a second time when it shows up in a block. Although they may save
re-transmitting it, on average network wide each transaction is sent once
and received once so the extra transmission for the block should offset the
relay savings.
--
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/9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6750 bytes --]
next prev parent reply other threads:[~2025-05-02 6:47 UTC|newest]
Thread overview: 35+ 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-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 6:29 ` Greg Maxwell [this message]
2025-05-02 9:51 ` Anthony Towns
2025-05-02 17:36 ` Greg Maxwell
2025-05-02 19:04 ` /dev /fd0
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=9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@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