Delivery-date: Fri, 19 Jul 2024 23:51:18 -0700
Sender: bitcoindev@googlegroups.com
Date: Fri, 19 Jul 2024 22:57:40 -0700 (PDT)
From: /dev /fd0 <alicexbtong@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <fd1e1dd3-ffda-416b-9bc8-900d0b69c8c1n@googlegroups.com>
In-Reply-To: <9c4c2a65-2c87-47f1-85d1-137c32099fb7n@googlegroups.com>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
 <18a5e5a2-92b3-4345-853d-5a63b71d848bn@googlegroups.com>
 <9c4c2a65-2c87-47f1-85d1-137c32099fb7n@googlegroups.com>
Subject: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack
 of Full-RBF In Core
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_315086_645987492.1721455060728"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_315086_645987492.1721455060728
Content-Type: multipart/alternative; 
	boundary="----=_Part_315087_1827213981.1721455060728"

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

Hi Antoine,

>  I'm interested if you can propose a formal or mathematical definition of=
=20
what constitute
> an in-topic of off-topic comments on a matters like full RBF, which has=
=20
been controversial
> for like a decade.

I will quote _willcl-ark_'s last comment as I do not have enough=20
permissions in bitcoin core repository to moderate comments:

"However the comments section here has become difficult to follow due to=20
numerous off-topic comments, a few personal disagreements, and repetition=
=20
of arguments. In the interest of having a more productive and focused=20
technical and philosophical discussion we are going to close and lock this=
=20
PR."

A new pull request should help reviewers. If you do not agree with it, feel=
=20
free to discuss it with moderators in bitcoin core IRC channel.

>  Again, I'm interested if you can propose a formal or mathematical=20
definition of what constitute
> a reasonable bitcoin core vulnerability handling policy and that way give=
=20
more ground on qualifying
> if a present situation is falling out of this reasonable guidelines and=
=20
that can be qualified more
> objectively as "politics".

Related discussion: https://github.com/bitcoin-core/meta/issues/5

> I think we have a mailing list to favorize textual long format and=20
encourage a more self-reflexive
> mode of reasoning in the conduct of bitcoin engineering discussions. I=20
believe comments not bringing
> new factual information or pointing to past experiences or concrete piece=
=20
of information are better
> left to twitter / nostr / reddit, whatever other communication channel=20
where the scientific and
> ethics of conversation standards are less stringent.

Ironically, this is exactly how moderation works in bitcoin core pull=20
requests and some comments were marked off-topic..

I have opened a pull request with the same commits (Peter Todd being the=20
author) to enable Full RBF by default:=20
https://github.com/bitcoin/bitcoin/pull/30493

/dev/fd0
floppy disk guy

On Saturday, July 20, 2024 at 12:01:12=E2=80=AFAM UTC Antoine Riard wrote:

> Hi /dev/fd0
>
> > The last comment in the pull request suggests opening a new pull reques=
t=20
> to enable full RBF by default, referencing the one closed due to off-topi=
c=20
> comments.
>
> I'm interested if you can propose a formal or mathematical definition of=
=20
> what constitute
> an in-topic of off-topic comments on a matters like full RBF, which has=
=20
> been controversial
> for like a decade. I can only think such definition could make future=20
> conversations about
> the boundaries of what is in / off bitcoin engineering topic more=20
> objective.
>
> > It seems that you are the one trying to politicize this issue.
>
> Let's be realistic on the state of bitcoin core security issues handling=
=20
> in the recent words of
> a group of some active contributors:
>
> "The project has historically done a poor job at publicly disclosing=20
> security-critical bugs, whether
> externally reported or found by contributors. This has led to a situation=
=20
> where a lot of users perceive
> Bitcoin Core as never having bugs. This perception is dangerous and,=20
> unfortunately, not accurate." [0].
>
> [0] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w
>
> Again, I'm interested if you can propose a formal or mathematical=20
> definition of what constitute
> a reasonable bitcoin core vulnerability handling policy and that way give=
=20
> more ground on qualifying
> if a present situation is falling out of this reasonable guidelines and=
=20
> that can be qualified more=20
> objectively as "politics".
>
> I think we have a mailing list to favorize textual long format and=20
> encourage a more self-reflexive
> mode of reasoning in the conduct of bitcoin engineering discussions. I=20
> believe comments not bringing
> new factual information or pointing to past experiences or concrete piece=
=20
> of information are better
> left to twitter / nostr / reddit, whatever other communication channel=20
> where the scientific and
> ethics of conversation standards are less stringent.
>
> All that said, I'm thinking to agree that the usage of all political=20
> rhethoric is a fallacy better
> left for expressions on other communication channels and this is note wis=
e=20
> to bundle it with novel
> technical information, as from the outset it does not favor to concentrat=
e=20
> the discussion on the fact
> and logical reasoning themselves. Even more, political rhetoric very=20
> easily downgrade in moralistic
> contest among protagonists on who has the monopole of the good / truth.=
=20
> Somehow bitcoin is beyond
> good and evil (-- under some long-term and abstract perspective).
>
> Best,
> Antoine
> ots hash: 3088507ecfb55ed301bb0defce9fb490daa6bb9594e96d57336d603556a8fda=
b
> Le vendredi 19 juillet 2024 =C3=A0 19:27:36 UTC+1, /dev /fd0 a =C3=A9crit=
 :
