From: Anthony Towns <aj@erisian•com.au>
To: Greg Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Relax OP_RETURN standardness restrictions
Date: Fri, 2 May 2025 19:51:27 +1000 [thread overview]
Message-ID: <aBSVn7nJnrheLy5Z@erisian.com.au> (raw)
In-Reply-To: <9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com>
On Thu, May 01, 2025 at 11:29:35PM -0700, Greg Maxwell wrote:
(Yay!)
> 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.
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.
> 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.
Alternatively, if it's a rule with exceptions, then it's those exceptions
that are the important factor and should be figured out.
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.
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)
> 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.
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.
The LibreRelay project has already followed pretty much that script for
pushing fullrbf relay onto the network, and is proposing to do the same
approach for data storage in the annex, so I don't think this is just
a hypothetical concern.
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.
> 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.
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):
1 limit utxo growth (via block weight constraints, and by avoiding
creation of utxos that would be uneconomic to spend)
2 prefer that transaction data be prunable rather than potentially
permanent (eg, better to have a 20-32 byte hash in the utxo set and
a 160 byte x-of-5 multisig script in the scriptSig or witness, than
to have the 160 byte x-of-5 multisig directly in the utxo set; this
is the main justification for why witness data should be discounted
vs output data)
3 limit block validation time to the ~1s range (on a block whose txs have
not been seen before, on reasonable hardware)
4 limit maximum block size growth to ~4GB/week (ie, the worst case from
having a 4M weight limit)
5 optimise validation and relay of blocks with txs that we have seen before
as much as possible
6 allow anyone to create any sort of scripts they like (via p2sh, p2wsh, p2tr),
within the limits of what you can conceivably do with script opcodes, and
without causing excessive validation costs
7 encourage people who want to use the blockchain as an anchor for their data
to store commitments in the blockchain rather than the actual data
8 allow miners to occassionally generate excess profits by mining non-standard
transactions that violate relay rules but comply with consensus rules
(There are obviously many other policies, eg the 21M coin limit, but I
think the above are the ones most relevant to this discussion)
I think all of those policies can be justified (or criticised) on their
own merits, independent of their popularity per se, and I think doing
that is a better approach than starting with what's popular or not.
I think there's perhaps four conclusions you could reasonably draw about
the policies above, wrt what's been discussed on this topic:
* encouraging data storage people to use commitments (7) didn't really
work, and given that could be done via documentation or blog posts
where we could provide reasoning, examples and alternatives rather than
just a "transaction rejected" which might be more effective anyway.
the citrea design also suggests that that policy is interfering with
the goal of limiting utxo growth (1). as a result, it probably doesn't
make a lot of sense to maintain that policy in code. There's already
the obvious incentive pushing people towards commitments instead of
raw data, in that doing so reduces the on-chain fees you need to pay.
* for (non-commitment) data storage use cases, OP_RETURN limits are
probably largely irrelevant in limiting blockchain usage; while
OP_RETURN is also prunable, it's not discounted (2), so including
data in the witness will still be preferable to the people who wish
to publish data in large volumes
* 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): it doesn't
really make much difference if your node is overloaded by spam or by
real transactions, either way it's overloaded. I haven't seen any
evidence of it being difficult to keep a node operating for that
reason, however.
* there are two aspects to the "miners generate excess profits from non-standard
transactions":
* 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
> Some Bitcoiners are of the opinion that they still want a knob, I think
> doing so is a disrespectful placebo[*]
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)
> 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.
Core's mempool/standardness policy covers both relay and mining
acceptability. I don't think it makes very much sense to separate them
-- beyond making the code more complex, accepting txs into your mempool
that you'll still relay but won't mine might block you from accepting
other (conflicting) txs that you would mine, eg.
About 11 years ago, you wrote:
] [...] Right now I've seen a lot of people
] promoting data storage as a virtuous use, and gearing up to directly
] store data when a commitment would work.
]
] If it turns out that encouraging people to use hashes is a lost cause
] it can always be further relaxed in the future, going the other way is
] much harder.
-- https://gnusha.org/pi/bitcoindev/CAAS2fgT6qFHBojoB-teCjF_YAd9TePdQ3+NWnO0dwf9Bv583_Q@mail.gmail.com/
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.
Let me offer a principle that will never need any exceptions: people
who are a mere 10-15 years behind the thinking of the bitcointalk.org
class of 2012 are still the brightest 1% of humanity.
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/aBSVn7nJnrheLy5Z%40erisian.com.au.
next prev parent reply other threads:[~2025-05-02 10:33 UTC|newest]
Thread overview: 38+ 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 20:03 ` [bitcoindev] Removing OP_Return restrictions: Devil's Advocate Position Peter Todd
2025-05-02 6:29 ` [bitcoindev] Re: Relax OP_RETURN standardness restrictions Greg Maxwell
2025-05-02 9:51 ` Anthony Towns [this message]
2025-05-02 17:36 ` Greg Maxwell
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=aBSVn7nJnrheLy5Z@erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoindev@googlegroups.com \
--cc=gmaxwell@gmail$(echo .)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