MIME-Version: 1.0
References: <CAD5xwhi6+Q-UX2xVnD4TE9uEbe-omQ748tpJJpYdrMNnG6D5vA@mail.gmail.com>
 <20200919133716.d5ofags2tprlvpqm@ganymede>
In-Reply-To: <20200919133716.d5ofags2tprlvpqm@ganymede>
From: nopara73 <adam.ficsor73@gmail.com>
Date: Sat, 19 Sep 2020 17:01:07 +0200
Message-ID: <CAEPKjge4pMYg7MBnApV0Rtn88LSM8i6kYHAKeaR8o-dSxfREAQ@mail.gmail.com>
To: "David A. Harding" <dave@dtrt.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c04f7605afabe364"
Subject: Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive
 TXID Dependencies for Fee Sponsoring
Precedence: list

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

Wouldn't this enable a passive adversary listening the mempool to associate
unrelated TXO clusters to the same user?

On Sat, Sep 19, 2020, 15:38 David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Sep 18, 2020 at 05:51:39PM -0700, Jeremy via bitcoin-dev wrote:
> > I'd like to share with you a draft proposal for a mechanism to replace
> > CPFP and RBF for increasing fees on transactions in the mempool that
> > should be more robust against attacks.
>
> Interesting idea!  This is going to take a while to think about, but I
> have one immediate question:
>
> > To prevent garbage sponsors, we also require that:
> >
> > 1. The Sponsor's feerate must be greater than the Sponsored's ancestor
> fee rate
> >
> > We allow one Sponsor to replace another subject to normal replacement
> > policies, they are treated as conflicts.
>
> Is this in the reference implementation?  I don't see it and I'm
> confused by this text.  I think it could mean either:
>
> 1. Sponsor Tx A can be replaced by Sponsor Tx B if A and B have at least
>    one input in common (which is part of the "normal replacement policies")
>
> 2. A can be replaced by B even if they don't have any inputs in common
>    as long as they do have a Sponsor Vector in common (while otherwise
>    using the "normal replacement policies").
>
> In the first case, I think Mallory can prevent Bob from
> sponsor-fee-bumping (sponsor-bumping?) his transaction by submitting a
> sponsor before he does; since Bob has no control over Mallory's inputs,
> he can't replace Mallory's sponsor tx.
>
> In the second case, I think Mallory can use an existing pinning
> technique to make it expensive for Bob to fee bump.  The normal
> replacement policies require a replacement to pay an absolute higher fee
> than the original transaction, so Mallory can create a 100,000 vbyte
> transaction with a single-vector sponsor at the end pointing to Bob's
> transaction.  This sponsor transaction pays the same feerate as Bob's
> transaction---let's say 50 nBTC/vbyte, so 5 mBTC total fee.  In order
> for Bob to replace Mallory's sponsor transaction with his own sponsor
> transaction, Bob needs to pay the incremental relay feerate (10
> nBTC/vbyte) more, so 6 mBTC total ($66 at $11k/BTC).
>
> Thanks,
>
> -Dave
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"auto">Wouldn&#39;t this enable a passive adversary listening th=
e mempool to associate unrelated TXO clusters to the same user?</div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sat, Sep =
19, 2020, 15:38 David A. Harding via bitcoin-dev &lt;<a href=3D"mailto:bitc=
oin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a=
>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Sep 18, 2020 a=
t 05:51:39PM -0700, Jeremy via bitcoin-dev wrote:<br>
&gt; I&#39;d like to share with you a draft proposal for a mechanism to rep=
lace<br>
&gt; CPFP and RBF for increasing fees on transactions in the mempool that<b=
r>
&gt; should be more robust against attacks.<br>
<br>
Interesting idea!=C2=A0 This is going to take a while to think about, but I=
<br>
have one immediate question:<br>
<br>
&gt; To prevent garbage sponsors, we also require that:<br>
&gt; <br>
&gt; 1. The Sponsor&#39;s feerate must be greater than the Sponsored&#39;s =
ancestor fee rate<br>
&gt; <br>
&gt; We allow one Sponsor to replace another subject to normal replacement<=
br>
&gt; policies, they are treated as conflicts.<br>
<br>
Is this in the reference implementation?=C2=A0 I don&#39;t see it and I&#39=
;m<br>
confused by this text.=C2=A0 I think it could mean either:<br>
<br>
1. Sponsor Tx A can be replaced by Sponsor Tx B if A and B have at least<br=
>
=C2=A0 =C2=A0one input in common (which is part of the &quot;normal replace=
ment policies&quot;)<br>
<br>
2. A can be replaced by B even if they don&#39;t have any inputs in common<=
br>
=C2=A0 =C2=A0as long as they do have a Sponsor Vector in common (while othe=
rwise<br>
=C2=A0 =C2=A0using the &quot;normal replacement policies&quot;).<br>
<br>
In the first case, I think Mallory can prevent Bob from<br>
sponsor-fee-bumping (sponsor-bumping?) his transaction by submitting a<br>
sponsor before he does; since Bob has no control over Mallory&#39;s inputs,=
<br>
he can&#39;t replace Mallory&#39;s sponsor tx.<br>
<br>
In the second case, I think Mallory can use an existing pinning<br>
technique to make it expensive for Bob to fee bump.=C2=A0 The normal<br>
replacement policies require a replacement to pay an absolute higher fee<br=
>
than the original transaction, so Mallory can create a 100,000 vbyte<br>
transaction with a single-vector sponsor at the end pointing to Bob&#39;s<b=
r>
transaction.=C2=A0 This sponsor transaction pays the same feerate as Bob&#3=
9;s<br>
transaction---let&#39;s say 50 nBTC/vbyte, so 5 mBTC total fee.=C2=A0 In or=
der<br>
for Bob to replace Mallory&#39;s sponsor transaction with his own sponsor<b=
r>
transaction, Bob needs to pay the incremental relay feerate (10<br>
nBTC/vbyte) more, so 6 mBTC total ($66 at $11k/BTC).<br>
<br>
Thanks,<br>
<br>
-Dave<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000c04f7605afabe364--