## Solution trade-offs
On the validation-side, there is one engineering issue, as I think there is no access to the spent nversion fields by the mempool logic. This would presume we add some new cache of all the confirmed UTXOs, so ~50M * 4bytes, 300 MB of additional state for policy-enforcing full-nodes. I don't know if there is another strong drawback, even the reorg logic the replaceable spends shouldn't be evicted if the confirmed ancestor is back to the mempool, as mempool validity shouldn't be reevaluated before a replacement candidate shows up. A fee penalty could be requested for nVersion-signaling transactions to compensate for the additional state stored by full-node operators (even if obviously they're not the ones earning the fees).
For the contracting protocols wallets, as you don't know in advance which coins are going to be used for a collaborative flow, you're better off to mark all your coins nVersion fields opting fullrbf. Otherwise, you will have to go through an on-chain fee cost to change the replacement status of the spends of your coins. However, this policy bookmarking comes as a protocol fingerprint leak for an observer of the transaction logs. If all the second-layers used by default, this is constituting a single anonymity set, though it might still be the privacy gains we're harvesting from Taproot output usage in the optimistic case (e.g in Lightning no commitment + HTLC transactions broadcast).
For the zeroconf operators, assuming they have access to the UTXO set, they can inspect the receiving transactions ancestors nVersion fields, and sort those transactions in the wider set of the replaceable ones, as they're currently doing for BIP125 opt-in ones.
Long-term, the annoying privacy issue and the assumption that any wallet will be a Lightning one could lead to the majority of wallets signaling RBF for their spends. Therefore making those wallets incompatible with zeroconf services, slowly economically outlawing them. From my perspective, though it might be a simplification, it sounds an alternative full rbf way forward, where rather than having miners deciding on the policy enforcement, we let the users decide with their coins. However, this new policy enforcement efficiency is still dependent on the existence of relay paths and support at the endpoints that matter, the miner mempools. So in fine we might have to realize incentive alignment with hashrate is what matters in terms of transaction-relay rules ?
Credit to Greg Maxwell for this idea.
Cheers,
Antoine
[0]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html