path: root/e6/690d840a7b1693339c73af130311a449407656

Return-Path: <sdaftuar@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 143B1C002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 17:35:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id DD44F8141C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 17:35:43 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org DD44F8141C
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=nWgTuyek
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 zti2qPNFuoYR
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 17:35:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org B36CD81400
Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com
 [IPv6:2a00:1450:4864:20::233])
 by smtp1.osuosl.org (Postfix) with ESMTPS id B36CD81400
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 17:35:42 +0000 (UTC)
Received: by mail-lj1-x233.google.com with SMTP id b8so4348535ljf.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 27 Oct 2022 10:35:42 -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=6hLVnoLlxdF/47mHMgIfdfPfiINKy4iwzGzT25J8I6A=;
 b=nWgTuyek8Ft5aqDqACdRTGTarBhzryQ0mKeJ/uuN1ajZi+9QKvzL4hQyZgNMEhZM0M
 6r9b8dpS1Ak2mg9494UFIxq1kuLZF9BM9wP4rJR+o1jUx2vWLyLTghYSRMbroD4zRCMd
 Nc2uFZKM/1BbmFiTOofzEcACMNiQpe6vNMzXp2eFD2js+wu1UEUaGYHMeXjWAnfEYFIN
 fwHtZQzWYSWoh1/M7yMUwG6dzs3+liRmh1fUBtpBagNpw518x65Md4F6QNJeujL8gAW/
 SahyvEl7pAP3CVkP0XLk3sH97ox0r0YSeekstX4FH5vfK/zpR+7PSweLJLEGVuvk2QoX
 193Q==
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=6hLVnoLlxdF/47mHMgIfdfPfiINKy4iwzGzT25J8I6A=;
 b=s9VXFCPFFY1r0Cokbtc8i+f1yuA3l0YF5NT1qHvT9iAQUw63VKiS6rsOPSI8Di2d3n
 SYiOl7DMzMIRc0aoQGFcv4PU6L+DCpYG0DDZA3xNR+rWSfGmh35thZ7qQNbFKJGdYiN/
 Fp+ZxwcquRW8dBMwHiGRioT5ddPzIWsxlzSrCyDzbA6fCX+vY9ndNiqYi5Zb3SFgBdCl
 9vigGfI8IEB6Z4iAABDRiDJzlvLnD8YzjkwPupxvBRq2KNLuLbx1s7wUAS0MrBU8KoGH
 YWmRjP7fpMNlQAqo0Tt3kexEmehUhb7HO6M8Fq+R00A2WU5SZNmPYXyBYJ0O154YClg5
 Lriw==
X-Gm-Message-State: ACrzQf3Kbd4Jr3odga18HtQjzO3Xt1YylT3us9Sn00a8muhAsQvQ6pwr
 aWkmY0NH7hC+byXzozucFhwSIZIBnpuC8aT1SgM/ejV4
X-Google-Smtp-Source: AMsMyM4uNUPuMLxXqsSxi854fwuUMKReA/H+KRN3yOldiRQpcHNuvjkJoMp95pMmKOG1caX/M+hzyyzgbvrg0dzA2OQ=
X-Received: by 2002:a2e:9888:0:b0:277:2427:5461 with SMTP id
 b8-20020a2e9888000000b0027724275461mr3323853ljj.431.1666892139886; Thu, 27
 Oct 2022 10:35:39 -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>
In-Reply-To: <Y1q+MedepB1qUpBP@erisian.com.au>
From: Suhas Daftuar <sdaftuar@gmail.com>
Date: Thu, 27 Oct 2022 13:35:28 -0400
Message-ID: <CAFp6fsHVdyK1xROa8jgq-cZFMrrXX-uZqkoNsS-C0B5AqG4KcA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000e07d1105ec07911d"
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:35:44 -0000

--000000000000e07d1105ec07911d
Content-Type: text/plain; charset="UTF-8"

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

--000000000000e07d1105ec07911d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<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 w=
orth 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 bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-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>

--000000000000e07d1105ec07911d--