>
>> Hi Peter,
>>
>> > I didn't get a substantive
>> > response from Bitcoin Core, other than Core closing the my pull-req=20
>> enabling
>> > full-RBF by default that would fix this specific vulnerability.
>>
>> The last comment in the pull request suggests opening a new pull request=
=20
>> to enable full RBF by default, referencing the one closed due to off-top=
ic=20
>> comments.=20
>>
>> > But read on, this is quite an odd case of Core politics, and the story=
=20
>> is not
>> > as simple as Core refusing to fix a vulnerability.
>>
>> It seems that you are the one trying to politicize this issue.=20
>>
>> /dev/fd0
>> floppy disk guy
>>
>> On Thursday, July 18, 2024 at 4:04:26=E2=80=AFPM UTC Peter Todd wrote:
>>
>>> # Summary=20
>>>
>>> This is a public disclosure of a vulnerability that I previously=20
>>> disclosed to=20
>>> the bitcoin-security mailing list. It's an easy vulnerability to fix.=
=20
>>> Although=20
>>> as with other "free" relay attacks I've disclosed, I didn't get a=20
>>> substantive=20
>>> response from Bitcoin Core, other than Core closing the my pull-req=20
>>> enabling=20
>>> full-RBF by default that would fix this specific vulnerability.=20
>>>
>>> But read on, this is quite an odd case of Core politics, and the story=
=20
>>> is not=20
>>> as simple as Core refusing to fix a vulnerability. Also, I've including=
=20
>>> a fun=20
>>> homework problem at the end: figure out how TRUC/V3 transactions itself=
=20
>>> creates=20
>>> a "free" relay attack.=20
>>>
>>>
>>> # Background=20
>>>
>>> This is just one of a few "free" relay attacks that I have recently=20
>>> disclosed,=20
>>> including, but not limited to:=20
>>>
>>> "A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2024=20
>>> https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg=20
>>>
>>> "A Free-Relay Attack Exploiting Min-Relay-Fee Differences" - Mar 31st=
=20
>>> 2024=20
>>> https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo=20
>>>
>>> The term "free relay attack" simply refers to any mechanism where=20
>>> transaction=20
>>> data can be broadcast at unusually low cost; the "free" in "free relay"=
=20
>>> is a=20
>>> misnomer as all these attacks do in fact have some cost.=20
>>>
>>> This particular attack isn't significantly different than the other=20
>>> attacks=20
>>> I've disclosed. With one important exception: unlike those other=20
>>> attacks,=20
>>> fixing this particular attack would be quite easy, by enabling full-rbf=
=20
>>> by=20
>>> default. So I disclosed it to the bitcoin-security mailing list as a=20
>>> test: does=20
>>> Bitcoin Core actually care about free relay attacks? My hypothesis is=
=20
>>> that Core=20
>>> does not, as they know full well that "free" relay is an unavoidable=20
>>> problem;=20
>>> I've received absolutely no feedback from any Bitcoin Core members for=
=20
>>> the=20
>>> other disclosed attacks, beyond achow using my disclosure of the RBF=20
>>> Rule #6=20
>>> attack as an excuse to remove me from the bitcoin-security mailing list=
.=20
>>>
>>> The fact that Core doesn't actually care about "free" relay attacks is=
=20
>>> relevant=20
>>> to TRUC/V3 Transactions. As per BIP-431:=20
>>>
>>> "The primary problem with [RBFR proposals] is the potential for free=20
>>> relay and DDoS attacks.=20
>>>
>>> Removing Rule 3 and 4 in general would allow free relay [27]."=20
>>>
>>> https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e2b638622a4fe14a=
428aee/bip-0431.mediawiki#user-content-Alternatives_replace_by_feerate=20
>>>
>>> I believe the authors of that BIP are fully aware of the fact that=20
>>> "free" relay=20
>>> is an unavoidable problem, making their rational for TRUC/V3 bogus, and=
=20
>>> don't=20
>>> want to admit that they've wasted a large amount of engineering time on=
=20
>>> a bad=20
>>> proposal. I will be submitting a pull-req to get BIP-431 corrected, as=
=20
>>> the many=20
>>> "free" relay attacks I've disclosed clearly show that claiming RBFR=20
>>> would=20
>>> "allow" free relay is simply not true.=20
>>>
>>> Notably, full-RBF is _itself_ a transaction pinning fix for many=20
>>> use-cases;=20
>>> part of the TRUC/V3 standard is to force full-RBF behavior for V3=20
>>> transactions.=20
>>> So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a=20
>>> second=20
>>> way, and TRUC/V3 proponents were the ones who tried to get the full-RBF=
=20
>>> option=20
>>> removed from Core in the first place. If not for this dumb bit of Core=
=20
>>> politics, I'm sure my year-old pull-req to enable full-RBF by default=
=20
>>> would=20
>>> have been merged many months ago, as almost all hashpower has adopted=
=20
>>> full-RBF=20
>>> making objections based on "zeroconf" absurd.=20
>>>
>>>
>>> # The Attack=20
>>>
>>> If you're a competent Bitcoin engineer, familiar with how mempools work=
,=20
>>> you've=20
>>> probably figured it out already based on the title: obviously, if a hig=
h=20
>>> percentage of miners are adopting a policy that Bitcoin Core nodes are=
=20
>>> not, you=20
>>> can cheaply consume transaction relay bandwidth by simply relaying=20
>>> transations=20
>>> that miners are rejecting.=20
>>>
>>> Specifically, do the following:=20
>>>
>>> 1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled.=
=20
>>> 2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate.=
=20
>>> 3. Spend the outputs of A in a large, low fee-rate, transaction B with=
=20
>>> BIP-125=20
>>> opt-in enabled. ~100% of miners will reject B, as it spends an input no=
t=20
>>> in=20
>>> their mempools. However Bitcoin Core nodes will waste bandwidth=20
>>> propagating=20
>>> B.=20
>>> 4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will=
=20
>>> waste=20
>>> bandwidth propagating Bn's that ~100% of miners are ignoring.=20
>>> 5. Double-spend A2 to recover your funds and do it all over again (or i=
f=20
>>> A2 had=20
>>> a high enough fee-rate, just wait for it to be mined).=20
>>>
>>> The cost to relay each B transaction depends on the fee-rate of B. Sinc=
e=20
>>> Bitcoin Core defaults to a fairly large mempool, the minimum relay=20
>>> fee-rate is=20
>>> typically well below the economic fee-rate required for miners to=20
>>> actually mine=20
>>> a transaction; Core accepts transactions that are uneconomical for=20
>>> miners to=20
>>> mine for the forseeable future.=20
>>>
>>> For example, at the moment typical mempools require transactions to pay=
=20
>>> at=20
>>> least 1sat/vB, while there are hundreds of MvB worth of transactions=20
>>> paying=20
>>> 4sat/vB, the minimum economical fee-rate. Thus, transactions paying les=
s=20
>>> than=20
>>> 4sat/VB are extremely unlikely to get mined in the nearish future.=20
>>>
>>> Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/v=
B=20
>>> would=20
>>> have almost zero cost as the probability of those transactions getting=
=20
>>> mined is=20
>>> nearly zero. This is true _regardless_ of what % of miners are mining=
=20
>>> full-RBF!=20
>>> As long as you can get at least one miner to mine the A double-spend,=
=20
>>> the=20
>>> attack only costs what it cost to get A mined.=20
>>>
>>> If B's are broadcast at a higher fee-rate than the minimum economical=
=20
>>> fee-rate,=20
>>> then the % of full-RBF miners matters. For example, if only 99% of=20
>>> miners mine=20
>>> full-RBF, the chance of a B transaction getting mined per block is abou=
t=20
>>> 1%, so=20
>>> the amortized cost of broadcasting B is about 1% of whatever total fee=
=20
>>> the=20
>>> highest fee-rate variant of B pays.=20
>>>
>>> For an attacker who does not need any B to be broadcast, the cost=20
>>> savings to=20
>>> use of relay bandwidth is approximately the ratio of the difference in=
=20
>>> size=20
>>> between B and and A. With a maximum standard transaction size of 100KvB=
,=20
>>> or=20
>>> 400KB serialized size, this ratio is on the order of 5000:1, times the=
=20
>>> total=20
>>> number of B variants broadcast, and the % chance of each B being mined;=
=20
>>> it's a=20
>>> few orders of magnitude.=20
>>>
>>> Of course, as mentioned above, this is just one of *many* "free" relay=
=20
>>> attacks,=20
>>> so fixing this particular issue doesn't change much.=20
>>>
>>>
>>> # Attackers Who Benefit From B Getting Mined=20
>>>
>>> Some attackers actually need B to get mined. For example, imagine an=20
>>> exchange=20
>>> who needs to do large consolidation transactions. They could use this=
=20
>>> attack=20
>>> (and some attacks like it) as a way to goad users and miners into minin=
g=20
>>> consolidation transactions for them at low cost. In this variant of the=
=20
>>> attack,=20
>>> the attacker would pad the size of B with consolidation spends that the=
y=20
>>> needed=20
>>> to do anyway. Someone who tried to stop the attack by getting B mined=
=20
>>> (eg via=20
>>> mempool.space's transaction accellerator) would simply be paying the=20
>>> attacker's=20
>>> fees for them.=20
>>>
>>> Obviously, this strategy is only relevant for B's below the economic=20
>>> fee-rate.=20
>>> However, the weaker version of this strategy is to parallize the attack=
,=20
>>> and do=20
>>> your consolidation with the _A_ double-spends to reduce the # of bytes=
=20
>>> used per=20
>>> full-rbf double-spend.=20
>>>
>>>
>>> # TRUC/V3 Creates a Free Relay Attack=20
>>>
>>> I'll leave the details of this as a homework problem. But obviously, th=
e=20
>>> introduction of TRUC/V3 transactions *itself* creates a free relay=20
>>> attack very=20
>>> similar to the above! Just like full-RBF, not all miners will mine V3=
=20
>>> transactions. So you can do the exact same type of attack by taking=20
>>> advantage=20
>>> of this difference in mining policy.=20
>>>
>>> --=20
>>> https://petertodd.org 'peter'[:-1]@petertodd.org=20
>>>
>>

--=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/fd1e1dd3-ffda-416b-9bc8-900d0b69c8c1n%40googlegroups.com.

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

Hi Antoine,<div><br /></div><div>&gt;=C2=A0

I'm interested if you can propose a formal or mathematical definition of wh=
at constitute<br />&gt; an in-topic of off-topic comments on a matters like=
 full RBF, which has been controversial<br />&gt; for like a decade.<br /><=
br />I will quote _willcl-ark_'s last comment as I do not have enough permi=
ssions in bitcoin core repository to moderate comments:</div><div><br /></d=
iv><div>"However the comments section here has become difficult to follow d=
ue to numerous off-topic comments, a few personal disagreements, and repeti=
tion of arguments. In the interest of having a more productive and focused =
technical and philosophical discussion we are going to close and lock this =
PR."</div><div><br /></div><div>A new pull request should help reviewers. I=
f you do not agree with it, feel free to discuss it with moderators in bitc=
oin core IRC channel.</div><div><br /></div><div>&gt;=C2=A0

Again, I'm interested if you can propose a formal or mathematical definitio=
n of what constitute<br />&gt; a reasonable bitcoin core vulnerability hand=
ling policy and that way give more ground on qualifying<br />&gt; if a pres=
ent situation is falling out of this reasonable guidelines and that can be =
qualified more<br />&gt; objectively as "politics".<br /><br />Related disc=
ussion:=C2=A0<a href=3D"https://github.com/bitcoin-core/meta/issues/5">http=
s://github.com/bitcoin-core/meta/issues/5</a></div><div><br /></div><div>&g=
t;=C2=A0I think we have a mailing list to favorize textual long format and =
encourage a more self-reflexive<br />&gt; mode of reasoning in the conduct =
of bitcoin engineering discussions. I believe comments not bringing<br />&g=
t; new factual information or pointing to past experiences or concrete piec=
e of information are better<br />&gt; left to twitter / nostr / reddit, wha=
tever other communication channel where the scientific and<br />&gt; ethics=
 of conversation standards are less stringent.</div><div><br /></div><div>I=
ronically, this is exactly how moderation works in bitcoin core pull reques=
ts and some comments were marked off-topic..</div><div><br /></div><div>I h=
ave opened a pull request with the same commits (Peter Todd being the autho=
r) to enable Full RBF by default:=C2=A0<a href=3D"https://github.com/bitcoi=
n/bitcoin/pull/30493">https://github.com/bitcoin/bitcoin/pull/30493</a></di=
v><div><br /></div><div>/dev/fd0</div><div>floppy disk guy<br /><br /></div=
><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Satur=
day, July 20, 2024 at 12:01:12=E2=80=AFAM UTC Antoine Riard wrote:<br/></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-le=
ft: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi /dev/fd0<br><br>&g=
t; The last comment in the pull request suggests opening a new pull request=
 to enable full RBF by default, referencing the one closed due to off-topic=
 comments.<br><br>I&#39;m interested if you can propose a formal or mathema=
tical definition of what constitute<br>an in-topic of off-topic comments on=
 a matters like full RBF, which has been controversial<br>for like a decade=
. I can only think such definition could make future conversations about<br=
>the boundaries of what is in / off bitcoin engineering topic more objectiv=
e.<br><br>&gt; It seems that you are the one trying to politicize this issu=
e.<br><br>Let&#39;s be realistic on the state of bitcoin core security issu=
es handling in the recent words of<br>a group of some active contributors:<=
br><br>&quot;The project has historically done a poor job at publicly discl=
osing security-critical bugs, whether<br>externally reported or found by co=
ntributors. This has led to a situation where a lot of users perceive<br>Bi=
tcoin Core as never having bugs. This perception is dangerous and, unfortun=
ately, not accurate.&quot; [0].<br><br>[0] <a href=3D"https://groups.google=
.com/g/bitcoindev/c/Q2ZGit2wF7w" target=3D"_blank" rel=3D"nofollow" data-sa=
feredirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://groups.=
google.com/g/bitcoindev/c/Q2ZGit2wF7w&amp;source=3Dgmail&amp;ust=3D17215349=
27747000&amp;usg=3DAOvVaw11jj_KEXeTl30GgjuRr4oo">https://groups.google.com/=
g/bitcoindev/c/Q2ZGit2wF7w</a><br><br>Again, I&#39;m interested if you can =
propose a formal or mathematical definition of what constitute<br>a reasona=
ble bitcoin core vulnerability handling policy and that way give more groun=
d on qualifying<br>if a present situation is falling out of this reasonable=
 guidelines and that can be qualified more <br>objectively as &quot;politic=
s&quot;.<br><br>I think we have a mailing list to favorize textual long for=
mat and encourage a more self-reflexive<br>mode of reasoning in the conduct=
 of bitcoin engineering discussions. I believe comments not bringing<br>new=
 factual information or pointing to past experiences or concrete piece of i=
nformation are better<br>left to twitter / nostr / reddit, whatever other c=
ommunication channel where the scientific and<br>ethics of conversation sta=
ndards are less stringent.<br><br>All that said, I&#39;m thinking to agree =
that the usage of all political rhethoric is a fallacy better<br>left for e=
xpressions on other communication channels and this is note wise to bundle =
it with novel<br>technical information, as from the outset it does not favo=
r to concentrate the discussion on the fact<br>and logical reasoning themse=
lves. Even more, political rhetoric very easily downgrade in moralistic<br>=
contest among protagonists on who has the monopole of the good / truth. Som=
ehow bitcoin is beyond<br>good and evil (-- under some long-term and abstra=
ct perspective).<br><br>Best,<br>Antoine<br>ots hash: 3088507ecfb55ed301bb0=
defce9fb490daa6bb9594e96d57336d603556a8fdab<br><div class=3D"gmail_quote"><=
div dir=3D"auto" class=3D"gmail_attr">Le vendredi 19 juillet 2024 =C3=A0 19=
:27:36 UTC+1, /dev /fd0 a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">Hi Peter,<br><br>&gt;=C2=A0I didn&#39;t get a substan=
tive<br>&gt; response from Bitcoin Core, other than Core closing the my pul=
l-req enabling<br>&gt; full-RBF by default that would fix this specific vul=
nerability.<br><br>

The last comment in the pull request suggests opening a new pull request to=
 enable full RBF by default, referencing the one closed due to off-topic co=
mments.

<div><br></div><div>&gt;=C2=A0But read on, this is quite an odd case of Cor=
e politics, and the story is not<br>&gt; as simple as Core refusing to fix =
a vulnerability.</div><div><br></div><div>

It seems that you are the one trying to politicize this issue.

</div><div><br></div><div>/dev/fd0</div><div>floppy disk guy<br><br></div><=
div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Thursda=
y, July 18, 2024 at 4:04:26=E2=80=AFPM UTC Peter Todd wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"># Summary
<br>
<br>This is a public disclosure of a vulnerability that I previously disclo=
sed to
<br>the bitcoin-security mailing list. It&#39;s an easy vulnerability to fi=
x. Although
<br>as with other &quot;free&quot; relay attacks I&#39;ve disclosed, I didn=
&#39;t get a substantive
<br>response from Bitcoin Core, other than Core closing the my pull-req ena=
bling
<br>full-RBF by default that would fix this specific vulnerability.
<br>
<br>But read on, this is quite an odd case of Core politics, and the story =
is not
<br>as simple as Core refusing to fix a vulnerability. Also, I&#39;ve inclu=
ding a fun
<br>homework problem at the end: figure out how TRUC/V3 transactions itself=
 creates
<br>a &quot;free&quot; relay attack.
<br>
<br>
<br># Background
<br>
<br>This is just one of a few &quot;free&quot; relay attacks that I have re=
cently disclosed,
<br>including, but not limited to:
<br>
<br>    &quot;A Free-Relay Attack Exploiting RBF Rule #6&quot; - Mar 18th 2=
024
<br>    <a href=3D"https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg" re=
l=3D"nofollow" target=3D"_blank" data-saferedirecturl=3D"https://www.google=
.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/g/bitcoindev/c/EJYoeNTPV=
hg&amp;source=3Dgmail&amp;ust=3D1721534927747000&amp;usg=3DAOvVaw1pg9w4b8YJ=
YubGAHVLkgbg">https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg</a>
<br>
<br>    &quot;A Free-Relay Attack Exploiting Min-Relay-Fee Differences&quot=
; - Mar 31st 2024
<br>    <a href=3D"https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo" re=
l=3D"nofollow" target=3D"_blank" data-saferedirecturl=3D"https://www.google=
.com/url?hl=3Den&amp;q=3Dhttps://groups.google.com/g/bitcoindev/c/3XqfIOYzX=
qo&amp;source=3Dgmail&amp;ust=3D1721534927747000&amp;usg=3DAOvVaw1fO722xNF_=
wkzTiuEK8qk_">https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo</a>
<br>
<br>The term &quot;free relay attack&quot; simply refers to any mechanism w=
here transaction
<br>data can be broadcast at unusually low cost; the &quot;free&quot; in &q=
uot;free relay&quot; is a
<br>misnomer as all these attacks do in fact have some cost.
<br>
<br>This particular attack isn&#39;t significantly different than the other=
 attacks
<br>I&#39;ve disclosed. With one important exception: unlike those other at=
tacks,
<br>fixing this particular attack would be quite easy, by enabling full-rbf=
 by
<br>default. So I disclosed it to the bitcoin-security mailing list as a te=
st: does
<br>Bitcoin Core actually care about free relay attacks? My hypothesis is t=
hat Core
<br>does not, as they know full well that &quot;free&quot; relay is an unav=
oidable problem;
<br>I&#39;ve received absolutely no feedback from any Bitcoin Core members =
for the
<br>other disclosed attacks, beyond achow using my disclosure of the RBF Ru=
le #6
<br>attack as an excuse to remove me from the bitcoin-security mailing list=
.
<br>
<br>The fact that Core doesn&#39;t actually care about &quot;free&quot; rel=
ay attacks is relevant
<br>to TRUC/V3 Transactions. As per BIP-431:
<br>
<br>    &quot;The primary problem with [RBFR proposals] is the potential fo=
r free relay and DDoS attacks.
<br>
<br>    Removing Rule 3 and 4 in general would allow free relay [27].&quot;
<br>    <a href=3D"https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e=
2b638622a4fe14a428aee/bip-0431.mediawiki#user-content-Alternatives_replace_=
by_feerate" rel=3D"nofollow" target=3D"_blank" data-saferedirecturl=3D"http=
s://www.google.com/url?hl=3Den&amp;q=3Dhttps://github.com/bitcoin/bips/blob=
/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki%23user-content=
-Alternatives_replace_by_feerate&amp;source=3Dgmail&amp;ust=3D1721534927747=
000&amp;usg=3DAOvVaw0sIymiR757C-0TPYkXkjNY">https://github.com/bitcoin/bips=
/blob/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki#user-cont=
ent-Alternatives_replace_by_feerate</a>
<br>
<br>I believe the authors of that BIP are fully aware of the fact that &quo=
t;free&quot; relay
<br>is an unavoidable problem, making their rational for TRUC/V3 bogus, and=
 don&#39;t
<br>want to admit that they&#39;ve wasted a large amount of engineering tim=
e on a bad
<br>proposal. I will be submitting a pull-req to get BIP-431 corrected, as =
the many
<br>&quot;free&quot; relay attacks I&#39;ve disclosed clearly show that cla=
iming RBFR would
<br>&quot;allow&quot; free relay is simply not true.
<br>
<br>Notably, full-RBF is _itself_ a transaction pinning fix for many use-ca=
ses;
<br>part of the TRUC/V3 standard is to force full-RBF behavior for V3 trans=
actions.
<br>So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a se=
cond
<br>way, and TRUC/V3 proponents were the ones who tried to get the full-RBF=
 option
<br>removed from Core in the first place. If not for this dumb bit of Core
<br>politics, I&#39;m sure my year-old pull-req to enable full-RBF by defau=
lt would
<br>have been merged many months ago, as almost all hashpower has adopted f=
ull-RBF
<br>making objections based on &quot;zeroconf&quot; absurd.
<br>
<br>
<br># The Attack
<br>
<br>If you&#39;re a competent Bitcoin engineer, familiar with how mempools =
work, you&#39;ve
<br>probably figured it out already based on the title: obviously, if a hig=
h
<br>percentage of miners are adopting a policy that Bitcoin Core nodes are =
not, you
<br>can cheaply consume transaction relay bandwidth by simply relaying tran=
sations
<br>that miners are rejecting.
<br>
<br>Specifically, do the following:
<br>
<br>1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled.
<br>2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate.
<br>3. Spend the outputs of A in a large, low fee-rate, transaction B with =
BIP-125
<br>   opt-in enabled. ~100% of miners will reject B, as it spends an input=
 not in
<br>   their mempools. However Bitcoin Core nodes will waste bandwidth prop=
agating
<br>   B.
<br>4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will=
 waste
<br>   bandwidth propagating Bn&#39;s that ~100% of miners are ignoring.
<br>5. Double-spend A2 to recover your funds and do it all over again (or i=
f A2 had
<br>   a high enough fee-rate, just wait for it to be mined).
<br>
<br>The cost to relay each B transaction depends on the fee-rate of B. Sinc=
e
<br>Bitcoin Core defaults to a fairly large mempool, the minimum relay fee-=
rate is
<br>typically well below the economic fee-rate required for miners to actua=
lly mine
<br>a transaction; Core accepts transactions that are uneconomical for mine=
rs to
<br>mine for the forseeable future.
<br>
<br>For example, at the moment typical mempools require transactions to pay=
 at
<br>least 1sat/vB, while there are hundreds of MvB worth of transactions pa=
ying
<br>4sat/vB, the minimum economical fee-rate. Thus, transactions paying les=
s than
<br>4sat/VB are extremely unlikely to get mined in the nearish future.
<br>
<br>Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/v=
B would
<br>have almost zero cost as the probability of those transactions getting =
mined is
<br>nearly zero. This is true _regardless_ of what % of miners are mining f=
ull-RBF!
<br>As long as you can get at least one miner to mine the A double-spend, t=
he
<br>attack only costs what it cost to get A mined.
<br>
<br>If B&#39;s are broadcast at a higher fee-rate than the minimum economic=
al fee-rate,
<br>then the % of full-RBF miners matters. For example, if only 99% of mine=
rs mine
<br>full-RBF, the chance of a B transaction getting mined per block is abou=
t 1%, so
<br>the amortized cost of broadcasting B is about 1% of whatever total fee =
the
<br>highest fee-rate variant of B pays.
<br>
<br>For an attacker who does not need any B to be broadcast, the cost savin=
gs to
<br>use of relay bandwidth is approximately the ratio of the difference in =
size
<br>between B and and A. With a maximum standard transaction size of 100KvB=
, or
<br>400KB serialized size, this ratio is on the order of 5000:1, times the =
total
<br>number of B variants broadcast, and the % chance of each B being mined;=
 it&#39;s a
<br>few orders of magnitude.
<br>
<br>Of course, as mentioned above, this is just one of *many* &quot;free&qu=
ot; relay attacks,
<br>so fixing this particular issue doesn&#39;t change much.
<br>
<br>
<br># Attackers Who Benefit From B Getting Mined
<br>
<br>Some attackers actually need B to get mined. For example, imagine an ex=
change
<br>who needs to do large consolidation transactions. They could use this a=
ttack
<br>(and some attacks like it) as a way to goad users and miners into minin=
g
<br>consolidation transactions for them at low cost. In this variant of the=
 attack,
<br>the attacker would pad the size of B with consolidation spends that the=
y needed
<br>to do anyway. Someone who tried to stop the attack by getting B mined (=
eg via
<br><a href=3D"http://mempool.space" rel=3D"nofollow" target=3D"_blank" dat=
a-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttp://memp=
ool.space&amp;source=3Dgmail&amp;ust=3D1721534927747000&amp;usg=3DAOvVaw0L2=
JLAPj_sT4UDdjU-wz-4">mempool.space</a>&#39;s transaction accellerator) woul=
d simply be paying the attacker&#39;s
<br>fees for them.
<br>
<br>Obviously, this strategy is only relevant for B&#39;s below the economi=
c fee-rate.
<br>However, the weaker version of this strategy is to parallize the attack=
, and do
<br>your consolidation with the _A_ double-spends to reduce the # of bytes =
used per
<br>full-rbf double-spend.
<br>
<br>
<br># TRUC/V3 Creates a Free Relay Attack
<br>
<br>I&#39;ll leave the details of this as a homework problem. But obviously=
, the
<br>introduction of TRUC/V3 transactions *itself* creates a free relay atta=
ck very
<br>similar to the above! Just like full-RBF, not all miners will mine V3
<br>transactions. So you can do the exact same type of attack by taking adv=
antage
<br>of this difference in mining policy.
<br>
<br>--=20
<br><a href=3D"https://petertodd.org" rel=3D"nofollow" target=3D"_blank" da=
ta-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://pe=
tertodd.org&amp;source=3Dgmail&amp;ust=3D1721534927747000&amp;usg=3DAOvVaw1=
WRvR1CVWQdmg69DP8T4_6">https://petertodd.org</a> &#39;peter&#39;[:-1]@<a hr=
ef=3D"http://petertodd.org" rel=3D"nofollow" target=3D"_blank" data-safered=
irecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttp://petertodd.org=
&amp;source=3Dgmail&amp;ust=3D1721534927747000&amp;usg=3DAOvVaw10zh6HFaRQYk=
991fLPAyRZ">petertodd.org</a>
<br></blockquote></div></blockquote></div></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/fd1e1dd3-ffda-416b-9bc8-900d0b69c8c1n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/fd1e1dd3-ffda-416b-9bc8-900d0b69c8c1n%40googlegroups.com</a>.=
<br />

------=_Part_315087_1827213981.1721455060728--

------=_Part_315086_645987492.1721455060728--