path: root/eb/fe4bcb980df29ef2f17f3f9b1c6d5e2c049594

Return-Path: <antoine.riard@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7560FC002B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Feb 2023 03:33:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 49E0F80C2D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Feb 2023 03:33:39 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 49E0F80C2D
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=PlCog4j+
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 CrStRU5Qm9nH
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Feb 2023 03:33:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 02C5480BB0
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com
 [IPv6:2607:f8b0:4864:20::131])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 02C5480BB0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed, 15 Feb 2023 03:33:36 +0000 (UTC)
Received: by mail-il1-x131.google.com with SMTP id 18so1021788ilg.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 14 Feb 2023 19:33:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=uF0V/tMJGQT1au+GPwcGZnaHZgrHFguvxE24QmB7v2U=;
 b=PlCog4j+6WChAB8ipLv1aPT0k7BSmT7nS/EFsCWvVIbMaAM420zrUGysu/7J3DFmkk
 CXd5v8sQbAZ32vuI/Pk9t3InxmAB/qxnSrQ9zqJ8KYivn2oKMLp7tm47Q3XrOlevipzr
 V5ooV0Nhe8FdGwRZZqNBDn9CYv4mf8ToSz8Lbke5SxZtxkvrJ09OeZq07C0q8pyZeEZh
 bka+hilN45k2u2025o1OqmGO1gQE7Gsr3U4kfmGdokNBtM1yGjsO84Yy4IlhDbgdRcQB
 F3nVWZ5P8niN9L+R2SOAg+k2oqX6VRubaOLVUo1j7PxBIbCF6gntpIod+CitoUM0tSJt
 uXiQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc: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=uF0V/tMJGQT1au+GPwcGZnaHZgrHFguvxE24QmB7v2U=;
 b=QyCM8mTGFrxYgpwVTu8ykyiJ5F27gUC4RpIKvrEP0/kZ5qHgV0MSozf28Fykg6edvv
 UXJzj0OmtxL1kMxcs7HuCyoiC3CgeLKJp/1k9/ossgjCpPVytC4Xmd35P28N8Ob/lWtv
 zlzVaWltx2D56m/lWl9i53hDr8gnM9Y9PGeOU0HBnaIT2+chTajMauhZLTYcTXMZDipw
 te5YFumZvyyAwZy7KGlPeabC5ernD5M34xK1lVVyGmByOLydMvnnL4Cz6GiykNB/FKHd
 ZG+bQaIa9t7W6ymba5WQMRbVJ9nxwFo/FACwaBFO96Flfuk6hHSRwukZvuoDFpdJJ8o/
 ZvYg==
X-Gm-Message-State: AO0yUKVAzy4o1DyXanY90cXWNpWgZm3f8pzPR7J952sVfDsRu5OQYjDC
 VeE8Rhj2XKjm5rKPg+UfAYxju9eikwrj38wiIA/05Swjkfc=
X-Google-Smtp-Source: AK7set8AwSfgKeSc3Nn6epO0G62MTKX8KT+26bRsUO8EOq2owS822rW3ujVE5wOQxqRIJ0SrzLGATfFpxcMD6tq+xbE=
X-Received: by 2002:a92:4441:0:b0:313:f870:58fb with SMTP id
 a1-20020a924441000000b00313f87058fbmr288424ilm.2.1676432015856; Tue, 14 Feb
 2023 19:33:35 -0800 (PST)
MIME-Version: 1.0
References: <CAAQdECCH=YOcu4g6Ku1_G4CnRg6rsaFPFPwbABx9aZin9A8+2A@mail.gmail.com>
 <CALZpt+E2XKmqAELcedN8-5JkCOwmEH-CN8nwmpwW74xGUZPtbA@mail.gmail.com>
 <CAAQdECCDfmAmxvSWfTsiTz_0TecpA8zoryZzHT==mXDU0p-xoA@mail.gmail.com>
