Hi Jeremy,

Answering here from #22871 discussions.

I agree on the general principle to not blur mempool policies signaling in committed transaction data. Beyond preserving upgradeability, another good argument is to let L2 nodes update the mempool policies signaling their pre-signed transactions non-interactively. If one of the transaction fields is assigned mempool semantics, in case of tightening policy changes, you will need to re-sign or bear the risks of having non-propagating transactions which opens the door for exploitation by a malicious counterparty. I think this point is kinda relevant if we have future cross-layer coordinated safety fixes to deal with a la CVE-2021-31876.

Even further, a set of L2 counterparties would like to pick up divergent tx-relay/mempool policies, having the signaling fields as part of the signature force them to come to consensus.

I think we can take the opportunity of p2p packages to introduce a new field to signal policy. Of course, a malicious tx-relay peer could modify its content to jam your transaction's propagation but in that case it is easier to just drop it.

One issue with taking back the `nSequence` field for consensus-semantic sounds is depriving the application-layer from a discrete, zero-cost payload (e.g the LN obfuscated commitment number watermark). This might be controversial as we'll increase the price of such applications if they're still willingly to relay application specific data through the p2p network (e.g force them to use a costly OP_RETURN output or payer/payee interactions to setup a pay-to-contract)

W.r.t flag day activation to smooth policy deployment, I think that's something we might rely on in the future though we could distinguish few types of policy deployments :
1) loosening changes (e.g full-rbf/dust threshold removal), a transaction which was relaying under
the former policy should relay under the new one
2) tightening changes (e.g #22871), a transaction which was relaying under the former policy
might not relay under the new one
3) new feature introduced (e.g packages), a transaction is offered a new mode of relay

I think 1) doesn't need that level of ecosystem coordination as applications/second-layers should always benefit from such changes. Maybe with the exception of full-rbf, where we have historical 0-conf softwares, with (broken) security assumptions made on the opt-out RBF mechanism. Same with 3), better to have new features deployed gradually, a flag day activation day in this case won't mean that all higher stacks will jump to use package-relay ?

Where a flag day might make sense would be for 2) ? It would create a higher level of commitment by the base layer software instead of a pure communication on the ML/GH, which might not be concretized in the announced release due to slow review process/feature freeze/rebase conflicts... Reversing the process and asking for Bitcoin applications/higher layers to update first might get us in the trap of never doing the change, as someone might have a small use-case in the corner relying on a given policy behavior.

That said, w.r.t to the proposed policy change in #22871, I think it's better to deploy full-rbf first, then give a time buffer to higher applications to free up the `nSequence` field and finally start to discourage the usage. Otherwise, by introducing new discouragement waivers, e.g not rejecting the usage of the top 8 bits, I think we're moving away from the policy design principle we're trying to establish (separation of mempool policies signaling from consensus data)