Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3A7D3C002D for ; Thu, 27 Oct 2022 19:00:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 1434381444 for ; Thu, 27 Oct 2022 19:00:28 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 1434381444 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=RcehCIfe 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 smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgu6RLc7sp5v for ; Thu, 27 Oct 2022 19:00:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 98BF58142E Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by smtp1.osuosl.org (Postfix) with ESMTPS id 98BF58142E for ; Thu, 27 Oct 2022 19:00:26 +0000 (UTC) Received: by mail-ej1-x633.google.com with SMTP id kt23so7307109ejc.7 for ; Thu, 27 Oct 2022 12:00:26 -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=3Hmlo0REGhD7kpgSqZsIbdAqAWQPzmAO5Rs9HLk6kS4=; b=RcehCIfeoadZIBi2NFjNooNFvUaZ7AW0zybM2l5VSs9SFnUmoHJM/Dv73r8FxVAbFm Ih3xaWmOPsOFaMV/GWVFqBgnmIom2OE54Ft07taP1B/urEk1QBJzqUW6dt7zVCNLum9T Yr8oiVrY+sCwpymN+UWdjabc0xPOLo/d+rJrwDNkq1hACOpq3YXnoXsvwVdr1UefuuE/ DZ1mplT41OvDpa3WEujutffaA85OoEXtzjTL0KTHp0zx7G3txtfh+NcC1CRV9kx6G3rQ B73zTHoGb3Jarnt62Vn5aCpDZuPilk1q0nCnB/nw0jEoVf2S0EQSwAefJqhkWIZqiZCt rEnQ== 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=3Hmlo0REGhD7kpgSqZsIbdAqAWQPzmAO5Rs9HLk6kS4=; b=QCQ1ATC36AVmkcXD8SjBra8JX/O3Ef4J8CHJhZigypIfnW4McSWgWOzIecgNJMr7v/ 7me86DRInnKpAOgcB+oAH8+D1Pg5DV+YGA3NJ/M7oWnA0AjFUCTViIJYsk7PPlfUBZba AWkC/mRcaTG4DGkXggZxTD+QcuHHnjR5XNY3h5EezPkeQVHqbkiVgszozEBg6tgCUqK1 dCD9cfzaSujWE5C2vFMdSIgzoawAiN26ckt09exNwqdU62awuCdVqWff4xuwU2XifvcK x2tF/u+jm5mCGSzCo4ucYE5UVjAZoe2AWKcb+UM7vEdpuGMsQdcbcPfXAM5FTEDBsfFp QtIA== X-Gm-Message-State: ACrzQf0V3KE7Eo1zZ4FYbKzgJKGbxoYFqxYdBZYLHycHFdSvj939hysh sq4ASe6URo32Eiovi3f/zj1BNFVh0glyOLjRZoo= X-Google-Smtp-Source: AMsMyM7gVEuFqSC4f1I/4o6akYKfUqbd+yn9gwJsB5q1l9X8MAs3v74Bd8y3PYrSlVX/fJAoJcRk2jR3LUR4S76jTeI= X-Received: by 2002:a17:907:2e0b:b0:7a7:d37e:4650 with SMTP id ig11-20020a1709072e0b00b007a7d37e4650mr20920916ejc.261.1666897224611; Thu, 27 Oct 2022 12:00:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Thu, 27 Oct 2022 15:00:13 -0400 Message-ID: To: Suhas Daftuar , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000f33ba105ec08c088" Subject: Re: [bitcoin-dev] On mempool policy consistency 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: Thu, 27 Oct 2022 19:00:28 -0000 --000000000000f33ba105ec08c088 Content-Type: text/plain; charset="UTF-8" During off-channel discussion, Suhas made a great point that even with fullrbf, you can get stuck by bip125 rule#5 pinning if an adversary controls a number of inputs(4 with default mempool settings). Implication being, while we can mitigate rule#3 damage potentially with fullrbf, we cannot actually make promises about mempool entry beyond quite small transaction sizes. Adversary has to make 100 transactions, 4 chains of 25, but it achieves the original pin. On Thu, Oct 27, 2022 at 1:44 PM Greg Sanders wrote: > > For instance, the double-spend could be low-feerate and large, and > effectively pin any attempt to replace it. > > Yes, this is the biggest hole left. You *could* replace it with RBF when > before you simply could not, so perhaps the pinning door is slightly > smaller in scenarios where going feerates are significantly higher than min. > > > Or it could be higher feerate and confirm and B/C have to start all over. > > Coinjoins have "blame rounds" exactly for this. Ruling out the above hole > where you don't want to pay the 100kvb rule#3 penalty, you can kick the > griefer out. Without replacement, you likely can not. > > > Or, A could stall things in the signing phase and B/C have to figure out > when to give up on the channel with A. > > Again, blame rounds solve this. > > So to recap, it makes it *possible* to over-bid your griefer, vs simply > not able to and have funds tied up for weeks(or guess you're being pinned > and double-spend your input, which again looks blame-worthy). > > Properly replacing rule#3 would give these protocols higher assurances, > but this is where we're at now. > > On Thu, Oct 27, 2022 at 1:35 PM Suhas Daftuar via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I have more to say on this broader topic, but since you've brought up >> this particular example I think it's worth commenting: >> >> On Thu, Oct 27, 2022 at 1:23 PM Anthony Towns via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> Is that true? Antoine claims [1] that opt-in RBF isn't enough to avoid >>> a DoS issue when utxos are jointly funded by untrusting partners, and, >>> aiui, that's the main motivation for addressing this now. >>> >>> [1] >>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html >>> >>> The scenario he describes is: A, B, C create a tx: >>> >>> inputs: A1, B1, C1 [opts in to RBF] >>> fees: normal >>> outputs: >>> [lightning channel, DLC, etc, who knows] >>> >>> they all analyse the tx, and agree it looks great; however just before >>> publishing it, A spams the network with an alternative tx, double >>> spending her input: >>> >>> inputs: A1 [does not opt in to RBF] >>> fees: low >>> outputs: A >>> >>> If A gets the timing right, that's bad for B and C because they've >>> populated their mempool with the 1st transaction, while everyone else >>> sees the 2nd one instead; and neither tx will replace the other. B and >>> C can't know that they should just cancel their transaction, eg: >>> >>> inputs: B1, C1 [opts in to RBF] >>> fees: 50% above normal >>> outputs: >>> [smaller channel, refund, whatever] >>> >>> and might instead waste time trying to fee bump the tx to get it mined, >>> or similar. >>> >>> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to >>> solve that problem if they have only opt-in RBF available? >>> >> >> I think this is not a real example of a DoS vector that is available >> because we support non-rbf signaling transactions. Even in a world where >> all transactions are replaceable, person A could double-spend their input >> in a way that is annoying for B and C. For instance, the double-spend >> could be low-feerate and large, and effectively pin any attempt to replace >> it. Or it could be higher feerate and confirm and B/C have to start all >> over. Or, A could stall things in the signing phase and B/C have to figure >> out when to give up on the channel with A. >> >> So I find this example to be unconvincing. Are there any other examples >> where having a non-replacement policy for some transactions causes problems >> for protocols people are trying to build? >> >> Thanks, >> Suhas >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > --000000000000f33ba105ec08c088 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
During off-channel discussion, Suhas made a great point th= at even with fullrbf, you=C2=A0can get stuck by bip125 rule#5 pinning if an= adversary controls a number of inputs(4 with default mempool settings).
Implication=C2=A0being, while we can mitigate rule#3 damag= e potentially with fullrbf, we cannot actually make promises about mempool = entry beyond quite small transaction sizes. Adversary has to make 100 trans= actions, 4 chains of 25, but it achieves the original=C2=A0pin.
=
On Thu= , Oct 27, 2022 at 1:44 PM Greg Sanders <gsanders87@gmail.com> wrote:
>=C2=A0For instance, the do= uble-spend could be low-feerate and large, and effectively pin any attempt = to replace it.