In-Reply-To: <CAAQdECCDfmAmxvSWfTsiTz_0TecpA8zoryZzHT==mXDU0p-xoA@mail.gmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 15 Feb 2023 03:33:24 +0000
Message-ID: <CALZpt+HYinkSWvy56ky4KJrmLGaN1OxBy+6MOX6VkRgQu-7Y6g@mail.gmail.com>
To: Yuval Kogman <nothingmuch@woobling.org>
Content-Type: multipart/alternative; boundary="000000000000cb9bc705f4b4bebf"
X-Mailman-Approved-At: Wed, 15 Feb 2023 08:49:53 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Unenforceable fee obligations in multiparty
 protocols with Taproot inputs
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, 15 Feb 2023 03:33:39 -0000

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

> Apologies for not citing, I think I must have seen that before but
> only remembered the pinning variants, and so did not recall it at the
> time that I wrote this up, which I did rather hastily.

> However, I do think the adversary model should be broadened, as there
> is a potential positive externality to a party which simply wishes to
> get some witness data confirmed in a block while paying less than the
> market rate, without needing to assume time sensitive contracts in the
> threat model.


Please no apologies - Message matters more than the messenger in

open-source. Yes, on the adversary model I would like to note there is a

potential negative externality in the context of time-sensitive contract,
e.g

for a DLC with short-term maturity you can delay confirmation of the fundin=
g

transaction in function of the event outcome progression (e.g a basketball
quarters),

and if the outcome turns in your defavor, you just double-spend a funding
input.


> What I had in mind was the estimated witness size messages in the dual
> funding proposal and felt they would create a false sense of
> validation, specifically in the context of an adversary interested in
> having their ordinal inscriptions being paid for by someone else by
> subverting the a priori agreed upon feerate. From my point of view
> this is primarily an argument for RBF by default (ideally full RBF, as
> rule 3 of BIP 125 imposes difficult constraints on multiparty
> transaction construction) in such protocols.


We could have miniscript embedded in the backend of a Lightning

implementation, to reject any malleable witness (maybe with some tolerance
bounds ?),

to restrain a counterparty downgrading a posteriori its feerate
contribution.

Full rbf effectively would prevent timevalue DoS inflicted to the
most-utxo-value

contributor in dual-funding, however in the present flow, I don't know if i=
t

changes something, the witness downgrading counterparty benefits from

a feerate discount, not lack of confirmation.


> Yes, that doesn't make things incentive compatible but allows the
> potential victims to have clearer bounds on the potential positive
> payoff to the adversary. I think that's mainly useful in conjunction
> constraining the order of signature submission, going from smallest to
> largest input seems intuitively compelling but it seems to me like
> ordering by feerate of creating transaction or perhaps some
> combination of the two might provide a stronger deterrent.


I think some combination of the two can makes sense, as if the feerate

is what you paid, the input value is your "economically subjective"
liquidity

risk, and as such you might pay a better signature submission place for

a feerate contribution increase. Quite sophisticated for the basic
dual-funding flow.


> Either way the main takeaway in my opinion is not that this is a
> serious attack, as it's hard to exploit in theory and as far as I know
> none of the currently deployed protocols are in any way vulnerable:

> 1. dual funding supports RBF and quite amenable to reputation based
mitigations
> 2. in JoinMarket the taker can protect themselves
> 3. centralized coinjoins, despite misleading claims to the contrary by
> both vendors, currently strongly rely on a trusted server for many
> other aspects of the protocol and all three protocols are not
> currently exploitable as described (the attacker can't broadcast the
> transaction with a witness that would otherwise be rejected by the
> server)

> ... but rather that (full) RBF is required for incentive compatible
> multiparty transactions (or the closest approximation of incentive
> compatibility possible barring future soft forks).


Yep yep, all types of DoS are less concerning than "loss of funds"

severity pinning attacks, and doesn't sounds to affect currently

deployed protocols. Still concerned all those DoS once accumulated

might be a "practical" show-stopper, like we have with channel jamming.



