Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1D4B0C002D for ; Wed, 2 Nov 2022 02:22:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id ECDC18140F for ; Wed, 2 Nov 2022 02:22:12 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org ECDC18140F Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=F4AdLNGf X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuEcE5OCz1id for ; Wed, 2 Nov 2022 02:22:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 7EFB6813A9 Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) by smtp1.osuosl.org (Postfix) with ESMTPS id 7EFB6813A9 for ; Wed, 2 Nov 2022 02:22:11 +0000 (UTC) Received: by mail-io1-xd2b.google.com with SMTP id 11so14002136iou.0 for ; Tue, 01 Nov 2022 19:22:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=17POhJjZAhwRuftTQPQ+DdDHUzTVXCn+0Y8KKsulah4=; b=F4AdLNGfAb/MEMz8JAtCABTJ+3cUGsOIXz5lkXG3z0jhBMp3mQ6IS4TZzBT+BfbVJe ezZVvTXM8hK/6erVkLkViQmL/92cAOivNI+4FgSH/s1kdshnWwgm2lbhKBCGUfinR6kg IY4h4BtyNvB3CKuuinMjDfEeyWYNoHCcuNZfuWKofM+kyneVf9fkwROTj778l0HQHIug Mf6+GvReS6Retx7jmu/kPH3eFIKDk7vwF2+aTYC7N75+HstEVi0yyyDW/r4uqnH7JPs2 ywjMTOnSLbdqce6lRMQdfXFv4IvFCE4Sk6DNrlfEzBRxtsV1Ba/850d9kytalhR+Rc9W 187Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=17POhJjZAhwRuftTQPQ+DdDHUzTVXCn+0Y8KKsulah4=; b=Y1vK5Hzi2eCIpLW8Ifi+98gf5nO3IPq7eQ0ykZSbG3OL+EsUqIw0lRqP4iGXMRpOSU cZLN3PNgJXkGrTisexObRkUf9Ywav1NemR4ize1huHrkDGa5MlJlAe/z8DWBWVEbBNqn fGjyCd65pQcXQ+phWKzEs5pHuBJhpNJ5Ih86UhVJ4YQZO5FI4UoXFW0GY5IgXw0BfXqT gDlQ+hXJto5lkLICndePqtRddS7pr2HGr7MrOJZKy+gwR3OeO+qNPdKFuGc1W7ho1F2e 0rrSabXQdwpM1gOhFu1aPmhBaQoAEtz8WejE75uMKWDOzVZicpcWxlPfDi6qix74/1XY tr/Q== X-Gm-Message-State: ACrzQf3Ly30zG8w6FFJcRfJDZP34MRKGOjto39KcLzWn3u1+cVkrBhRG iJbyxBSRlXOHroTR56Nr0RyR02o76QIGVO4CJWqBFMeFG75KHb00 X-Google-Smtp-Source: AMsMyM40Asui2fli2D1FRiB362iIzexWJX1yDK6+XnEd5swFBegkjjG1MTd0Gq/KEt5jB8Dp1xQVb2fTussstbsiASw= X-Received: by 2002:a05:6638:3f10:b0:375:71c7:c296 with SMTP id ck16-20020a0566383f1000b0037571c7c296mr4216289jab.155.1667355730267; Tue, 01 Nov 2022 19:22:10 -0700 (PDT) MIME-Version: 1.0 From: Antoine Riard Date: Tue, 1 Nov 2022 22:21:59 -0400 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000004554305ec738234" X-Mailman-Approved-At: Wed, 02 Nov 2022 10:26:56 +0000 Subject: [bitcoin-dev] Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2022 02:22:13 -0000 --00000000000004554305ec738234 Content-Type: text/plain; charset="UTF-8" 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 --00000000000004554305ec738234 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi list,

Reading Suhas's post on mempool p= olicy consistency rules, and the grounded suggestion that as protocol devel= opers 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 de= sign of an
unified set of rules, reminded me there is another solution t= o 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 pr= otocol developers and operators.

## The Problem: Pinning Contracting= Protocols Funding Flows with Opt-out Double-Spend

As originally lai= d out [0], multi-party collaborative flows (coinjoin/dual-funding/swaps/spl= icing/etc), where every participant contributes at least one input, are suf= fering from a low-cost and high-success DoS vector with asymmetric damages.= E.g with lightning interactive transaction construction protocols limits o= f 252 inputs, 1 single input can bleed the timevalue of the remaining 251 i= nputs, or engage in a MEV attack where the fee-bumping entity is lured to i= nflate feerate beyond the current blockspace demand. The attack can be hidd= en and a posteriori assigning blame consistently stays an open question in = the lack of a consensus mechanism between participants on the network mempo= ols states.

The issue lies in the fact that participants joining inp= uts together don't have control, or even view, of the replacement signa= ling 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 mecha= nism to require replacement signaling provable to a third-party only on the= knowledge of the UTXO spents.

# The Solution: Opt-in Full-Replace-b= y-Fee Spent-nVersion Signaling

A new policy is specified in a new wa= y a transaction can signal that it is replaceable.

1. A confirmed tr= ansaction 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 collabor= ative participants of a multi-party flows that the target transaction shoul= d propagate to the miners, if the fee/feerate offered are the best ones wit= hout opt-out based pinning. It can be required the UTXOs to have few confir= mations in case of shallow reorgs to increase DoS protection.

## Solution trade-offs

On the validation-side, there is one eng= ineering 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 c= onfirmed UTXOs, so ~50M * 4bytes, 300 MB of additional state for policy-enf= orcing full-nodes. I don't know if there is another strong drawback, ev= en the reorg logic the replaceable spends shouldn't be evicted if the c= onfirmed ancestor is back to the mempool, as mempool validity shouldn't= be reevaluated before a replacement candidate shows up. A fee penalty coul= d be requested for nVersion-signaling transactions to compensate for the ad= ditional state stored by full-node operators (even if obviously they're= not the ones earning the fees).

For the contracting protocols walle= ts, 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 f= ee cost to change the replacement status of the spends of your coins. Howev= er, this policy bookmarking comes as a protocol fingerprint leak for an obs= erver of the transaction logs. If all the second-layers used by default, th= is is constituting a single anonymity set, though it might still be the pri= vacy 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, th= ey can inspect the receiving transactions ancestors nVersion fields, and so= rt 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 co= uld lead to the majority of wallets signaling RBF for their spends. Therefo= re making those wallets incompatible with zeroconf services, slowly economi= cally outlawing them. From my perspective, though it might be a simplificat= ion, it sounds an alternative full rbf way forward, where rather than havin= g miners deciding on the policy enforcement, we let the users decide with t= heir coins. However, this new policy enforcement efficiency is still depend= ent on the existence of relay paths and support at the endpoints that matte= r, the miner mempools. So in fine we might have to realize incentive alignm= ent 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-d= ev/2021-May/003033.html
--00000000000004554305ec738234--