Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 06345C002D for ; Thu, 27 Oct 2022 17:44:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id AADB64026A for ; Thu, 27 Oct 2022 17:44:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org AADB64026A Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=g58qRZQh 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 smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oHBeWdRwFtis for ; Thu, 27 Oct 2022 17:44:56 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 551CC400C4 Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) by smtp2.osuosl.org (Postfix) with ESMTPS id 551CC400C4 for ; Thu, 27 Oct 2022 17:44:56 +0000 (UTC) Received: by mail-ed1-x529.google.com with SMTP id m15so4032076edb.13 for ; Thu, 27 Oct 2022 10:44:56 -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=l+l43rE+C4bsbFwrmUHe4wZWp+R3eKQOWmKatQNGO7U=; b=g58qRZQh2uf+Wkb3sZXM6fcbU1muZKENe+qG1s4rgJIDffGrpNWhskaT9ElA9ibXgo UdFp6KaeumxEKNl8bTBuhQYeX/KHO4y8n1fqZr2/6/j7dui6MYwfL0rmNnaWlgk57VIh vVz1mYl0a3c83gSWRi008IcFG/HHWWqmrRY/QTNivElGSSnLPzRztY+A6sjLbX28FRHv DugMyKIxKUGVGxq3oVf+uh4uJ+QzhsHGIgWFYjk3DI3leBn9YgGUfZjvVCObfQaBebzZ Su4KgXVwQcMAOG9kzk/YUBc0y+LMrvSdh2bFkhkns1mze/59Qf06S+SpXfc6Y6gTfKhw PFwg== 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=l+l43rE+C4bsbFwrmUHe4wZWp+R3eKQOWmKatQNGO7U=; b=rx1hC1GSTuHFQd1+hC4H1LKoZi6z4TgN1U/a9whkl0gBSsn5KXIdtOEPNHJLkiJHr5 ucH8ySZ0HrH744WKYYkzLReLP3nnSf2DJUhgf/rvTbh7F+KssmSsq6NEeS4JY8Ywieap ywy47VihxXS4u7ikSCM7K581Bderpy1icJ2f5kDQtrZM7mB2vBkli71zfkNDmNhsBG/0 H92QCI/7YBoy+EtoJsD1pSOElqp+PILnnd+a+IxKlOeO48zk6vNr9E2tR0i/Qkgz6Y2+ wV1KL3qpaA8MxG2wUZummjHbfa8M4IWI2kwoD9zIiDMJtpJvzpLeINIn4WV03nNN9egI EwQQ== X-Gm-Message-State: ACrzQf0qwe5WpIJATNkSMMyjpn6FSPxBOQGXTbKZPg9kejQGVwEQ7o2L 0G7Z6oaRRz+nnBrJ0eADk+ymji4+7XD3TM6vq1gAkWU/hs0= X-Google-Smtp-Source: AMsMyM7ZjPzjQuca8sDTzVlakQvD1DknZ2IqP3vn+fYs2aAmoByrj4fc45seKtneBLySB9yxlqbDD7K7c08agUOH1V0= X-Received: by 2002:a05:6402:370c:b0:453:9fab:1b53 with SMTP id ek12-20020a056402370c00b004539fab1b53mr48094644edb.28.1666892694265; Thu, 27 Oct 2022 10:44:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Sanders Date: Thu, 27 Oct 2022 13:44:43 -0400 Message-ID: To: Suhas Daftuar , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000eba51505ec07b290" 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 17:44:58 -0000 --000000000000eba51505ec07b290 Content-Type: text/plain; charset="UTF-8" > 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 > --000000000000eba51505ec07b290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0For instance, the double-spend could be low-feer= ate and large, and effectively pin any attempt to replace it.

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

> Or it could be higher feerate and confir= m and B/C have to start all over.

Coinjoins=C2=A0h= ave "blame rounds" exactly for this. Ruling out the above hole wh= ere you don't want to pay the 100kvb=C2=A0rule#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 ma= kes 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 y= our input, which again looks blame-worthy).

Proper= ly 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 Daftu= ar 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:=C2=A0

<= div class=3D"gmail_quote">
On Thu, Oct= 27, 2022 at 1:23 PM Anthony Towns via bitcoin-dev <bitcoin-dev@lists.li= nuxfoundation.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.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
--000000000000eba51505ec07b290--