path: root/a6/da1d4fe2519558d078878c47978fd436883643

Return-Path: <gsanders87@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 56F0FC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Nov 2022 13:59:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 29F2A4025D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Nov 2022 13:59:15 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 29F2A4025D
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=hQMkDYNC
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id P4863wiDU6Ia
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Nov 2022 13:59:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org CB6634023E
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com
 [IPv6:2a00:1450:4864:20::629])
 by smtp4.osuosl.org (Postfix) with ESMTPS id CB6634023E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  2 Nov 2022 13:59:12 +0000 (UTC)
Received: by mail-ej1-x629.google.com with SMTP id kt23so45465157ejc.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 02 Nov 2022 06:59:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :from:to:cc:subject:date:message-id:reply-to;
 bh=WzpN407//eyGFDAjbQy+N5lo4aVZTvOhmyw9sbtdvbs=;
 b=hQMkDYNCuPpgH1LpTt8VrveVkuUrWKmUEoIIrIN3tMgL/PCVyViNCfWXSUE0BeqA3I
 qJmSWpGP13zJsGgopbk/OnmanfrCsSFQLLY6lqZhHv70Ltu+e/wjp0dTUPxjIE/vB6Eg
 WUURazWQoUciG84g5IjHa4BlgXfalA0PU8pX0tCKEOLRXU6WNlu/orvn1dKHL57Nt4ZO
 kUBLJ93BlEdzC40aXV2sGqZVIkhGMwZiLWl5RcQZjhNlo20GEaeQGyxCnB56lPVRKSRI
 nBqvdqkiOlOOqa4YjTM9YecDTzPr52wyWAD8EUvkNfl7klCj8xdXaLp1MSN9kJchbSY6
 gmgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:in-reply-to:references:mime-version
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=WzpN407//eyGFDAjbQy+N5lo4aVZTvOhmyw9sbtdvbs=;
 b=LZJIE2GQNLddpfszKCqxY8z00ohQra3SwEe7ktYL2n8ssYiVFwI9pNZkIFDz3EadXY
 igNS2dT448JZQZgmc2URD4fvm/MCP8bhFdzsve1yIP3IalXJO3/3vgB6p6pD9bFcsBP4
 iN8WJJZ+lXYZ2JKTkMlZyAoDXlLjoYaZesDvww6srvnuwv5jINAqZU1XV0vW+LP3u649
 jWMTg/4eHVclnCljPlc9qYicjS0jweoCx3fY0XmijsQsBycmFOnFH+Qf3a+K0VUV0JX0
 pGd8jVJryTAtl8OMp528shVAw4PHh0WXqXi8+dinP3ATOVs67dS4z1RSNl7k+qGo02th
 glmg==
X-Gm-Message-State: ACrzQf3KlnTto8U4YLSrNO1sElbSOWfjcgmbwdca+F6Pit+3F7Did9s9
 o54cyL4KWEUFXuUs3sBQ7s9OWd5oUh5jnYMRTHxDwp/DlSk=
X-Google-Smtp-Source: AMsMyM7AZtG/ilfsspPnF3FyNKtc7ACffcHRSoIBUlhftGtR2FPU74PeZrOPMK2XrPnNBtb+dzaGRmzGWVYzzIeRihc=
X-Received: by 2002:a17:906:858a:b0:7ad:d164:bc45 with SMTP id
 v10-20020a170906858a00b007add164bc45mr16276076ejx.113.1667397550971; Wed, 02
 Nov 2022 06:59:10 -0700 (PDT)
