path: root/c6/90753c12cae848ca0cf9365f58e072e65fa4f6

Return-Path: <gsanders87@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3A7D3C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 19:00:26 +0000 (UTC)
Received: by mail-ej1-x633.google.com with SMTP id kt23so7307109ejc.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <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>
 <CAB3F3Du4-eQY9X93HXhEpuwfTwon+OAHU9TEakgoi+50sU-dsQ@mail.gmail.com>
In-Reply-To: <CAB3F3Du4-eQY9X93HXhEpuwfTwon+OAHU9TEakgoi+50sU-dsQ@mail.gmail.com>
From: Greg Sanders <gsanders87@gmail.com>
Date: Thu, 27 Oct 2022 15:00:13 -0400
Message-ID: <CAB3F3DuFnk3mXY9nqAZh3eAxhv1TjUqtjjS+A32EkX25V4mbWg@mail.gmail.com>
To: Suhas Daftuar <sdaftuar@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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 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 <gsanders87@gmail.com> 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

<div dir=3D"ltr">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).<di=
v><br></div><div>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.</div></div>=
<br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu=
, Oct 27, 2022 at 1:44 PM Greg Sanders &lt;<a href=3D"mailto:gsanders87@gma=
il.com">gsanders87@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr">&gt;=C2=A0For instance, the do=
uble-spend could be low-feerate 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 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.</div><div><br></div><div>&gt; Or it could=
 be higher feerate and confirm and B/C have to start all over.</div><div><b=
r></div><div>Coinjoins=C2=A0have &quot;blame rounds&quot; exactly for this.=
 Ruling out the above hole where you don&#39;t want to pay the 100kvb=C2=A0=
rule#3 penalty, you can kick the griefer out. Without replacement, you like=
ly can not.</div><div><br></div><div>&gt; 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.<div><br></div><div>Again, blame rounds solve this.</div></div><div><br>=
</div><div>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&#39;re be=
ing pinned and double-spend your input, which again looks blame-worthy).</d=
iv><div><br></div><div>Properly 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 dir=3D"ltr" class=3D"gmail_attr">On Thu, Oct 27=
, 2022 at 1:35 PM Suhas Daftuar via bitcoin-dev &lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux=
foundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-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 th=
ink it&#39;s worth commenting:=C2=A0</div><br><div class=3D"gmail_quote"><d=
iv 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:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is that tru=
e? 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>
</blockquote></div>

--000000000000f33ba105ec08c088--