Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7560FC002B for ; 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 ; 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 ; 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 ; Wed, 15 Feb 2023 03:33:36 +0000 (UTC) Received: by mail-il1-x131.google.com with SMTP id 18so1021788ilg.3 for ; 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: In-Reply-To: From: Antoine Riard Date: Wed, 15 Feb 2023 03:33:24 +0000 Message-ID: To: Yuval Kogman Content-Type: multipart/alternative; boundary="000000000000cb9bc705f4b4bebf" X-Mailman-Approved-At: Wed, 15 Feb 2023 08:49:53 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 a =C3=A9crit : > On Wed, 8 Feb 2023 at 02:56, Antoine Riard > 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

>= Apologies for not citing, I think I must have seen that before but<= br style=3D"color:rgb(34,34,34);font-family:Arial,Helvetica,sans-serif">> only remembered the pinning variants, and so did not reca= ll it at the
> time that I wrote this up, which I di= d 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 sensi= tive contracts in the
> threat model.

=


Please no apologies - Messa= ge matters more than the messenger in

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

potential negative=C2=A0externality in the context of time-sensitive contract, e.g

for a DLC wit= h=C2=A0short-term maturity you can delay confirmatio= n of the funding

transaction=C2=A0in function of the event outc= ome 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 si= ze messages in the dual
> funding proposal and felt = they would create a false sense of
> validation, spe= cifically 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 R= BF by default (ideally full RBF, as
> rule 3 of BIP = 125 imposes difficult constraints on multiparty
> tr= ansaction construction) in such protocols.


<= p style=3D"margin:0px;font-stretch:normal;font-size:11px;line-height:normal= ;font-family:Menlo;color:rgb(0,0,0)">We could have miniscri= pt embedded in the backend of a Lightning

implementation, to reject any malleable witn= ess (maybe with some tolerance bounds ?),

to restrain a counterparty downgrading a pos= teriori its feerate contribution.

Full rbf effectively would prevent timevalue DoS inf= licted to the most-utxo-value

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

changes something, the witness downgrading counterparty benef= its from

a = feerate discount, not lack of confirmation.


> Yes, that doesn't make things incentive= compatible but allows the
> potential victims to ha= ve 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 compe= lling but it seems to me like
> ordering by feerate = of creating transaction or perhaps some
> combinatio= n of the two might provide a stronger deterrent.
=


I think some com= bination of the two can makes sense, as if the feerate

is what you paid, the input v= alue is your "economically subjective" liquidity

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

a feerate contribution increase. Quite so= phisticated 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
> no= ne 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, despi= te misleading claims to the contrary by
> both vendo= rs, currently strongly rely on a trusted server for many
> currently exploitable as described (the attacker can'= ;t broadcast the
> transaction with a witness that w= ould otherwise be rejected by the
> server)
> ... but rather that (full) RBF is required for incentive com= patible
> multiparty transactions (or the closest ap= proximation of incentive
> compatibility possible ba= rring future soft forks).


Yep yep, all types of DoS are less conc= erning than "loss of funds"

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

deployed protocols. Still concerned all those DoS once accumulate= d

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



=
Le=C2=A0ven. 10 f=C3=A9vr. 2023 =C3= =A0=C2=A019:35, Yuval Kogman <nothingmuch@woobling.org> a =C3=A9crit=C2=A0:
On Wed, 8 Feb 2023 at 02:56, Antoine Riard <antoine.riard@gmail.com> wrot= e:
> 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.

Yep!

>=C2=A0 It doesn't sound to me a fee siphoning as occurring with loo= se malleability [0], rather another case of transaction-relay jamming where= the adversary's goal is to slow down the confirmation of the transacti= on 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 i= s also a description available here [2].

Yep, the mechanism is basically the same as witness malleability based jamm= ing.

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

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<= br> none of the currently deployed protocols are in any way vulnerable:

1. dual funding supports RBF and quite amenable to reputation based mitigat= ions
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--