path: root/c0/fd19c7a5944967481974c4d844e4ba4dc81f3b

Delivery-date: Tue, 23 Jul 2024 17:44:05 -0700
Received: from mail-yb1-f190.google.com ([209.85.219.190])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBTM4QG2QMGQEYYEBOPA@googlegroups.com>)
	id 1sWQ6u-0004qZ-OU
	for bitcoindev@gnusha.org; Tue, 23 Jul 2024 17:44:05 -0700
Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-e05ec8921fdsf12747297276.1
        for <bitcoindev@gnusha.org>; Tue, 23 Jul 2024 17:44:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1721781839; x=1722386639; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=cxK+8Yz420krABR27or65yBKv0vpAEQVTNSHOeC6DC4=;
        b=E5I6+6+2LM2f12xgpBQ1N5LbFwtTQMancXQnIvGWk/RZs2HgDj5fdQk7ouKHFwwOdq
         XXaKEUhU8qzOrN3vzUbBjmP4C9KQYRwz2joYS2OeffYMTBdV/z3bSWlkWy7/HuZuAqE3
         37tOS2PGAa1upk7qzCY1Gcf/Twu1wRgYoqpHjOoCebIz+0tBQWUnJ2ymg2yis3UVhLEW
         e91kWmBO/bZEkNv4EpU/DR9ZNtHAcCC4ByjTrfv2ulh+lCTkHoEeD2ESnTWl6qfCEM8e
         2O8i6FuP4JDpZ2gI65PYUlyTfkbZKvbsMp6WfuakvOZh7GIIhQsJILzciEV6tSoWJ4if
         9cVg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1721781839; x=1722386639; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=cxK+8Yz420krABR27or65yBKv0vpAEQVTNSHOeC6DC4=;
        b=XZe31S4rd1f6kkJlm8qRJZIHQ6j5xtdUYnOluE5USBD+b7caVPV4TdvaBMhvSpm7li
         C6e741ylZZJwf9VGjtc9MHqbnEBZTm4MWDt7VAqJ2uQr6EPM6NMf5MLIzW9HJQsMYm2E
         reggSFMyQOyayAXdo6NSe7WXozpTeycgUsOEbwVLn7xivAxpa4rBL+/r0+ofJwuHLRFt
         oZrou0bIeWN2HZecB9MeVk41O2g4lqJPExSyoRQk2Ax0MesbUCYEKpNXSMIayaO404ve
         jSa3MMg7rnoV3DHIH4FBhpvZI8KcR/nFVqlxih4kd1MTgwvXI53omMuPbYfhjaQqITa3
         KvIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1721781839; x=1722386639;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=cxK+8Yz420krABR27or65yBKv0vpAEQVTNSHOeC6DC4=;
        b=Kpgb4C6VkOt+DKtdlfel8D287wgHTScoKfqPQAuUI8YbmQY/ToWKTMBIogI/O6pozp
         U5QHr6lJWv7AqzzD28fWx5exJliVAKNsXpRc07knSHhgkgmSPD8uQElOm4i1fNqpC37B
         B3Gt1sQ6IOx0ZRF489Vqw2dBPt9Mi5mbwThdHxg8T+R2fDXXSQXCyRtpsCoAc1I0aT9H
         mTzIoMDu7lPtGRlsDVs25APK+Hr/0eWiLzY+GT2HEKeZgs7vgz6YtszHNA1sEfj+O2XB
         TC8eV+vQYBKcpGK5E7sJSGar4juEnzXhQX24qNlfvXXRTufRw2IRQImHnhGyKVKTqLNH
         2OgQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWjbqQe+jZrZiVsJTAziCkQW6Pj46zwbkkyG4elRa1D7WIl8e8zesTdjZcNpv4FddLyV5NYHWoawFMCmtB9BPp00Ti+WbI=
X-Gm-Message-State: AOJu0YzMoKhj71RjG/FLQJ+ZTdqHY/Mrc5wZprBqr5CT7YVK2oGUhXKh
	/SNWlPYl/0SpK+hLkAVeO4aRdPoHxwF88oTyYcylxswJiNHtU3s/
X-Google-Smtp-Source: AGHT+IHNJvlI5ayToKdkkUEj9Ozs+k3cVISfFkTiJHCVieFbCVJTd1HnSvw85/KNrtZDvwig4yCX8g==
X-Received: by 2002:a25:ae5e:0:b0:e03:601a:1a83 with SMTP id 3f1490d57ef6-e0b0985c9abmr1748809276.39.1721781838687;
        Tue, 23 Jul 2024 17:43:58 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:2e07:0:b0:e03:514d:f716 with SMTP id 3f1490d57ef6-e05fdbbe498ls6653639276.2.-pod-prod-07-us;
 Tue, 23 Jul 2024 17:43:57 -0700 (PDT)
X-Received: by 2002:a05:690c:d87:b0:615:32e1:d82c with SMTP id 00721157ae682-66a66254672mr9071697b3.6.1721781837315;
        Tue, 23 Jul 2024 17:43:57 -0700 (PDT)
Received: by 2002:a05:690c:26c7:b0:627:7f59:2eee with SMTP id 00721157ae682-6691747e85fms7b3;
        Tue, 23 Jul 2024 17:38:39 -0700 (PDT)
X-Received: by 2002:a81:ee09:0:b0:651:2eea:4dfe with SMTP id 00721157ae682-672b6a14cb5mr99217b3.0.1721781518530;
        Tue, 23 Jul 2024 17:38:38 -0700 (PDT)
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"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

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