Delivery-date: Tue, 23 Jul 2024 17:44:05 -0700
Sender: bitcoindev@googlegroups.com
Date: Tue, 23 Jul 2024 17:38:38 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <1d64b24e-9ae4-4eac-b93a-c35fdcd26d6en@googlegroups.com>
In-Reply-To: <d57a02a84e756dbda03161c9034b9231@dtrt.org>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
 <c6593662694f9d4a4fe999dd432f87ff@dtrt.org>
 <ZpvRvRybauFFnhQV@petertodd.org>
 <d57a02a84e756dbda03161c9034b9231@dtrt.org>
Subject: Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack
 of Full-RBF In Core
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_1119486_1116258211.1721781518315"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_1119486_1116258211.1721781518315
Content-Type: multipart/alternative; 
	boundary="----=_Part_1119487_287820526.1721781518315"

------=_Part_1119487_287820526.1721781518315
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dave,

> Weak blocks also provide a decentralized DoS-resistant mechanism for
> voluntarily communicating all sorts of information from miners to other
> miners and relay nodes. That makes them an excellent tool for resolving
> any attack that depends on miners and relay nodes having a divergent set
> of transactions.

I think the mechanism you're describing is plagued by the following=20
vulnerability:
- an attacker mempool-partition all miners by exploiting transaction-relay=
=20
asymmetries (e.g same feerate, same weight, diff txid)
- an attacker broadcast an appealing transaction entering the top of mempoo=
l
- a weak block up to 4MB is generated for each such miner partitioned and=
=20
relayed to the rest of the network
- the whole block-relay network is wasting 4 MB of block-relay bandwidth=20
multiplied by N, the number of miners affected
- the mempool-partitition transaction vector might have paid a sub-minimal=
=20
feerate just to enter in mempool

Bonus point: the attacker has hashrate capabilities to mine the block=20
including the mempool-partition transaction vector
rendering a null gain for the DoSed miners whatever the weak block reward=
=20
mechanism for the "weak block" proposal (unless
the reward is exogeneous to the bitcoin blockchain, a type of in-protocol=
=20
reward one might skeptical relatively to bitcoin
security model).

I don't think the "weak block" proposal as you're presenting it makes=20
sense, at the very least quantitative evaluations
would be necessary to be sure you're not worsening the denial-of-service=20
aspect. In the present layout of the "weak block"
proposal, I really think you saying it's a decentralized DoS-resistant=20
mechanism is deeply misleading and inaccurate for
the rest of the community.

Zooming out, I believe it's an intesresting problem wishing to improve=20
rewarding of miners income if we wish to encourage
solo miners, and improve on the initial financial liquidity incentives that=
=20
are driving miners to gather themselves in pool
since the early days of bitcon, though I don't see how "weak block" can be=
=20
a viable solution.

Best,
Antoine
ots hash: 85636ac4e91bc781bbcdc8c0a24a17ad1c90039c6cabbb4d3ddd334c2c29fc02=
=20

Le dimanche 21 juillet 2024 =C3=A0 19:04:29 UTC+1, David A. Harding a =C3=
=A9crit :

> On 2024-07-20 05:03, Peter Todd wrote:
> > What other "free" relay attacks can you think of that were fixed?
>
> The two you mention were the two I had in mind.
>
> > Did you actually read my One-Shot RBFR proposal?
>
> Yes. It didn't provide any examples of RBFr free relay and I wanted to
> see whether a basic RBFr free relay attack would use significantly more,
> significantly less, or about the same amount of bandwidth per dollar
> spent as other free relay attacks. My conclusion is that it's about the
> same.
>
> > Weak blocks are not a solution to any of the "free" relay attacks I've
> > disclosed and your source does not claim that they are a "free" relay
> > solution.
>
> It does not explicitly say that, but it does say: "bonus use-cases:
> =E2=80=9CForcible insertion=E2=80=9D of transactions that are incentive-c=
ompatible but
> violate anti-DoS rules".
>
> For example, in some of the scenarios you describe, the attacker sends
> an appealing transaction to miners and then sends less appealing
> versions of that transaction to relay nodes. If the appealing
> transaction enters the top mempool and gets included in a weak block,
> relay nodes will stop relaying less appealing variations minutes to
> hours before they otherwise would.
>
> Weak blocks also provide a decentralized DoS-resistant mechanism for
> voluntarily communicating all sorts of information from miners to other
> miners and relay nodes. That makes them an excellent tool for resolving
> any attack that depends on miners and relay nodes having a divergent set
> of transactions.
>
> > 1) Have you've read my One Shot RBFR proposal? In particular, my
> > analysis of DoS attacks *including* existing DoS attacks like
> > simultaneous broadcast.
> >=20
> > 2) Do you agree or disagree with me that these existing DoS attacks
> > are real?
>
> Yes, I've read your proposal, and I agree those attacks are plausible.
> In my mind, the major difference between those free relay attacks
> and RBFR free relay attacks is how solvable they are.
>
> I think it's easy to sketch a significant mitigation to all free relay
> attacks (including RBFR):
>
> - Reduce the maximum size of both relayable transactions and in-mempool
> packages, e.g. from 100,000 vbytes to 1,000 vbytes.
>
> - Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB.
>
> - Increase the default mempool feerate floor, e.g. from e.g. from 1
> sat/vb to 100 sat/vb.
>
> That would break relay of many existing presigned transactions,
> potentially leading to money loss, and would break other existing
> usecases, not to mention introduce other problems. However, I think
> it's sufficient to prove that a mitigation to free relay is possible
> without rendering the network unusable.
>
> Of course, an ideal solution wouldn't require placing any additional
> constraints on mempool policy. For the case of free relay due to
> divergent mempool policies, maybe it's something that could be done with
> transaction set reconciliation (~erlay), functions for allowing
> independent nodes to come to consistent conclusions about the best
> revenue set of transactions (~cluster mempool), P2P relay of non-obvious
> cluster linearizations[1], and miners voluntarily committing to their
> mempool contents in candidate blocks and P2P relaying those commitments
> in weak blocks.
>
> Innovations like that don't work for RBFR. If mempool policy is kept
> the same, free relay attacks with RBFR remain equally effective no
> matter what mechanisms we implement to improve preconsensus consistency.
>
> If pure RBFR is added and clever protocol developers find ways to
> largely fix other free relay attacks, then devs will either need to
> significantly restrict mempool policy anyway or will need to restrict or
> remove RBFR to make Bitcoin Core safe. Given that, it seems to me like
> a very reasonable decision not to add pure RBFR and to wait until better
> tools like cluster mempool become available before evaluating
> significant changes to RBF policy (like one-shot RBFR).
>
> Thanks,
>
> -Dave
>
> [1]=20
>
> https://github.com/bitcoinops/bitcoinops.github.io/pull/1421#discussion_r=
1415834695
>

