diff options
| author | Greg Sanders <gsanders87@gmail.com> | 2022-10-27 15:00:13 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-10-27 19:00:28 +0000 |
| commit | 40832fa6cd04a32783a60eec154452912d730bd6 (patch) | |
| tree | 1e27af86dc666a80f2bb300d176b36442afa0189 | |
| parent | 581bdb01f6f3dfd747bd906c9bb83d0d4b66c96f (diff) | |
| download | pi-bitcoindev-40832fa6cd04a32783a60eec154452912d730bd6.tar.gz pi-bitcoindev-40832fa6cd04a32783a60eec154452912d730bd6.zip | |
Re: [bitcoin-dev] On mempool policy consistency
| -rw-r--r-- | c6/90753c12cae848ca0cf9365f58e072e65fa4f6 | 310 |
1 files changed, 310 insertions, 0 deletions
diff --git a/c6/90753c12cae848ca0cf9365f58e072e65fa4f6 b/c6/90753c12cae848ca0cf9365f58e072e65fa4f6 new file mode 100644 index 000000000..efb230b7d --- /dev/null +++ b/c6/90753c12cae848ca0cf9365f58e072e65fa4f6 @@ -0,0 +1,310 @@ +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 <<a href=3D"mailto:gsanders87@gma= +il.com">gsanders87@gmail.com</a>> 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">>=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>> 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 "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.</div><div><br></div><div>> 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'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'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 <<a href=3D"mailto:bitco= +in-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linux= +foundation.org</a>> 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've brought up this particular example I th= +ink it'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 <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat= +ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> 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't enough to avoid<br> +a DoS issue when utxos are jointly funded by untrusting partners, and,<br> +aiui, that'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's bad for B and C because they'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'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-- + |