Le ven. 10 f=C3=A9vr. 2023 =C3=A0 19:35, Yuval Kogman <nothingmuch@woobling=
.org> a
=C3=A9crit :

> On Wed, 8 Feb 2023 at 02:56, Antoine Riard <antoine.riard@gmail.com>
> wrote:
> > From what I understand, there are many inputs for the coinjoin
> transaction, the latest signer provides an inflated witness downgrading t=
he
> multi-party transaction feerate.
>
> Yep!
>
> >  It doesn't sound to me a fee siphoning as occurring with loose
> malleability [0], rather another case of transaction-relay jamming where
> the adversary's goal is to slow down the confirmation of the transaction =
to
> waste everyone timevalue.
> >
> > I think the issue has already been mentioned to advocate updating Core'=
s
> mempool acceptance policy, and allows wtxid-replacement [1]. There is als=
o
> a description available here [2].
>
> Yep, the mechanism is basically the same as witness malleability based
> jamming.
>
> Apologies for not citing, I think I must have seen that before but
> only remembered the pinning variants, and so did not recall it at the
> time that I wrote this up, which I did rather hastily.
>
> However, I do think the adversary model should be broadened, as there
> is a potential positive externality to a party which simply wishes to
> get some witness data confirmed in a block while paying less than the
> market rate, without needing to assume time sensitive contracts in the
> threat model.
>
> What I had in mind was the estimated witness size messages in the dual
> funding proposal and felt they would create a false sense of
> validation, specifically in the context of an adversary interested in
> having their ordinal inscriptions being paid for by someone else by
> subverting the a priori agreed upon feerate. From my point of view
> this is primarily an argument for RBF by default (ideally full RBF, as
> rule 3 of BIP 125 imposes difficult constraints on multiparty
> transaction construction) in such protocols.
>
> > I don't think increasing adversary costliness is that efficient as ther=
e
> is a scaling effect (e.g the feerate of the previous transaction can be
> used to feed N outputs for N dissociated attack contexts).
>
> Yes, that doesn't make things incentive compatible but allows the
> potential victims to have clearer bounds on the potential positive
> payoff to the adversary. I think that's mainly useful in conjunction
> constraining the order of signature submission, going from smallest to
> largest input seems intuitively compelling but it seems to me like
> ordering by feerate of creating transaction or perhaps some
> combination of the two might provide a stronger deterrent.
>
> Either way the main takeaway in my opinion is not that this is a
> serious attack, as it's hard to exploit in theory and as far as I know
> none of the currently deployed protocols are in any way vulnerable:
>
> 1. dual funding supports RBF and quite amenable to reputation based
> mitigations
> 2. in JoinMarket the taker can protect themselves
> 3. centralized coinjoins, despite misleading claims to the contrary by
> both vendors, currently strongly rely on a trusted server for many
> other aspects of the protocol and all three protocols are not
> currently exploitable as described (the attacker can't broadcast the
> transaction with a witness that would otherwise be rejected by the
> server)
>
> ... but rather that (full) RBF is required for incentive compatible
> multiparty transactions (or the closest approximation of incentive
> compatibility possible barring future soft forks).
>

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

<div dir=3D"ltr"><p style=3D"margin:0px;font-stretch:normal;font-size:11px;=
line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color=
:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">&gt;=
 Apologies for not citing, I think I must have seen that before but</span><=
br style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><sp=
an style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font=
-size:small">&gt; only remembered the pinning variants, and so did not reca=
ll it at the</span><br style=3D"color:rgb(34,34,34);font-family:Arial,Helve=
tica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helve=
tica,sans-serif;font-size:small">&gt; time that I wrote this up, which I di=
d rather hastily.</span><br style=3D"color:rgb(34,34,34);font-family:Arial,=
Helvetica,sans-serif"><br style=3D"color:rgb(34,34,34);font-family:Arial,He=
lvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial,He=
lvetica,sans-serif;font-size:small">&gt; However, I do think the adversary =
model should be broadened, as there</span><br style=3D"color:rgb(34,34,34);=
font-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);=
font-family:Arial,Helvetica,sans-serif;font-size:small">&gt; is a potential=
 positive externality to a party which simply wishes to</span><br style=3D"=
