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!