Delivery-date: Sun, 21 Jul 2024 11:04:48 -0700
Sender: bitcoindev@googlegroups.com
Date: Sat, 20 Jul 2024 19:12:18 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <6d52892b-db6c-4497-894a-cc6f337acb97n@googlegroups.com>
In-Reply-To: <fd1e1dd3-ffda-416b-9bc8-900d0b69c8c1n@googlegroups.com>
References: <Zpk7EYgmlgPP3Y9D@petertodd.org>
 <18a5e5a2-92b3-4345-853d-5a63b71d848bn@googlegroups.com>
 <9c4c2a65-2c87-47f1-85d1-137c32099fb7n@googlegroups.com>
 <fd1e1dd3-ffda-416b-9bc8-900d0b69c8c1n@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_530330_1096622603.1721527938131"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_530330_1096622603.1721527938131
Content-Type: multipart/alternative; 
	boundary="----=_Part_530331_1569615936.1721527938131"

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

Hi dev0,

> I will quote _willcl-ark_'s last comment as I do not have enough=20
permissions in bitcoin core repository to moderate comments:
>=20
> "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 p> hilosophical discussion we are going to close and lock=20
this PR."

I think you're missing my argument about formalization as ways to have=20
moderation norms shared and accepted by all contributors whatever, their
cultural or professional background.=20

I believe (a) the moderation criteria on in / off-topic comment and its=20
exercise by moderator shall be objective enough to be understood and=20
spontaneously
followed by contributors and (b) the moderators vetted with permissions=20
should adhere to a minimal of conflicts of interests guidelines to avoid=20
being accused
of being "political" in the exercise of their permsisions (cf. bitcoin-meta=
=20
issue #3 which I'll observe has been opened for 2 months now and have not=
=20
received an answer).

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

This is a non-sense to say a new pull request should help reviewers, when=
=20
as a PR author you cannot know with certainty who will be the reviewers in=
=20
a FOSS project like Core.
About engaging on the moderation rules, like said, it's already done on the=
=20
gituhb, which favors long-format and in-depth discussion (rather than an=20
IRC channel).

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

This is certainly a discussion that we shall have a community, be it=20
bitcoin core project active contributors, or security researchers offering=
=20
their time to report sec issues.

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

I'll observe that we're quite limited by the medium itself, i.e github as=
=20
we cannot prioritize review comments based on contributors reputation.

Though this is not answering the risk of having an in / off-topic=20
moderation criteria inflating with time and vicissiating from intellectual=
=20
substance the "public communication channels".

If you look on the history of public space in the world over the last 2=20
millenias and what lessons we can drawn or ponder for FOSS development, a=
=20
public space is always
a frail notion that it always at risk of disappearing or being captured. I=
=20
can always recommend you to read Hannah Arendet's The Crisis of Culture or=
=20
The Human Condition if
you wish to meditate on this notion of public space, and the significance=
=20
of it (it's a philosopher I hope relatively universal, whatever your=20
cultural background).

> 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

Interesting, I'll review it again in the coming future.

Best,
Antoine
ots hash: 6ba9cae6564f1ef8c583115ec71d155e9b4504907e02059e7a02046b6220dc2e

Le samedi 20 juillet 2024 =C3=A0 07:51:09 UTC+1, /dev /fd0 a =C3=A9crit :