color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><span style=3D"=
color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small"=
>&gt; get some witness data confirmed in a block while paying less than the=
</span><br style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-se=
rif"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-se=
rif;font-size:small">&gt; market rate, without needing to assume time sensi=
tive contracts in the</span><br style=3D"color:rgb(34,34,34);font-family:Ar=
ial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Ar=
ial,Helvetica,sans-serif;font-size:small">&gt; threat model.</span><br></p>=
<p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:norma=
l;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);fo=
nt-family:Arial,Helvetica,sans-serif;font-size:small"><br></span></p><p sty=
le=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font=
-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-fam=
ily:Arial,Helvetica,sans-serif;font-size:small">Please no apologies - Messa=
ge matters more than the messenger in</span></p><p style=3D"margin:0px;font=
-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:r=
gb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,s=
ans-serif;font-size:small">open-source. Yes,=C2=A0</span><span style=3D"col=
or:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">on=
 the adversary model I would like to note there is a</span></p><p style=3D"=
margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-famil=
y:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Ar=
ial,Helvetica,sans-serif;font-size:small">potential negative=C2=A0</span><s=
pan style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;fon=
t-size:small">externality in the context of time-sensitive contract, e.g</s=
pan></p><p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-heig=
ht:normal;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,3=
4,34);font-family:Arial,Helvetica,sans-serif;font-size:small">for a DLC wit=
h=C2=A0</span><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetic=
a,sans-serif;font-size:small">short-term maturity you can delay confirmatio=
n of the funding</span></p><p style=3D"margin:0px;font-stretch:normal;font-=
size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span styl=
e=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:s=
mall">transaction=C2=A0</span><span style=3D"color:rgb(34,34,34);font-famil=
y:Arial,Helvetica,sans-serif;font-size:small">in function of the event outc=
ome progression (e.g a basketball quarters),</span></p><p style=3D"margin:0=
px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;=
color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helv=
etica,sans-serif;font-size:small">and if the outcome turns in your defavor,=
 you just double-spend a funding input.</span></p><p style=3D"margin:0px;fo=
nt-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color=
:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica=
,sans-serif;font-size:small"><br></span></p><p style=3D"margin:0px;font-str=
etch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0=
,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-=
serif;font-size:small">&gt; What I had in mind was the estimated witness si=
ze messages in the dual</span><br style=3D"color:rgb(34,34,34);font-family:=
Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:=
Arial,Helvetica,sans-serif;font-size:small">&gt; funding proposal and felt =
they would create a false sense of</span><br style=3D"color:rgb(34,34,34);f=
ont-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);f=
ont-family:Arial,Helvetica,sans-serif;font-size:small">&gt; validation, spe=
cifically in the context of an adversary interested in</span><br style=3D"c=
olor:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><span style=3D"c=
olor:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">=
&gt; having their ordinal inscriptions being paid for by someone else by</s=
pan><br style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif=
"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif=
;font-size:small">&gt; subverting the a priori agreed upon feerate. From my=
 point of view</span><br style=3D"color:rgb(34,34,34);font-family:Arial,Hel=
vetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial,Hel=
vetica,sans-serif;font-size:small">&gt; this is primarily an argument for R=
BF by default (ideally full RBF, as</span><br style=3D"color:rgb(34,34,34);=
font-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);=
font-family:Arial,Helvetica,sans-serif;font-size:small">&gt; rule 3 of BIP =
125 imposes difficult constraints on multiparty</span><br style=3D"color:rg=
b(34,34,34);font-family:Arial,Helvetica,sans-serif"><span style=3D"color:rg=
b(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">&gt; tr=
ansaction construction) in such protocols.</span><span style=3D"color:rgb(3=
4,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small"><br></span=
></p><p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:=
normal;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,3=
4);font-family:Arial,Helvetica,sans-serif;font-size:small"><br></span></p><=
p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:normal=
;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);fon=
t-family:Arial,Helvetica,sans-serif;font-size:small">We could have miniscri=
pt embedded in the backend of a Lightning</span></p><p style=3D"margin:0px;=
font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;col=
or:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helveti=
ca,sans-serif;font-size:small">implementation, to reject any malleable witn=
ess (maybe with some tolerance bounds ?),</span></p><p style=3D"margin:0px;=
font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;col=
or:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helveti=
ca,sans-serif;font-size:small">to restrain a counterparty downgrading a pos=
teriori its feerate contribution.</span></p><p style=3D"margin:0px;font-str=
etch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0=
,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-=
serif;font-size:small">Full rbf effectively would prevent timevalue DoS inf=
licted to the most-utxo-value</span></p><p style=3D"margin:0px;font-stretch=
:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0=
)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-seri=
f;font-size:small">contributor in dual-funding, however in the present flow=
, I don&#39;t know if it</span></p><p style=3D"margin:0px;font-stretch:norm=
al;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><s=
pan style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;fon=
t-size:small">changes something, the witness downgrading counterparty benef=
its from</span></p><p style=3D"margin:0px;font-stretch:normal;font-size:11p=
x;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"col=
or:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">a =
feerate discount, not lack of confirmation.</span></p><p style=3D"margin:0p=
x;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;c=
olor:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helve=
tica,sans-serif;font-size:small"><br></span></p><p style=3D"margin:0px;font=
-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:r=
gb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,s=
ans-serif;font-size:small">&gt; Yes, that doesn&#39;t make things incentive=
 compatible but allows the</span><br style=3D"color:rgb(34,34,34);font-fami=
ly:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-fami=
ly:Arial,Helvetica,sans-serif;font-size:small">&gt; potential victims to ha=
ve clearer bounds on the potential positive</span><br style=3D"color:rgb(34=
,34,34);font-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34=
,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">&gt; payoff=
 to the adversary. I think that&#39;s mainly useful in conjunction</span><b=
r style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><spa=
n style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-=
size:small">&gt; constraining the order of signature submission, going from=
 smallest to</span><br style=3D"color:rgb(34,34,34);font-family:Arial,Helve=
tica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helve=
tica,sans-serif;font-size:small">&gt; largest input seems intuitively compe=
lling but it seems to me like</span><br style=3D"color:rgb(34,34,34);font-f=
amily:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-f=
amily:Arial,Helvetica,sans-serif;font-size:small">&gt; ordering by feerate =
of creating transaction or perhaps some</span><br style=3D"color:rgb(34,34,=
34);font-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,=
34);font-family:Arial,Helvetica,sans-serif;font-size:small">&gt; combinatio=
n of the two might provide a stronger deterrent.</span><span style=3D"color=
:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small"><br>=
</span></p><p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-h=
eight:normal;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(3=
4,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small"><br></span=
></p><p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:=
normal;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,3=
4);font-family:Arial,Helvetica,sans-serif;font-size:small">I think some com=
bination of the two can makes sense, as if the feerate</span></p><p style=
=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-f=
amily:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-famil=
y:Arial,Helvetica,sans-serif;font-size:small">is what you paid, the input v=
alue is your &quot;economically subjective&quot; liquidity</span></p><p sty=
le=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font=
-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-fam=
ily:Arial,Helvetica,sans-serif;font-size:small">risk, and as such you might=
 pay a better signature submission place for</span></p><p style=3D"margin:0=
px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;=
color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helv=
etica,sans-serif;font-size:small">a feerate contribution increase. Quite so=
phisticated for the basic dual-funding flow.</span></p><p style=3D"margin:0=
px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;=
color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helv=
etica,sans-serif;font-size:small"><br></span></p><p style=3D"margin:0px;fon=
t-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:=
rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,=
sans-serif;font-size:small">&gt; Either way the main takeaway in my opinion=
 is not that this is a</span><br style=3D"color:rgb(34,34,34);font-family:A=
