path: root/e9/a5a9b2eb72af0a9a6b1d690fb58d37fbf3f7cf

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&#39;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 &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitc=
oin-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">On Tue, Nov 01, 2022 at 10:21:59PM -0400, =
Antoine Riard via bitcoin-dev wrote:<br>
&gt; Hi list,<br>
&gt; <br>
&gt; Reading Suhas&#39;s post on mempool policy consistency rules, and the =
grounded<br>
&gt; suggestion that as protocol developers we should work on special polic=
y<br>
&gt; rules to support each reasonable use case on the network rather to arb=
iter<br>
&gt; between class of use-cases in the design of an<br>
&gt; unified set of rules, reminded me there is another solution to solve<b=
r>
&gt; multi-party funding pinning rather than wide deployment of fullrbf. Th=
is<br>
&gt; was communicated to me a while back, and it was originally dismissed<b=
r>
&gt; because of the privacy trade-offs (and potential slight fees overhead<=
br>
&gt; cost). However, if widely adopted, they might sound acceptable to<br>
&gt; 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=
&#39;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> &#39;peter&#39;[:-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--