Delivery-date: Fri, 19 Jul 2024 07:23:14 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::d36 as permitted sender) client-ip=2607:f8b0:4864:20::d36;
MIME-Version: 1.0
References: <Zpk7EYgmlgPP3Y9D@petertodd.org> <18fc443d-c347-4a84-94fe-81308ae20b76n@googlegroups.com>
 <Zpm73WHBNIkkIT0Y@petertodd.org>
In-Reply-To: <Zpm73WHBNIkkIT0Y@petertodd.org>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Fri, 19 Jul 2024 14:52:29 +0100
Message-ID: <CALZpt+HJvBXM_geK7JC8umrt1goq8bc+pnY0mk+o+r_+bjrtew@mail.gmail.com>
Subject: Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The
 Lack of Full-RBF In Core
To: Peter Todd <pete@petertodd.org>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="00000000000051cd21061d9a02e5"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

--00000000000051cd21061d9a02e5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Peter,

> I think you need to re-read the attack carefully before we discuss this
> further. The % of hash power mining full-rbf does not significantly
change the
> cost efficiency of the attack as long as the fee-rate of the B
transaction(s)
> is below the minimum economic fee-rate necessary for miners to mine a
> transaction. Above the minimum economic fee-rate, the cost efficiency is
an
> essentially linear function of % of full-rbf miners.

This is not the % of hash power mining _full-rbf_ I was pointing to, just
the indistinct
total % of hash power mining.

In my understanding, this is the scenario:
- Alice broadcasts small size, low-feerate transaction opt-in disabled A to
99% of the miners+network nodes mempools
- Alice broadcasts a double-spend of A, a high-feerate transaction A2 to
Mark, a single miner
- Network nodes does not relay transaction A to Mark and vice-versa Mark
does not relay transaction A2 to network nodes
- Alice broadcasts a child B of transaction A to 99% of the miners+network
nodes mempools
- Mark, the single miner confirms in a block A2, rendering as a waste A+B
network bandwidth

Correct if I'm wrong with this scenario and if it does not match the attack
vector you're describing.

The child B can be extended with a full chain of useless children within
max mempool limits.

The attack efficiency (i.e the total vB of bandwidth network waste) is
dependent on the delay
by which transaction A2 is included in Mark's block template and
subsequently mined. Back to
my observation, higher are Mark hashrate ressources, less there is latency
to let transaction B
spontaneously propagate on the network, or for Alice to (re)-broadcast in
cycle.

All that said, I think my open question to you at the beginning of my
answer is still there,
i.e how much time has been left between the private report of this issue to
the sec mailing
list and the public disclosure of your email.

Best,
Antoine
ots hash: 001081aba5b44bf98f8774090fcd62109061e1623965ab8ec71068274b46aaf8

Le ven. 19 juil. 2024 =C3=A0 02:05, Peter Todd <pete@petertodd.org> a =C3=
=A9crit :

> On Thu, Jul 18, 2024 at 04:04:47PM -0700, Antoine Riard wrote:
> > Hi Peter,
> >
> > In my understanding, the attack efficiency varies widely in function of
> the
> > hashrate ressources
> > of the miner getting the high-feerate double-spend A2 transaction. I
> think
> > higher are the hashrate
> > ressources, lower would have been the transaction B (re)-broadcast
> > bandwidth waste.
>
> I think you need to re-read the attack carefully before we discuss this
> further. The % of hash power mining full-rbf does not significantly chang=
e
> the
> cost efficiency of the attack as long as the fee-rate of the B
> transaction(s)
> is below the minimum economic fee-rate necessary for miners to mine a
> transaction. Above the minimum economic fee-rate, the cost efficiency is =
an
> essentially linear function of % of full-rbf miners.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/CALZpt%2BHJvBXM_geK7JC8umrt1goq8bc%2BpnY0mk%2Bo%2Br_%2Bbjrtew%40=
mail.gmail.com.

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