rial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:A=
rial,Helvetica,sans-serif;font-size:small">&gt; serious attack, as it&#39;s=
 hard to exploit in theory and as far as I know</span><br style=3D"color:rg=
b(34,34,34);font-family:Arial,Helvetica,sans-serif"><span style=3D"color:rg=
b(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">&gt; no=
ne of the currently deployed protocols are in any way vulnerable:</span><br=
 style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><br s=
tyle=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><span s=
tyle=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-siz=
e:small">&gt; 1. dual funding supports RBF and quite amenable to reputation=
 based mitigations</span><br style=3D"color:rgb(34,34,34);font-family:Arial=
,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial=
,Helvetica,sans-serif;font-size:small">&gt; 2. in JoinMarket the taker can =
protect themselves</span><br style=3D"color:rgb(34,34,34);font-family:Arial=
,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial=
,Helvetica,sans-serif;font-size:small">&gt; 3. centralized coinjoins, despi=
te misleading claims to the contrary by</span><br style=3D"color:rgb(34,34,=
34);font-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,=
34);font-family:Arial,Helvetica,sans-serif;font-size:small">&gt; both vendo=
rs, currently strongly rely on a trusted server for many</span><br style=3D=
"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><span style=3D=
"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small=
">&gt; other aspects of the protocol and all three protocols are not</span>=
<br style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><s=
pan style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;fon=
t-size:small">&gt; currently exploitable as described (the attacker can&#39=
;t broadcast the</span><br style=3D"color:rgb(34,34,34);font-family:Arial,H=
elvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial,H=
elvetica,sans-serif;font-size:small">&gt; transaction with a witness that w=
ould otherwise be rejected by the</span><br style=3D"color:rgb(34,34,34);fo=
nt-family:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);fo=
nt-family:Arial,Helvetica,sans-serif;font-size:small">&gt; server)</span><b=
r style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><br =
style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif"><span =
style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-si=
ze:small">&gt; ... but rather that (full) RBF is required for incentive com=
patible</span><br style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,=
sans-serif"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,=
sans-serif;font-size:small">&gt; multiparty transactions (or the closest ap=
proximation of incentive</span><br style=3D"color:rgb(34,34,34);font-family=
:Arial,Helvetica,sans-serif"><span style=3D"color:rgb(34,34,34);font-family=
:Arial,Helvetica,sans-serif;font-size:small">&gt; compatibility possible ba=
rring future soft forks).</span><span style=3D"color:rgb(34,34,34);font-fam=
ily:Arial,Helvetica,sans-serif;font-size:small"><br></span></p><p style=3D"=
margin:0px;font-stretch:normal;font-size:11px;line-height:normal;font-famil=
y:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Ar=
ial,Helvetica,sans-serif;font-size:small"><br></span></p><p style=3D"margin=
:0px;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menl=
o;color:rgb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,He=
lvetica,sans-serif;font-size:small">Yep yep, all types of DoS are less conc=
erning than &quot;loss of funds&quot;</span></p><p style=3D"margin:0px;font=
-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:r=
gb(0,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,s=
ans-serif;font-size:small">severity pinning attacks, and doesn&#39;t sounds=
 to affect currently</span></p><p style=3D"margin:0px;font-stretch:normal;f=
ont-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span =
style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif;font-si=
ze:small">deployed protocols. Still concerned all those DoS once accumulate=
d</span></p><p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-=
height:normal;font-family:Menlo;color:rgb(0,0,0)"><span style=3D"color:rgb(=
34,34,34);font-family:Arial,Helvetica,sans-serif;font-size:small">might be =
a &quot;practical&quot; show-stopper, like we have with channel jamming.</s=
pan><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-ser=
if;font-size:small">=C2=A0 =C2=A0</span></p><p style=3D"margin:0px;font-str=
etch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0=
,0,0)"><span style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-=
serif;font-size:small"><br></span></p></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0ven. 10 f=C3=A9vr. 2023 =C3=
=A0=C2=A019:35, Yuval Kogman &lt;<a href=3D"mailto:nothingmuch@woobling.org=
">nothingmuch@woobling.org</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left=
:1ex">On Wed, 8 Feb 2023 at 02:56, Antoine Riard &lt;<a href=3D"mailto:anto=
ine.riard@gmail.com" target=3D"_blank">antoine.riard@gmail.com</a>&gt; wrot=
e:<br>
&gt; From what I understand, there are many inputs for the coinjoin transac=
tion, the latest signer provides an inflated witness downgrading the multi-=
party transaction feerate.<br>
<br>
Yep!<br>
<br>
&gt;=C2=A0 It doesn&#39;t sound to me a fee siphoning as occurring with loo=
se malleability [0], rather another case of transaction-relay jamming where=
 the adversary&#39;s goal is to slow down the confirmation of the transacti=
