Greg Maxwell brought up an idea on the mailinglist that I think is worth preserving here, although I don’t think it’s currently needed:
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.
(emphasis mine)
Relay policy should generally “admit all transactions which are reliably being mined”, in order to not to break compact block relay. But having a more restrictive mining policy doesn’t hurt this relay.
The email uses the example scenario of a setting that we as project believe is useless - and when used as relay policy becomes harmful.
I agree with him that’s still not a good idea. Additionally this use case alone is not worth the implementation complexity (extra test coverage, thinking through attack scenario’s, explaining the nuances in documentation, etc).
But here’s another scenario, where I do think we should consider it:
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.
By having the (default) miner still not include things that break forward compatibility, there remains hope of returning to a status quo where the forward compatibility hook is restored.
Though not much if they’re incentivised to just change the default once and forget about it. So maybe this isn’t a good example.
A third scenario, in retrospect, we could have used it with -mempoolfullrbf
. We could have had an extra step (3) there:
- Add the setting, off by default
- Notice that it was getting mined by >10% of hash rate
- Relay it regardless of the setting, but still not mine it
- Drop the setting (maybe have it on by default first, to match the majority mining usage)
Again I’m not sure how big of a difference that would have made.
[0] https://gnusha.org/pi/bitcoindev/9c50244f-0ca0-40a5-8b76-01ba0d67ec1bn@googlegroups.com/