> Hi Antoine,
>
> >  I'm interested if you can propose a formal or mathematical definition=
=20
> of 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 thi=
s=20
> PR."
>
> A new pull request should help reviewers. If you do not agree with it,=20
> feel 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=20
> give 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=20
> piece 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=20
>> request to enable full RBF by default, referencing the one closed due to=
=20
>> off-topic 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 situatio=
n=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 giv=
e=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 piec=
e=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=20
>> wise to bundle it with novel
>> technical information, as from the outset it does not favor to=20
>> concentrate 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: 3088507ecfb55ed301bb0defce9fb490daa6bb9594e96d57336d603556a8fd=
ab
>> Le vendredi 19 juillet 2024 =C3=A0 19:27:36 UTC+1, /dev /fd0 a =C3=A9cri=
t :
>>
>>> 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 reques=
t=20
>>> to enable full RBF by default, referencing the one closed due to off-to=
pic=20
>>> comments.=20
>>>
>>> > But read on, this is quite an odd case of Core politics, and the stor=
y=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 includin=
g=20
>>>> a fun=20
>>>> homework problem at the end: figure out how TRUC/V3 transactions itsel=
f=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-rb=
f=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=20
>>>> 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/812907c2b00b92ee31e2b638622a4fe14=
a428aee/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, an=
d=20
>>>> don't=20
>>>> want to admit that they've wasted a large amount of engineering time o=
n=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-RB=
F=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=20
>>>> work, you've=20
>>>> probably figured it out already based on the title: obviously, if a=20
>>>> high=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=
=20
>>>> not 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 wil=
l=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=
=20
>>>> if 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.=20
>>>> Since=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 pa=
y=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=20
>>>> less 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=20
>>>> 3sat/vB 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=20
>>>> about 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=20
>>>> 100KvB, 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=20
>>>> mining=20
>>>> consolidation transactions for them at low cost. In this variant of th=
e=20
>>>> attack,=20
>>>> the attacker would pad the size of B with consolidation spends that=20
>>>> they 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=20
>>>> attack, 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,=
=20
>>>> the=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/6d52892b-db6c-4497-894a-cc6f337acb97n%40googlegroups.com.

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

Hi dev0,<br /><br />&gt; I will quote _willcl-ark_'s last comment as I do n=
ot have enough permissions in bitcoin core repository to moderate comments:=
<br />&gt; <br />&gt; "However the comments section here has become difficu=
lt to follow due to numerous off-topic comments, a few personal disagreemen=
ts, and repetition of arguments. In the interest of having a more productiv=
e and focused technical and p&gt; hilosophical discussion we are going to c=
lose and lock this PR."<br /><br />I think you're missing my argument about=
 formalization as ways to have moderation norms shared and accepted by all =
contributors whatever, their<br />cultural or professional background. <br =
/><br />I believe (a) the moderation criteria on in / off-topic comment and=
 its exercise by moderator shall be objective enough to be understood and s=
pontaneously<br />followed by contributors and (b) the moderators vetted wi=
th permissions should adhere to a minimal of conflicts of interests guideli=
nes to avoid being accused<br />of being "political" in the exercise of the=
ir permsisions (cf. bitcoin-meta issue #3 which I'll observe has been opene=
d for 2 months now and have not received an answer).<br /><br />&gt; A new =
pull request should help reviewers. If you do not agree with it, feel free =
to discuss it with moderators in bitcoin core IRC channel.<br /><br />This =
is a non-sense to say a new pull request should help reviewers, when as a P=
R author you cannot know with certainty who will be the reviewers in a FOSS=
 project like Core.<br />About engaging on the moderation rules, like said,=
 it's already done on the gituhb, which favors long-format and in-depth dis=
cussion (rather than an IRC channel).<br /><br />&gt; Related discussion: h=
ttps://github.com/bitcoin-core/meta/issues/5<br /><br />This is certainly a=
 discussion that we shall have a community, be it bitcoin core project acti=
ve contributors, or security researchers offering their time to report sec =
issues.<br /><br />&gt; Ironically, this is exactly how moderation works in=
 bitcoin core pull requests and some comments were marked off-topic..<br />=
<br />I'll observe that we're quite limited by the medium itself, i.e githu=
b as we cannot prioritize review comments based on contributors reputation.=
<br /><br />Though this is not answering the risk of having an in / off-top=
ic moderation criteria inflating with time and vicissiating from intellectu=
al substance the "public communication channels".<br /><br />If you look on=
 the history of public space in the world over the last 2 millenias and wha=
t lessons we can drawn or ponder for FOSS development, a public space is al=
ways<br />a frail notion that it always at risk of disappearing or being ca=
ptured. I can always recommend you to read Hannah Arendet's The Crisis of C=
ulture or The Human Condition if<br />you wish to meditate on this notion o=
f public space, and the significance of it (it's a philosopher I hope relat=
ively universal, whatever your cultural background).<br /><br />&gt; I have=
 opened a pull request with the same commits (Peter Todd being the author) =