on to waste everyone timevalue.<br>
&gt;<br>
&gt; I think the issue has already been mentioned to advocate updating Core=
&#39;s mempool acceptance policy, and allows wtxid-replacement [1]. There i=
s also a description available here [2].<br>
<br>
Yep, the mechanism is basically the same as witness malleability based jamm=
ing.<br>
<br>
Apologies for not citing, I think I must have seen that before but<br>
only remembered the pinning variants, and so did not recall it at the<br>
time that I wrote this up, which I did rather hastily.<br>
<br>
However, I do think the adversary model should be broadened, as there<br>
is a potential positive externality to a party which simply wishes to<br>
get some witness data confirmed in a block while paying less than the<br>
market rate, without needing to assume time sensitive contracts in the<br>
threat model.<br>
<br>
What I had in mind was the estimated witness size messages in the dual<br>
funding proposal and felt they would create a false sense of<br>
validation, specifically in the context of an adversary interested in<br>
having their ordinal inscriptions being paid for by someone else by<br>
subverting the a priori agreed upon feerate. From my point of view<br>
this is primarily an argument for RBF by default (ideally full RBF, as<br>
rule 3 of BIP 125 imposes difficult constraints on multiparty<br>
transaction construction) in such protocols.<br>
<br>
&gt; I don&#39;t think increasing adversary costliness is that efficient as=
 there is a scaling effect (e.g the feerate of the previous transaction can=
 be used to feed N outputs for N dissociated attack contexts).<br>
<br>
Yes, that doesn&#39;t make things incentive compatible but allows the<br>
potential victims to have clearer bounds on the potential positive<br>
payoff to the adversary. I think that&#39;s mainly useful in conjunction<br=
>
constraining the order of signature submission, going from smallest to<br>
largest input seems intuitively compelling but it seems to me like<br>
ordering by feerate of creating transaction or perhaps some<br>
combination of the two might provide a stronger deterrent.<br>
<br>
Either way the main takeaway in my opinion is not that this is a<br>
serious attack, as it&#39;s hard to exploit in theory and as far as I know<=
br>
none of the currently deployed protocols are in any way vulnerable:<br>
<br>
1. dual funding supports RBF and quite amenable to reputation based mitigat=
ions<br>
2. in JoinMarket the taker can protect themselves<br>
3. centralized coinjoins, despite misleading claims to the contrary by<br>
both vendors, currently strongly rely on a trusted server for many<br>
other aspects of the protocol and all three protocols are not<br>
currently exploitable as described (the attacker can&#39;t broadcast the<br=
>
transaction with a witness that would otherwise be rejected by the<br>
server)<br>
<br>
... but rather that (full) RBF is required for incentive compatible<br>
multiparty transactions (or the closest approximation of incentive<br>
compatibility possible barring future soft forks).<br>
</blockquote></div>

--000000000000cb9bc705f4b4bebf--