Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling

Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling
2022-11-02 13:58 ` Greg Sanders
  2022-11-02 14:04 ` Peter Todd
  
From: Antoine Riard @ 2022-11-02  2:21 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 5308 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 5591 bytes --]

 permalink raw reply	[|nested]
2022-11-02  2:21 [bitcoin-dev] Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling Antoine Riard

  2022-11-02 14:04 ` Peter Todd
  
From: Greg Sanders @ 2022-11-02 13:58 UTC (permalink / raw)
  To: Antoine Riard, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 6499 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 7304 bytes --]

 permalink raw reply	[|nested]
2022-11-02  2:21 [bitcoin-dev] Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling Antoine Riard
  2022-11-02 13:58 ` Greg Sanders

  2022-11-02 14:19   ` Greg Sanders
  
From: Peter Todd @ 2022-11-02 14:04 UTC (permalink / raw)
  To: Antoine Riard, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1781 bytes --]

On Tue, Nov 01, 2022 at 10:21:59PM -0400, Antoine Riard via bitcoin-dev 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.

Strong NACK.

Zeroconf is, at best, a very marginal usecase. The only services that have
spoken up in support of it are Bitrefill and Muun, and the latter says they're
working to get rid of their vulnerability to it. People attempting to make it
secure have repeatedly done sybil attacks against the network in attempts to
measure transaction propagation. And of course, if transaction fees and full
mempools are in our near future - as is widely expected - mempool consistency
will even further diminish making zeroconf even harder to achieve.

Incurring a bunch of engineering costs and harming privacy for the sake of
continuing this nonsense is ridiculous.

If anything, we should be moving to full-RBF so we can undo the privacy cost
that is opt-in-RBF: right now 30% of transactions are having to harm their
privacy by signalling support for it. Full-RBF will allow that wallet
distinguisher to be eliminated.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2022-11-02 14:04 ` Peter Todd

  2022-11-02 14:33     ` Peter Todd
  
From: Greg Sanders @ 2022-11-02 14:19 UTC (permalink / raw)
  To: Peter Todd, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 3019 bytes --]

Sorry, I forgot one point which is pertinent to this conversation.

*Even with* fullrbf-everywhere and V3, pinning via rule#3 and rule#5 are
still an issue in coinjoin scenarios.

Each coinjoin adversary can double-spend their coin to either full package
weight(101kvb),
or give 24 descendants, which means you quickly pay out the nose in rule#3
or are excluded
from RBFing it if you have 4+ greifers in your coinjoin violating rule#5.

If we instead narrowed this policy to marking a transaction output as
opt-in to V3, it gets a bit more interesting. *Unfortunately,
double-spending counterparties can still cause rule#3 pain, one 100kvb
package of junk per peer,* but rule#5 violations is at least contained to
coinjoins with ~50 peers(assuming two transactions booted per input
double-spent, which would be the V3 max bumped per input).

It's still worth exploring, but very speculatively.

Greg

On Wed, Nov 2, 2022 at 10:04 AM Peter Todd via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:

> On Tue, Nov 01, 2022 at 10:21:59PM -0400, Antoine Riard via bitcoin-dev
> 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.
>
> Strong NACK.
>
> Zeroconf is, at best, a very marginal usecase. The only services that have
> spoken up in support of it are Bitrefill and Muun, and the latter says
> they're
> working to get rid of their vulnerability to it. People attempting to make
> it
> secure have repeatedly done sybil attacks against the network in attempts
> to
> measure transaction propagation. And of course, if transaction fees and
> full
> mempools are in our near future - as is widely expected - mempool
> consistency
> will even further diminish making zeroconf even harder to achieve.
>
> Incurring a bunch of engineering costs and harming privacy for the sake of
> continuing this nonsense is ridiculous.
>
> If anything, we should be moving to full-RBF so we can undo the privacy
> cost
> that is opt-in-RBF: right now 30% of transactions are having to harm their
> privacy by signalling support for it. Full-RBF will allow that wallet
> distinguisher to be eliminated.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 3942 bytes --]

 permalink raw reply	[|nested]
2022-11-02 14:19   ` Greg Sanders

  2022-11-02 15:00       ` Greg Sanders
  
From: Peter Todd @ 2022-11-02 14:33 UTC (permalink / raw)
  To: Greg Sanders;  Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

On Wed, Nov 02, 2022 at 10:19:00AM -0400, Greg Sanders wrote:
> Sorry, I forgot one point which is pertinent to this conversation.
> 
> *Even with* fullrbf-everywhere and V3, pinning via rule#3 and rule#5 are
> still an issue in coinjoin scenarios.
> 
> Each coinjoin adversary can double-spend their coin to either full package
> weight(101kvb),
> or give 24 descendants, which means you quickly pay out the nose in rule#3

...and the attacker also pays out the nose if they're exploiting rule #3.

> or are excluded
> from RBFing it if you have 4+ greifers in your coinjoin violating rule#5.
> 
> If we instead narrowed this policy to marking a transaction output as
> opt-in to V3, it gets a bit more interesting. *Unfortunately,
> double-spending counterparties can still cause rule#3 pain, one 100kvb
> package of junk per peer,* but rule#5 violations is at least contained to
> coinjoins with ~50 peers(assuming two transactions booted per input
> double-spent, which would be the V3 max bumped per input).

There's no hard technical reason for rule #5 to even exist. It's simply a
conservative DoS limit to avoid having to do "too much" computation when
processing a replacement in some replacement implementations. We shouldn't
assume it will always exist. And like rule #3 pinning, exploiting it costs
money.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

 permalink raw reply	[|nested]
2022-11-02 14:33     ` Peter Todd

  
From: Greg Sanders @ 2022-11-02 15:00 UTC ( / )
  To: Peter Todd;  Bitcoin Protocol Discussion



> ...and the attacker also pays out the nose if they're exploiting rule #3.

I agree the attacker puts more at stake in this case. If we're assuming
they pay the price and get mined, they can be booted from the protocol
whenever they get mined. I was speaking about the worst case scenario where
it's never mined.

> We shouldn't assume it will always exist.

Just making sure people know that today it does impact things today.

On Wed, Nov 2, 2022, 10:33 AM Peter Todd <pete@petertodd•org> wrote:

> On Wed, Nov 02, 2022 at 10:19:00AM -0400, Greg Sanders wrote:
> > Sorry, I forgot one point which is pertinent to this conversation.
> >
> > *Even with* fullrbf-everywhere and V3, pinning via rule#3 and rule#5 are
> > still an issue in coinjoin scenarios.
> >
> > Each coinjoin adversary can double-spend their coin to either full
> package
> > weight(101kvb),
> > or give 24 descendants, which means you quickly pay out the nose in
> rule#3
>
> ...and the attacker also pays out the nose if they're exploiting rule #3.
>
> > or are excluded
> > from RBFing it if you have 4+ greifers in your coinjoin violating rule#5.
> >
> > If we instead narrowed this policy to marking a transaction output as
> > opt-in to V3, it gets a bit more interesting. *Unfortunately,
> > double-spending counterparties can still cause rule#3 pain, one 100kvb
> > package of junk per peer,* but rule#5 violations is at least contained to
> > coinjoins with ~50 peers(assuming two transactions booted per input
> > double-spent, which would be the V3 max bumped per input).
>
> There's no hard technical reason for rule #5 to even exist. It's simply a
> conservative DoS limit to avoid having to do "too much" computation when
> processing a replacement in some replacement implementations. We shouldn't
> assume it will always exist. And like rule #3 pinning, exploiting it costs
> money.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>