Yes, this is the biggest hole left. You *= could* replace it with RBF when before you simply could not, so perhaps=C2= =A0the pinning door is slightly smaller in scenarios where going feerates a= re significantly higher than min.

> Or it could= be higher feerate and confirm and B/C have to start all over.
Coinjoins=C2=A0have "blame rounds" exactly for this.= Ruling out the above hole where you don't want to pay the 100kvb=C2=A0= rule#3 penalty, you can kick the griefer out. Without replacement, you like= ly can not.

> Or, A could stall things in the s= igning phase and B/C have to figure out when to give up on the channel with= A.

Again, blame rounds solve this.

=
So to recap, it makes it *possible* to over-bid your griefer, vs= simply not able to and have funds tied up for weeks(or guess you're be= ing pinned and double-spend your input, which again looks blame-worthy).

Properly replacing rule#3 would give these protocols= higher assurances, but this is where we're at now.

On Thu, Oct 27= , 2022 at 1:35 PM Suhas Daftuar via bitcoin-dev <bitcoin-dev@lists.linux= foundation.org> wrote:
I have more to say on this = broader topic, but since you've brought up this particular example I th= ink it's worth commenting:=C2=A0

On Thu, Oct 27, 2022 at 1:23 PM Anthony= Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wr= ote:
Is that tru= e? Antoine claims [1] that opt-in RBF isn't enough to avoid
a DoS issue when utxos are jointly funded by untrusting partners, and,
aiui, that's the main motivation for addressing this now.

[1] https://lists.linu= xfoundation.org/pipermail/lightning-dev/2021-May/003033.html

The scenario he describes is: A, B, C create a tx:

=C2=A0 inputs: A1, B1, C1 [opts in to RBF]
=C2=A0 fees: normal
=C2=A0 outputs:
=C2=A0 =C2=A0 [lightning channel, DLC, etc, who knows]

they all analyse the tx, and agree it looks great; however just before
publishing it, A spams the network with an alternative tx, double
spending her input:

=C2=A0 inputs: A1 [does not opt in to RBF]
=C2=A0 fees: low
=C2=A0 outputs: A

If A gets the timing right, that's bad for B and C because they've<= br> populated their mempool with the 1st transaction, while everyone else
sees the 2nd one instead; and neither tx will replace the other. B and
C can't know that they should just cancel their transaction, eg:

=C2=A0 inputs: B1, C1 [opts in to RBF]
=C2=A0 fees: 50% above normal
=C2=A0 outputs:
=C2=A0 =C2=A0 [smaller channel, refund, whatever]

and might instead waste time trying to fee bump the tx to get it mined,
or similar.

What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
solve that problem if they have only opt-in RBF available?
=

I think this is not a real example of a DoS vector that= is available because we support non-rbf signaling transactions. Even in a = world where all transactions are replaceable, person A could double-spend t= heir input in a way that is annoying for B and C.=C2=A0 For instance, the d= ouble-spend could be low-feerate and large, and effectively pin any attempt= to replace it.=C2=A0 Or it could be higher feerate and confirm and B/C hav= e to start all over.=C2=A0 Or, A could stall things in the signing phase an= d B/C have to figure out when to give up on the channel with A.
<= br>
So I find this example to be unconvincing.=C2=A0 Are there an= y other examples where having a non-replacement policy for some transaction= s causes problems for protocols people are trying to build?

<= /div>
Thanks,
Suhas
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000f33ba105ec08c088--