On Thursday, April 17, 2025 at 7:09:23 PM UTC Antoine Poinsot wrote:

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.