--=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/1d64b24e-9ae4-4eac-b93a-c35fdcd26d6en%40googlegroups.com.

------=_Part_1119487_287820526.1721781518315
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dave,<br /><br />&gt; Weak blocks also provide a decentralized DoS-resis=
tant mechanism for<br />&gt; voluntarily communicating all sorts of informa=
tion from miners to other<br />&gt; miners and relay nodes. That makes them=
 an excellent tool for resolving<br />&gt; any attack that depends on miner=
s and relay nodes having a divergent set<br />&gt; of transactions.<br /><b=
r />I think the mechanism you're describing is plagued by the following vul=
nerability:<br />- an attacker mempool-partition all miners by exploiting t=
ransaction-relay asymmetries (e.g same feerate, same weight, diff txid)<br =
/>- an attacker broadcast an appealing transaction entering the top of memp=
ool<br />- a weak block up to 4MB is generated for each such miner partitio=
ned and relayed to the rest of the network<br />- the whole block-relay net=
work is wasting 4 MB of block-relay bandwidth multiplied by N, the number o=
f miners affected<br />- the mempool-partitition transaction vector might h=
ave paid a sub-minimal feerate just to enter in mempool<br /><br />Bonus po=
int: the attacker has hashrate capabilities to mine the block including the=
 mempool-partition transaction vector<br />rendering a null gain for the Do=
Sed miners whatever the weak block reward mechanism for the "weak block" pr=
oposal (unless<br />the reward is exogeneous to the bitcoin blockchain, a t=
ype of in-protocol reward one might skeptical relatively to bitcoin<br />se=
curity model).<br /><br />I don't think the "weak block" proposal as you're=
 presenting it makes sense, at the very least quantitative evaluations<br /=
>would be necessary to be sure you're not worsening the denial-of-service a=
spect. In the present layout of the "weak block"<br />proposal, I really th=
ink you saying it's a decentralized DoS-resistant mechanism is deeply misle=
ading and inaccurate for<br />the rest of the community.<br /><br />Zooming=
 out, I believe it's an intesresting problem wishing to improve rewarding o=
f miners income if we wish to encourage<br />solo miners, and improve on th=
e initial financial liquidity incentives that are driving miners to gather =
themselves in pool<br />since the early days of bitcon, though I don't see =
how "weak block" can be a viable solution.<br /><br />Best,<br />Antoine<br=
 />ots hash: 85636ac4e91bc781bbcdc8c0a24a17ad1c90039c6cabbb4d3ddd334c2c29fc=
