diff options
| author | Greg Sanders <gsanders87@gmail.com> | 2022-11-02 10:19:00 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-11-02 14:19:15 +0000 |
| commit | 928db78057825a88317e1d6311dc377ca423ad9f (patch) | |
| tree | 97be74815d3f6e74a509337fb2745301e4dc44ba | |
| parent | 67fda118068e5dcc0efa4259ba5be255da891d69 (diff) | |
| download | pi-bitcoindev-928db78057825a88317e1d6311dc377ca423ad9f.tar.gz pi-bitcoindev-928db78057825a88317e1d6311dc377ca423ad9f.zip | |
Re: [bitcoin-dev] Solving Multi-Party Flows Pinning with Opt-in Full-RBF Spent-nVersion Signaling
| -rw-r--r-- | e9/a5a9b2eb72af0a9a6b1d690fb58d37fbf3f7cf | 255 |
1 files changed, 255 insertions, 0 deletions
diff --git a/e9/a5a9b2eb72af0a9a6b1d690fb58d37fbf3f7cf b/e9/a5a9b2eb72af0a9a6b1d690fb58d37fbf3f7cf new file mode 100644 index 000000000..1f48ddf9b --- /dev/null +++ b/e9/a5a9b2eb72af0a9a6b1d690fb58d37fbf3f7cf @@ -0,0 +1,255 @@ +Return-Path: <gsanders87@gmail.com> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 981C5C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 2 Nov 2022 14:19:15 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp4.osuosl.org (Postfix) with ESMTP id 7849241674 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 2 Nov 2022 14:19:15 +0000 (UTC) +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 7849241674 +Authentication-Results: smtp4.osuosl.org; + dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com + header.a=rsa-sha256 header.s=20210112 header.b=bP8Qff+j +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 smtp4.osuosl.org ([127.0.0.1]) + by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id H1BzvUbW-GoR + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 2 Nov 2022 14:19:14 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org DDAD141673 +Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com + [IPv6:2a00:1450:4864:20::634]) + by smtp4.osuosl.org (Postfix) with ESMTPS id DDAD141673 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 2 Nov 2022 14:19:13 +0000 (UTC) +Received: by mail-ej1-x634.google.com with SMTP id f5so24157331ejc.5 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 02 Nov 2022 07:19:13 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=cc:to:subject:message-id:date:from:in-reply-to:references + :mime-version:from:to:cc:subject:date:message-id:reply-to; + bh=7/B37JUO2RCtrmVip013wmaA5biGYxccHq+gl3vrP7A=; + b=bP8Qff+j7rF+vdY+ZQULlfbU2OHJ6Y8sf/WZrIKpdcFxJXUPsxK224i+epsfXoVuMy + HSfxmztSjP2pTJnvYvx37Mnrp5GbksrHDzv5kz4TkOllJ87xwfo++mM9w99OKDCjmUA1 + Rnj/tYkbUWsksDqU46BwJRjhtl9l2Yry7NkeuGEvqcEf3+NprlBXk2gTjpfMepBh7z8c + u+VXnMvM7r2Rf3a9Dl0I2tGTWT1l20lttsuFDmkYMMochcuR6/+iwgGXD0Vc6whyMnWQ + wei0NK17QrHoFH9daPHtakIKzz7YYIfLaLk1gy3hX398sRtumLZqcFFOsuNHTax1xf1M + sAlA== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=cc: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=7/B37JUO2RCtrmVip013wmaA5biGYxccHq+gl3vrP7A=; + b=TOpO5uwxKz3DPCQHTnk81XBhMj+R5H9x2YoQqTYto61s2+P4fIimxbpLPZNgk/hlu+ + c7JQhY+MW/GiLUpu1rvCkb3h+sT8YZ56Iwv3hcr2DuE11ipBnYmW+Wv1Ir9C3ebG5K8j + eVJDl6gRtRAdpaq9zFq8n87Z362VxZnloWBaSU2siTox9cw4GhEWq/fQi/0EA1NPT5l3 + mJmHn6vFJ844eM5B89tZ2lJEM2x4dVcJQ44HNNsn4qquZHmu03YMqKASQRJksAdx0j4M + xd7k/8HI51v4iNy6Su4hbEueJHsPvPxr/4isWmvR8zTFz12+beEocD3bYUSdLCxOPaz/ + 0WEw== +X-Gm-Message-State: ACrzQf0hJfuaOUyxJ/2gk2n/5WKn6fc2ZqKRYBmNUHmSLDbbyNZV1a6o + J3cuVnWjD6qwoFMFjk4h9m9FKPIDeCNoJWq7O0Q= +X-Google-Smtp-Source: AMsMyM7cOK5jvY1DVxO4wCvCrLeSeuRqomc2xPmTOEgXPy2NYBBUDuqyOvqsBcBeIMAPRMvKw+YE3skV2w93iZOm27Q= +X-Received: by 2002:a17:906:9414:b0:7ad:bde1:3ccf with SMTP id + q20-20020a170906941400b007adbde13ccfmr20258742ejx.543.1667398752009; Wed, 02 + Nov 2022 07:19:12 -0700 (PDT) +MIME-Version: 1.0 +References: <CALZpt+GZAd-vYMzUMicg0c9OyyWExtT5EH61Hms6NNOM19ddZA@mail.gmail.com> + <Y2J40/Cd40fUlFjj@petertodd.org> +In-Reply-To: <Y2J40/Cd40fUlFjj@petertodd.org> +From: Greg Sanders <gsanders87@gmail.com> +Date: Wed, 2 Nov 2022 10:19:00 -0400 +Message-ID: <CAB3F3DsA3kNutwXGwamyyEgJN65rJt-0ks-ytuXP7jwjsjr8ug@mail.gmail.com> +To: Peter Todd <pete@petertodd.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Content-Type: multipart/alternative; boundary="00000000000050026005ec7d8637" +Subject: Re: [bitcoin-dev] Solving Multi-Party Flows Pinning with Opt-in + Full-RBF Spent-nVersion Signaling +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: Wed, 02 Nov 2022 14:19:15 -0000 + +--00000000000050026005ec7d8637 +Content-Type: text/plain; charset="UTF-8" + +Sorry, I forgot one point which is pertinent to this conversation. + +*Even with* fullrbf-everywhere and V3, pinning via rule#3 and rule#5 are +still an issue in coinjoin scenarios. + +Each coinjoin adversary can double-spend their coin to either full package +weight(101kvb), +or give 24 descendants, which means you quickly pay out the nose in rule#3 +or are excluded +from RBFing it if you have 4+ greifers in your coinjoin violating rule#5. + +If we instead narrowed this policy to marking a transaction output as +opt-in to V3, it gets a bit more interesting. *Unfortunately, +double-spending counterparties can still cause rule#3 pain, one 100kvb +package of junk per peer,* but rule#5 violations is at least contained to +coinjoins with ~50 peers(assuming two transactions booted per input +double-spent, which would be the V3 max bumped per input). + +It's still worth exploring, but very speculatively. + +Greg + +On Wed, Nov 2, 2022 at 10:04 AM Peter Todd via bitcoin-dev < +bitcoin-dev@lists.linuxfoundation.org> wrote: + +> On Tue, Nov 01, 2022 at 10:21:59PM -0400, Antoine Riard via bitcoin-dev +> wrote: +> > Hi list, +> > +> > Reading Suhas's post on mempool policy consistency rules, and the +> grounded +> > suggestion that as protocol developers we should work on special policy +> > rules to support each reasonable use case on the network rather to +> arbiter +> > between class of use-cases in the design of an +> > unified set of rules, reminded me there is another solution to solve +> > multi-party funding pinning rather than wide deployment of fullrbf. This +> > was communicated to me a while back, and it was originally dismissed +> > because of the privacy trade-offs (and potential slight fees overhead +> > cost). However, if widely adopted, they might sound acceptable to +> > contracting protocol developers and operators. +> +> Strong NACK. +> +> Zeroconf is, at best, a very marginal usecase. The only services that have +> spoken up in support of it are Bitrefill and Muun, and the latter says +> they're +> working to get rid of their vulnerability to it. People attempting to make +> it +> secure have repeatedly done sybil attacks against the network in attempts +> to +> measure transaction propagation. And of course, if transaction fees and +> full +> mempools are in our near future - as is widely expected - mempool +> consistency +> will even further diminish making zeroconf even harder to achieve. +> +> Incurring a bunch of engineering costs and harming privacy for the sake of +> continuing this nonsense is ridiculous. +> +> If anything, we should be moving to full-RBF so we can undo the privacy +> cost +> that is opt-in-RBF: right now 30% of transactions are having to harm their +> privacy by signalling support for it. Full-RBF will allow that wallet +> distinguisher to be eliminated. +> +> -- +> https://petertodd.org 'peter'[:-1]@petertodd.org +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +> + +--00000000000050026005ec7d8637 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Sorry, I forgot one point which is pertinent to this conve= +rsation.<div><br></div><div>*Even with* fullrbf-everywhere and V3, pinning = +via rule#3 and rule#5 are still an issue in coinjoin scenarios.=C2=A0</div>= +<div><br></div><div>Each coinjoin adversary can double-spend their coin to = +either full package weight(101kvb),</div><div>or give 24 descendants, which= + means you quickly pay out the nose in rule#3 or are excluded</div><div>fro= +m RBFing it if you have 4+ greifers=C2=A0in your coinjoin violating rule#5.= +</div><div><br></div><div>If we instead narrowed this policy to marking a t= +ransaction output as opt-in to V3, it gets a bit more interesting. <b>Unfor= +tunately, double-spending counterparties can still cause rule#3 pain, one 1= +00kvb package of junk per peer,</b> but rule#5 violations is at least conta= +ined to coinjoins with ~50 peers(assuming two transactions booted per input= + double-spent, which would be the V3 max bumped per input).</div><div><br><= +/div><div>It's still worth exploring, but very speculatively.</div><div= +><br></div><div>Greg</div></div><br><div class=3D"gmail_quote"><div dir=3D"= +ltr" class=3D"gmail_attr">On Wed, Nov 2, 2022 at 10:04 AM Peter Todd via bi= +tcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc= +oin-dev@lists.linuxfoundation.org</a>> 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">On Tue, Nov 01, 2022 at 10:21:59PM -0400, = +Antoine Riard via bitcoin-dev wrote:<br> +> Hi list,<br> +> <br> +> Reading Suhas's post on mempool policy consistency rules, and the = +grounded<br> +> suggestion that as protocol developers we should work on special polic= +y<br> +> rules to support each reasonable use case on the network rather to arb= +iter<br> +> between class of use-cases in the design of an<br> +> unified set of rules, reminded me there is another solution to solve<b= +r> +> multi-party funding pinning rather than wide deployment of fullrbf. Th= +is<br> +> was communicated to me a while back, and it was originally dismissed<b= +r> +> because of the privacy trade-offs (and potential slight fees overhead<= +br> +> cost). However, if widely adopted, they might sound acceptable to<br> +> contracting protocol developers and operators.<br> +<br> +Strong NACK.<br> +<br> +Zeroconf is, at best, a very marginal usecase. The only services that have<= +br> +spoken up in support of it are Bitrefill and Muun, and the latter says they= +'re<br> +working to get rid of their vulnerability to it. People attempting to make = +it<br> +secure have repeatedly done sybil attacks against the network in attempts t= +o<br> +measure transaction propagation. And of course, if transaction fees and ful= +l<br> +mempools are in our near future - as is widely expected - mempool consisten= +cy<br> +will even further diminish making zeroconf even harder to achieve.<br> +<br> +Incurring a bunch of engineering costs and harming privacy for the sake of<= +br> +continuing this nonsense is ridiculous.<br> +<br> +If anything, we should be moving to full-RBF so we can undo the privacy cos= +t<br> +that is opt-in-RBF: right now 30% of transactions are having to harm their<= +br> +privacy by signalling support for it. Full-RBF will allow that wallet<br> +distinguisher to be eliminated.<br> +<br> +-- <br> +<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http= +s://petertodd.org</a> 'peter'[:-1]@<a href=3D"http://petertodd.org"= + rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br> +_______________________________________________<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> + +--00000000000050026005ec7d8637-- + |