MIME-Version: 1.0
References: <CALZpt+GZAd-vYMzUMicg0c9OyyWExtT5EH61Hms6NNOM19ddZA@mail.gmail.com>
In-Reply-To: <CALZpt+GZAd-vYMzUMicg0c9OyyWExtT5EH61Hms6NNOM19ddZA@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Wed, 2 Nov 2022 09:58:59 -0400
Message-ID: <CAB3F3DsSpyAVz+_7buznG5GFRZ8yDDKRneBg4KBJb1MD4Zk_VQ@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b99efc05ec7d3ea5"
Subject: Re: [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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Nov 2022 13:59:15 -0000

--000000000000b99efc05ec7d3ea5
Content-Type: text/plain; charset="UTF-8"

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
>

--000000000000b99efc05ec7d3ea5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>My idea, which I hated and didn&#39;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 th=
e same way.<br></div><div><br></div><div>&gt; On the validation-side, there=
 is one engineering issue, as I think there is no access to the spent nvers=
ion fields by the mempool logic.</div><div><br></div><div>I don&#39;t think=
 Core tracks this value in the utxo set either, because currently there&#39=
;s no use-case for it today? Am I mistaken?</div><div><br></div><div>/**<br=
></div><div>=C2=A0* A UTXO entry.<br>=C2=A0*<br>=C2=A0* Serialized format:<=
br>=C2=A0* - VARINT((coinbase ? 1 : 0) | (height &lt;&lt; 1))<br>=C2=A0* - =
the non-spent CTxOut (via TxOutCompression)<br>=C2=A0*/<br></div><div><br><=
/div><div>Greg</div><div><br></div></div><br><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Wed, Nov 2, 2022 at 6:27 AM Antoine R=
iard via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundatio=
n.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div>Hi list,<br><br>Reading Suhas&#39;s post on mempool policy consist=
ency rules, and the grounded suggestion that as protocol developers we shou=
ld 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<br=
>unified set of rules, reminded me there is another solution to solve multi=
-party funding pinning rather than wide deployment of fullrbf. This was com=
municated to me a while back, and it was originally dismissed because of th=
e privacy trade-offs (and potential slight fees overhead cost). However, if=
 widely adopted, they might sound acceptable to contracting protocol develo=
pers and operators.<br><br>## The Problem: Pinning Contracting Protocols Fu=
nding Flows with Opt-out Double-Spend<br><br>As originally laid out [0], mu=
lti-party collaborative flows (coinjoin/dual-funding/swaps/splicing/etc), w=
here every participant contributes at least one input, are suffering from a=
 low-cost and high-success DoS vector with asymmetric damages. E.g with lig=
htning interactive transaction construction protocols limits of 252 inputs,=
 1 single input can bleed the timevalue of the remaining 251 inputs, or eng=
age in a MEV attack where the fee-bumping entity is lured to inflate feerat=
e beyond the current blockspace demand. The attack can be hidden and a post=
eriori assigning blame consistently stays an open question in the lack of a=
 consensus mechanism between participants on the network mempools states.<b=
r><br>The issue lies in the fact that participants joining inputs together =
don&#39;t have control, or even view, of the replacement signaling of any p=
otential double-spend of the other participants inputs. Indeed the opt-in f=
ullrbf signaling is enforced based on the nSequence field, and this one is =
fully malleable by the UTXO spender. There is no current mechanism to requi=
re replacement signaling provable to a third-party only on the knowledge of=
 the UTXO spents.<br><br># The Solution: Opt-in Full-Replace-by-Fee Spent-n=
Version Signaling<br><br>A new policy is specified in a new way a transacti=
on can signal that it is replaceable.<br><br>1. A confirmed transaction is =
considered to have opted in to allowing replacement of any of its spends (o=
r their descendants), if the last bit of the nVersion field is set.<br><br>=
Rational: The future replacement status of any UTXO spend can be determined=
 by inspecting the nVersion, therefore protecting the collaborative partici=
pants of a multi-party flows that the target transaction should propagate t=
o 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 ca=
se of shallow reorgs to increase DoS protection.<br></div><div><br>## Solut=
ion trade-offs<br><br>On the validation-side, there is one engineering issu=
e, as I think there is no access to the spent nversion fields by the mempoo=
l logic. This would presume we add some new cache of all the confirmed UTXO=
s, so ~50M * 4bytes, 300 MB of additional state for policy-enforcing full-n=
odes. I don&#39;t know if there is another strong drawback, even the reorg =
logic the replaceable spends shouldn&#39;t be evicted if the confirmed ance=
stor is back to the mempool, as mempool validity shouldn&#39;t be reevaluat=
ed before a replacement candidate shows up. A fee penalty could be requeste=
d for nVersion-signaling transactions to compensate for the additional stat=
e stored by full-node operators (even if obviously they&#39;re not the ones=
 earning the fees).<br><br>For the contracting protocols wallets, as you do=
n&#39;t know in advance which coins are going to be used for a collaborativ=
e flow, you&#39;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 ch=
ange the replacement status of the spends of your coins. However, this poli=
cy bookmarking comes as a protocol fingerprint leak for an observer of the =
transaction logs. If all the second-layers used by default, this is constit=
uting a single anonymity set, though it might still be the privacy gains we=
&#39;re harvesting from Taproot output usage in the optimistic case (e.g in=
 Lightning no commitment + HTLC transactions broadcast).<br><br>For the zer=
oconf operators, assuming they have access to the UTXO set, they can inspec=
t the receiving transactions ancestors nVersion fields, and sort those tran=
sactions in the wider set of the replaceable ones, as they&#39;re currently=
 doing for BIP125 opt-in ones.<br><br>Long-term, the annoying privacy issue=
 and the assumption that any wallet will be a Lightning one could lead to t=
he majority of wallets signaling RBF for their spends. Therefore making tho=
se wallets incompatible with zeroconf services, slowly economically outlawi=
ng them. From my perspective, though it might be a simplification, it sound=
s an alternative full rbf way forward, where rather than having miners deci=
ding on the policy enforcement, we let the users decide with their coins. H=
owever, this new policy enforcement efficiency is still dependent on the ex=
istence of relay paths and support at the endpoints that matter, the miner =
mempools. So in fine we might have to realize incentive alignment with hash=
rate is what matters in terms of transaction-relay rules ?<br><br>Credit to=
 Greg Maxwell for this idea.<br><br>Cheers,<br>Antoine<br><br>[0] <a href=
=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/0030=
33.html" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/ligh=
tning-dev/2021-May/003033.html</a><br></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000b99efc05ec7d3ea5--