02=C2=A0<br /><br /><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"g=
mail_attr">Le dimanche 21 juillet 2024 =C3=A0 19:04:29 UTC+1, David A. Hard=
ing a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding=
-left: 1ex;">On 2024-07-20 05:03, Peter Todd wrote:
<br>&gt; What other &quot;free&quot; relay attacks can you think of that we=
re fixed?
<br>
<br>The two you mention were the two I had in mind.
<br>
<br>&gt; Did you actually read my One-Shot RBFR proposal?
<br>
<br>Yes.  It didn&#39;t provide any examples of RBFr free relay and I wante=
d to
<br>see whether a basic RBFr free relay attack would use significantly more=
,
<br>significantly less, or about the same amount of bandwidth per dollar
<br>spent as other free relay attacks.  My conclusion is that it&#39;s abou=
t the
<br>same.
<br>
<br>&gt; Weak blocks are not a solution to any of the &quot;free&quot; rela=
y attacks I&#39;ve
<br>&gt; disclosed and your source does not claim that they are a &quot;fre=
e&quot; relay
<br>&gt; solution.
<br>
<br>It does not explicitly say that, but it does say: &quot;bonus use-cases=
:
<br>=E2=80=9CForcible insertion=E2=80=9D of transactions that are incentive=
-compatible but
<br>violate anti-DoS rules&quot;.
<br>
<br>For example, in some of the scenarios you describe, the attacker sends
<br>an appealing transaction to miners and then sends less appealing
<br>versions of that transaction to relay nodes.  If the appealing
<br>transaction enters the top mempool and gets included in a weak block,
<br>relay nodes will stop relaying less appealing variations minutes to
<br>hours before they otherwise would.
<br>
<br>Weak blocks also provide a decentralized DoS-resistant mechanism for
<br>voluntarily communicating all sorts of information from miners to other
<br>miners and relay nodes.  That makes them an excellent tool for resolvin=
g
<br>any attack that depends on miners and relay nodes having a divergent se=
t
<br>of transactions.
<br>
<br>&gt; 1) Have you&#39;ve read my One Shot RBFR proposal? In particular, =
my
<br>&gt; analysis of DoS attacks *including* existing DoS attacks like
<br>&gt; simultaneous broadcast.
<br>&gt;=20
<br>&gt; 2) Do you agree or disagree with me that these existing DoS attack=
s
<br>&gt; are real?
<br>
<br>Yes, I&#39;ve read your proposal, and I agree those attacks are plausib=
le.
<br>In my mind, the major difference between those free relay attacks
<br>and RBFR free relay attacks is how solvable they are.
<br>
<br>I think it&#39;s easy to sketch a significant mitigation to all free re=
lay
<br>attacks (including RBFR):
<br>
<br>- Reduce the maximum size of both relayable transactions and in-mempool
<br>   packages, e.g. from 100,000 vbytes to 1,000 vbytes.
<br>
<br>- Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB.
<br>
<br>- Increase the default mempool feerate floor, e.g. from e.g. from 1
<br>   sat/vb to 100 sat/vb.
<br>
<br>That would break relay of many existing presigned transactions,
<br>potentially leading to money loss, and would break other existing
<br>usecases, not to mention introduce other problems.  However, I think
<br>it&#39;s sufficient to prove that a mitigation to free relay is possibl=
e
<br>without rendering the network unusable.
<br>
<br>Of course, an ideal solution wouldn&#39;t require placing any additiona=
l
<br>constraints on mempool policy.  For the case of free relay due to
<br>divergent mempool policies, maybe it&#39;s something that could be done=
 with
<br>transaction set reconciliation (~erlay), functions for allowing
<br>independent nodes to come to consistent conclusions about the best
<br>revenue set of transactions (~cluster mempool), P2P relay of non-obviou=
s
<br>cluster linearizations[1], and miners voluntarily committing to their
<br>mempool contents in candidate blocks and P2P relaying those commitments
<br>in weak blocks.
<br>
<br>Innovations like that don&#39;t work for RBFR.  If mempool policy is ke=
pt
<br>the same, free relay attacks with RBFR remain equally effective no
<br>matter what mechanisms we implement to improve preconsensus consistency=
.
<br>
<br>If pure RBFR is added and clever protocol developers find ways to
<br>largely fix other free relay attacks, then devs will either need to
<br>significantly restrict mempool policy anyway or will need to restrict o=
r
<br>remove RBFR to make Bitcoin Core safe.  Given that, it seems to me like
<br>a very reasonable decision not to add pure RBFR and to wait until bette=
r
<br>tools like cluster mempool become available before evaluating
<br>significant changes to RBF policy (like one-shot RBFR).
<br>
<br>Thanks,
<br>
<br>-Dave
<br>
<br>[1]=20
<br><a href=3D"https://github.com/bitcoinops/bitcoinops.github.io/pull/1421=
#discussion_r1415834695" target=3D"_blank" rel=3D"nofollow" data-saferedire=
cturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/bitc=
oinops/bitcoinops.github.io/pull/1421%23discussion_r1415834695&amp;source=
=3Dgmail&amp;ust=3D1721867759933000&amp;usg=3DAOvVaw2X4-nfDVxG2uLXgZHywT3U"=
>https://github.com/bitcoinops/bitcoinops.github.io/pull/1421#discussion_r1=
415834695</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/1d64b24e-9ae4-4eac-b93a-c35fdcd26d6en%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/1d64b24e-9ae4-4eac-b93a-c35fdcd26d6en%40googlegroups.com</a>.=
<br />

------=_Part_1119487_287820526.1721781518315--

------=_Part_1119486_1116258211.1721781518315--