My idea, which I hated and didn't propose, was to mark utxos specifically
for this exact purpose, but this is extremely ugly from a wallet/consensus
perspective. nVersion is cleaner(well, except the below issue), at the cost
of forcibly marking all utxos in a transaction the same way.

> 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.

I don't think Core tracks this value in the utxo set either, because
currently there's no use-case for it today? Am I mistaken?

/**
 * A UTXO entry.
 *
 * Serialized format:
 * - VARINT((coinbase ? 1 : 0) | (height << 1))
 * - the non-spent CTxOut (via TxOutCompression)
 */

Greg


On Wed, Nov 2, 2022 at 6:27 AM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi list,
>
> Reading Suhas's post on mempool policy consistency rules, and the grounded
> suggestion that as protocol developers we should work on special policy
> rules to support each reasonable use case on the network rather to arbiter
> between class of use-cases in the design of an
> unified set of rules, reminded me there is another solution to solve
> multi-party funding pinning rather than wide deployment of fullrbf. This
> was communicated to me a while back, and it was originally dismissed
> because of the privacy trade-offs (and potential slight fees overhead
> cost). However, if widely adopted, they might sound acceptable to
> contracting protocol developers and operators.
>
> ## The Problem: Pinning Contracting Protocols Funding Flows with Opt-out
> Double-Spend
>
> As originally laid out [0], multi-party collaborative flows
> (coinjoin/dual-funding/swaps/splicing/etc), where every participant
> contributes at least one input, are suffering from a low-cost and
> high-success DoS vector with asymmetric damages. E.g with lightning
> interactive transaction construction protocols limits of 252 inputs, 1
> single input can bleed the timevalue of the remaining 251 inputs, or engage
> in a MEV attack where the fee-bumping entity is lured to inflate feerate
> beyond the current blockspace demand. The attack can be hidden and a
> posteriori assigning blame consistently stays an open question in the lack
> of a consensus mechanism between participants on the network mempools
> states.
>
> The issue lies in the fact that participants joining inputs together don't
> have control, or even view, of the replacement signaling of any potential
> double-spend of the other participants inputs. Indeed the opt-in fullrbf
> signaling is enforced based on the nSequence field, and this one is fully
> malleable by the UTXO spender. There is no current mechanism to require
> replacement signaling provable to a third-party only on the knowledge of
> the UTXO spents.
>
> # The Solution: Opt-in Full-Replace-by-Fee Spent-nVersion Signaling
>
> A new policy is specified in a new way a transaction can signal that it is
> replaceable.
>
> 1. A confirmed transaction is considered to have opted in to allowing
> replacement of any of its spends (or their descendants), if the last bit of
> the nVersion field is set.
>
> Rational: The future replacement status of any UTXO spend can be
> determined by inspecting the nVersion, therefore protecting the
> collaborative participants of a multi-party flows that the target
> transaction should propagate to the miners, if the fee/feerate offered are
> the best ones without opt-out based pinning. It can be required the UTXOs
> to have few confirmations in case of shallow reorgs to increase DoS
> protection.
>
> ## 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>