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
Precedence: list

--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--