<div dir=3D"ltr">Hi Peter,<br><br>&gt; I think you need to re-read the atta=
ck carefully before we discuss this<br>&gt; further. The % of hash power mi=
ning full-rbf does not significantly change the<br>&gt; cost efficiency of =
the attack as long as the fee-rate of the B transaction(s)<br>&gt; is below=
 the minimum economic fee-rate necessary for miners to mine a<br>&gt; trans=
action. Above the minimum economic fee-rate, the cost efficiency is an<br>&=
gt; essentially linear function of % of full-rbf miners.<br><br>This is not=
 the % of hash power mining _full-rbf_ I was pointing to, just the indistin=
ct<div>total % of hash power mining.<br><br>In my understanding, this is th=
e scenario:<br>- Alice broadcasts small size, low-feerate transaction opt-i=
n disabled A to 99% of the miners+network nodes mempools<br>- Alice broadca=
sts a double-spend of A, a high-feerate transaction A2 to Mark, a single mi=
ner<br>- Network nodes does not relay transaction A to Mark and vice-versa =
Mark does not relay transaction A2 to network nodes<br>- Alice broadcasts a=
 child B of transaction A to 99% of the miners+network nodes mempools<br>- =
Mark, the single miner confirms in a block A2, rendering as a waste A+B net=
work bandwidth<br><br>Correct if I&#39;m wrong with this scenario and if it=
 does not match the attack vector you&#39;re describing. <br><br>The child =
B can be extended with a full chain of useless children within max mempool =
limits.<br><br>The attack efficiency (i.e the total vB of bandwidth network=
 waste) is dependent on the delay<br>by which transaction A2 is included in=
 Mark&#39;s block template and subsequently mined. Back to<br>my observatio=
n, higher are Mark hashrate ressources, less there is latency to let transa=
ction B<br>spontaneously propagate on the network, or for Alice to (re)-bro=
adcast in cycle.<br><br>All that said, I think my open question to you at t=
he beginning of my answer is still there,<br>i.e how much time has been lef=
t between the private report of this issue to the sec mailing<br>list and t=
he public disclosure of your email.<br><br>Best,<br>Antoine<br>ots hash: 00=
1081aba5b44bf98f8774090fcd62109061e1623965ab8ec71068274b46aaf8<br></div></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=
=C2=A0ven. 19 juil. 2024 =C3=A0=C2=A002:05, Peter Todd &lt;<a href=3D"mailt=
o:pete@petertodd.org">pete@petertodd.org</a>&gt; a =C3=A9crit=C2=A0:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204=
);padding-left:1ex">On Thu, Jul 18, 2024 at 04:04:47PM -0700, Antoine Riard=
 wrote:<br>
&gt; Hi Peter,<br>
&gt;<br>
&gt; In my understanding, the attack efficiency varies widely in function o=
f the <br>
&gt; hashrate ressources<br>
&gt; of the miner getting the high-feerate double-spend A2 transaction. I t=
hink <br>
&gt; higher are the hashrate<br>
&gt; ressources, lower would have been the transaction B (re)-broadcast <br=
>
&gt; bandwidth waste.<br>
<br>
I think you need to re-read the attack carefully before we discuss this<br>
further. The % of hash power mining full-rbf does not significantly change =
the<br>
cost efficiency of the attack as long as the fee-rate of the B transaction(=
s)<br>
is below the minimum economic fee-rate necessary for miners to mine a<br>
transaction. Above the minimum economic fee-rate, the cost efficiency is an=
<br>
essentially linear function of % of full-rbf miners.<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>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/CALZpt%2BHJvBXM_geK7JC8umrt1goq8bc%2BpnY0mk%2Bo%2Br_%=
2Bbjrtew%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://g=
roups.google.com/d/msgid/bitcoindev/CALZpt%2BHJvBXM_geK7JC8umrt1goq8bc%2Bpn=
Y0mk%2Bo%2Br_%2Bbjrtew%40mail.gmail.com</a>.<br />

--00000000000051cd21061d9a02e5--