path: root/57/0babee40991a8c281f39ad5c017eb522c1ceaa

Return-Path: <gsanders87@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 06345C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 17:44:56 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id m15so4032076edb.13
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <mailman.38435.1666828344.956.bitcoin-dev@lists.linuxfoundation.org>
 <CAHTn92wfjTCF5UtbjezbEYWTUQ7t6FNZu1ow0pirJXGFoXJxCA@mail.gmail.com>
 <Y1q+MedepB1qUpBP@erisian.com.au>
 <CAFp6fsHVdyK1xROa8jgq-cZFMrrXX-uZqkoNsS-C0B5AqG4KcA@mail.gmail.com>
In-Reply-To: <CAFp6fsHVdyK1xROa8jgq-cZFMrrXX-uZqkoNsS-C0B5AqG4KcA@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 27 Oct 2022 13:44:43 -0400
Message-ID: <CAB3F3Du4-eQY9X93HXhEpuwfTwon+OAHU9TEakgoi+50sU-dsQ@mail.gmail.com>
To: Suhas Daftuar <sdaftuar@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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

<div dir=3D"ltr">&gt;=C2=A0For instance, the double-spend could be low-feer=
ate and large, and effectively pin any attempt to replace it.<div><br></div=
><div>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.</div><div><br></div><div>&gt; Or it could be higher feerate and confir=
m and B/C have to start all over.</div><div><br></div><div>Coinjoins=C2=A0h=
ave &quot;blame rounds&quot; exactly for this. Ruling out the above hole wh=
ere you don&#39;t want to pay the 100kvb=C2=A0rule#3 penalty, you can kick =
the griefer out. Without replacement, you likely can not.</div><div><br></d=
iv><div>&gt; 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.<div><br></div><div>Again,=
 blame rounds solve this.</div></div><div><br></div><div>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&#39;re being pinned and double-spend y=
our input, which again looks blame-worthy).</div><div><br></div><div>Proper=
ly replacing rule#3 would give these protocols higher assurances, but this =
is where we&#39;re at now.</div></div><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr" class=3D"gmail_attr">On Thu, Oct 27, 2022 at 1:35 PM Suhas Daftu=
ar via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockqu=
ote 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"ltr"><div dir=3D"ltr"=
>I have more to say on this broader topic, but since you&#39;ve brought up =
this particular example I think it&#39;s worth commenting:=C2=A0</div><br><=
div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Oct=
 27, 2022 at 1:23 PM Anthony Towns via bitcoin-dev &lt;<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li=
nuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">Is that true? Antoine claims [1] that opt-in RBF isn&#39;t=
 enough to avoid<br>
a DoS issue when utxos are jointly funded by untrusting partners, and,<br>
aiui, that&#39;s the main motivation for addressing this now.<br>
<br>
[1] <a href=3D"https://lists.linuxfoundation.org/pipermail/lightning-dev/20=
21-May/003033.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linu=
xfoundation.org/pipermail/lightning-dev/2021-May/003033.html</a><br>
<br>
The scenario he describes is: A, B, C create a tx:<br>
<br>
=C2=A0 inputs: A1, B1, C1 [opts in to RBF]<br>
=C2=A0 fees: normal<br>
=C2=A0 outputs:<br>
=C2=A0 =C2=A0 [lightning channel, DLC, etc, who knows]<br>
<br>
they all analyse the tx, and agree it looks great; however just before<br>
publishing it, A spams the network with an alternative tx, double<br>
spending her input:<br>
<br>
=C2=A0 inputs: A1 [does not opt in to RBF]<br>
=C2=A0 fees: low<br>
=C2=A0 outputs: A<br>
<br>
If A gets the timing right, that&#39;s bad for B and C because they&#39;ve<=
br>
populated their mempool with the 1st transaction, while everyone else<br>
sees the 2nd one instead; and neither tx will replace the other. B and<br>
C can&#39;t know that they should just cancel their transaction, eg:<br>
<br>
=C2=A0 inputs: B1, C1 [opts in to RBF]<br>
=C2=A0 fees: 50% above normal<br>
=C2=A0 outputs:<br>
=C2=A0 =C2=A0 [smaller channel, refund, whatever]<br>
<br>
and might instead waste time trying to fee bump the tx to get it mined,<br>
or similar.<br>
<br>
What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to<br>
solve that problem if they have only opt-in RBF available?<br></blockquote>=
<div><br></div><div>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.</div><div><=
br></div><div>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><div><br><=
/div><div>Thanks,</div><div>Suhas</div></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>

--000000000000eba51505ec07b290--