to enable Full RBF by default: https://github.com/bitcoin/bitcoin/pull/3049=
3<br /><br />Interesting, I'll review it again in the coming future.<br /><=
br />Best,<br />Antoine<br />ots hash: 6ba9cae6564f1ef8c583115ec71d155e9b45=
04907e02059e7a02046b6220dc2e<br /><br /><div class=3D"gmail_quote"><div dir=
=3D"auto" class=3D"gmail_attr">Le samedi 20 juillet 2024 =C3=A0 07:51:09 UT=
C+1, /dev /fd0 a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204)=
; padding-left: 1ex;">Hi Antoine,<div><br></div><div></div><div>&gt;=C2=A0

I&#39;m interested if you can propose a formal or mathematical definition o=
f what constitute<br>&gt; an in-topic of off-topic comments on a matters li=
ke full RBF, which has been controversial<br>&gt; for like a decade.<br><br=
></div><div>I will quote _willcl-ark_&#39;s last comment as I do not have e=
nough permissions in bitcoin core repository to moderate comments:</div><di=
v><br></div><div>&quot;However the comments section here has become difficu=
lt to follow due to numerous off-topic comments, a few personal disagreemen=
ts, and repetition of arguments. In the interest of having a more productiv=
e and focused technical and philosophical discussion we are going to close =
and lock this PR.&quot;</div><div><br></div><div>A new pull request should =
help reviewers. If you do not agree with it, feel free to discuss it with m=
oderators in bitcoin core IRC channel.</div><div><br></div><div></div><div>=
&gt;=C2=A0

Again, I&#39;m interested if you can propose a formal or mathematical defin=
ition of what constitute<br>&gt; a reasonable bitcoin core vulnerability ha=
ndling 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 &quot;politics&quot;.<br><br></div><d=
iv>Related discussion:=C2=A0<a href=3D"https://github.com/bitcoin-core/meta=
/issues/5" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https=
://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.com/bitcoin-core/meta/=
issues/5&amp;source=3Dgmail&amp;ust=3D1721614254583000&amp;usg=3DAOvVaw173w=
wlf4j5C5ciEmVaAgNG">https://github.com/bitcoin-core/meta/issues/5</a></div>=
<div><br></div><div>&gt;=C2=A0I think we have a mailing list to favorize te=
xtual long format and encourage a more self-reflexive<br>&gt; mode of reaso=
ning in the conduct of bitcoin engineering discussions. I believe comments =
not bringing<br>&gt; new factual information or pointing to past experience=
s or concrete piece of information are better<br>&gt; left to twitter / nos=
tr / reddit, whatever other communication channel where the scientific and<=
br>&gt; ethics of conversation standards are less stringent.</div><div><br>=
</div><div>Ironically, this is exactly how moderation works in bitcoin core=
 pull requests and some comments were marked off-topic..</div><div><br></di=
v><div>I have opened a pull request with the same commits (Peter Todd being=
 the author) to enable Full RBF by default:=C2=A0<a href=3D"https://github.=
com/bitcoin/bitcoin/pull/30493" target=3D"_blank" rel=3D"nofollow" data-saf=
eredirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://github.c=
om/bitcoin/bitcoin/pull/30493&amp;source=3Dgmail&amp;ust=3D1721614254583000=
&amp;usg=3DAOvVaw07z-hC52x1wBa12AAsjoh3">https://github.com/bitcoin/bitcoin=
/pull/30493</a></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_a=
ttr">On Saturday, July 20, 2024 at 12:01:12=E2=80=AFAM UTC Antoine Riard wr=
ote:<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">Hi /dev/fd0<br><b=
r>&gt; The last comment in the pull request suggests opening a new pull req=
uest to enable full RBF by default, referencing the one closed due to off-t=
opic comments.<br><br>I&#39;m interested if you can propose a formal or mat=
hematical definition of what constitute<br>an in-topic of off-topic comment=
s on a matters like full RBF, which has been controversial<br>for like a de=
cade. I can only think such definition could make future conversations abou=
t<br>the boundaries of what is in / off bitcoin engineering topic more obje=
ctive.<br><br>&gt; It seems that you are the one trying to politicize this =
issue.<br><br>Let&#39;s be realistic on the state of bitcoin core security =
issues handling in the recent words of<br>a group of some active contributo=
rs:<br><br>&quot;The project has historically done a poor job at publicly d=
isclosing security-critical bugs, whether<br>externally reported or found b=
y contributors. This has led to a situation where a lot of users perceive<b=
r>Bitcoin Core as never having bugs. This perception is dangerous and, unfo=
rtunately, not accurate.&quot; [0].<br><br>[0] <a href=3D"https://groups.go=
ogle.com/g/bitcoindev/c/Q2ZGit2wF7w" rel=3D"nofollow" target=3D"_blank" dat=
a-saferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://gro=
ups.google.com/g/bitcoindev/c/Q2ZGit2wF7w&amp;source=3Dgmail&amp;ust=3D1721=
614254583000&amp;usg=3DAOvVaw0oXm6Zb4Ymb_yKHV3M7ebr">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 rea=
sonable bitcoin core vulnerability handling policy and that way give more g=
round on qualifying<br>if a present situation is falling out of this reason=
able guidelines and that can be qualified more <br>objectively as &quot;pol=
itics&quot;.<br><br>I think we have a mailing list to favorize textual long=
 format and encourage a more self-reflexive<br>mode of reasoning in the con=
duct of bitcoin engineering discussions. I believe comments not bringing<br=
>new factual information or pointing to past experiences or concrete piece =
of information are better<br>left to twitter / nostr / reddit, whatever oth=
er communication channel where the scientific and<br>ethics of conversation=
 standards are less stringent.<br><br>All that said, I&#39;m thinking to ag=
ree that the usage of all political rhethoric is a fallacy better<br>left f=
or expressions on other communication channels and this is note wise to bun=
dle it with novel<br>technical information, as from the outset it does not =
favor to concentrate the discussion on the fact<br>and logical reasoning th=
emselves. Even more, political rhetoric very easily downgrade in moralistic=
<br>contest among protagonists on who has the monopole of the good / truth.=
 Somehow bitcoin is beyond<br>good and evil (-- under some long-term and ab=
stract perspective).<br><br>Best,<br>Antoine<br>ots hash: 3088507ecfb55ed30=
1bb0defce9fb490daa6bb9594e96d57336d603556a8fdab<br><div class=3D"gmail_quot=
e"><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 clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">Hi Peter,<br><br>&gt;=C2=A0I didn&#39;t get a s=
ubstantive<br>&gt; response from Bitcoin Core, other than Core closing the =
my pull-req enabling<br>&gt; full-RBF by default that would fix this specif=
ic vulnerability.<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=3Dfr&amp;q=3Dhttps://groups.google.com/g/bitcoindev/c/EJYoeNTPV=
hg&amp;source=3Dgmail&amp;ust=3D1721614254583000&amp;usg=3DAOvVaw3QBRF3Kniz=
PqpW3s91g9iU">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=3Dfr&amp;q=3Dhttps://groups.google.com/g/bitcoindev/c/3XqfIOYzX=
qo&amp;source=3Dgmail&amp;ust=3D1721614254583000&amp;usg=3DAOvVaw02qu0l1F9x=
ao2GBQM9IsOm">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=3Dfr&amp;q=3Dhttps://github.com/bitcoin/bips/blob=
/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki%23user-content=
-Alternatives_replace_by_feerate&amp;source=3Dgmail&amp;ust=3D1721614254584=
000&amp;usg=3DAOvVaw1AN6mA8oV_YaT65axSNDk6">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=3Dfr&amp;q=3Dhttp://memp=
ool.space&amp;source=3Dgmail&amp;ust=3D1721614254584000&amp;usg=3DAOvVaw3Mw=
m8CmgWwBKEEDfVzf3r2">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=3Dfr&amp;q=3Dhttps://pe=
tertodd.org&amp;source=3Dgmail&amp;ust=3D1721614254584000&amp;usg=3DAOvVaw3=
XX7fd2iMgQqis02cszbfh">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=3Dfr&amp;q=3Dhttp://petertodd.org=
&amp;source=3Dgmail&amp;ust=3D1721614254584000&amp;usg=3DAOvVaw0mRXWMuaQDxS=
z5svt-U2mv">petertodd.org</a>
<br></blockquote></div></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/6d52892b-db6c-4497-894a-cc6f337acb97n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/6d52892b-db6c-4497-894a-cc6f337acb97n%40googlegroups.com</a>.=
<br />

------=_Part_530331_1569615936.1721527938131--

------=_Part_530330_1096622603.1721527938131--