public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
Date: Sat, 20 Jul 2024 19:12:18 -0700 (PDT)	[thread overview]
Message-ID: <6d52892b-db6c-4497-894a-cc6f337acb97n@googlegroups.com> (raw)
In-Reply-To: <fd1e1dd3-ffda-416b-9bc8-900d0b69c8c1n@googlegroups.com>


[-- Attachment #1.1: Type: text/plain, Size: 18566 bytes --]

Hi dev0,

> I will quote _willcl-ark_'s last comment as I do not have enough 
permissions in bitcoin core repository to moderate comments:
> 
> "However the comments section here has become difficult to follow due to 
numerous off-topic comments, a few personal disagreements, and repetition 
of arguments. In the interest of having a more productive and focused 
technical and p> hilosophical discussion we are going to close and lock 
this PR."

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

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

> 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.

This is a non-sense to say a new pull request should help reviewers, when 
as a PR author you cannot know with certainty who will be the reviewers in 
a FOSS project like Core.
About engaging on the moderation rules, like said, it's already done on the 
gituhb, which favors long-format and in-depth discussion (rather than an 
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 
bitcoin core project active contributors, or security researchers offering 
their time to report sec issues.

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

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

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

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

> 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/30493

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

Best,
Antoine
ots hash: 6ba9cae6564f1ef8c583115ec71d155e9b4504907e02059e7a02046b6220dc2e

Le samedi 20 juillet 2024 à 07:51:09 UTC+1, /dev /fd0 a écrit :

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

-- 
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 email 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.

[-- Attachment #1.2: Type: text/html, Size: 22018 bytes --]

  parent reply	other threads:[~2024-07-21 18:04 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-18 15:56 [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd
2024-07-18 23:04 ` [bitcoindev] " Antoine Riard
2024-07-19  1:05   ` Peter Todd
2024-07-19 13:52     ` Antoine Riard
2024-07-19 14:38       ` Peter Todd
2024-07-19 23:58         ` Antoine Riard
2024-07-20  0:46           ` 'Ava Chow' via Bitcoin Development Mailing List
2024-07-21  2:06             ` Antoine Riard
2024-07-21 20:17               ` 'Ava Chow' via Bitcoin Development Mailing List
2024-07-22  1:59                 ` 'Anonymous User' via Bitcoin Development Mailing List
2024-07-24  0:44                   ` Antoine Riard
2024-08-01  5:57                   ` Garlo Nicon
2024-07-24  0:35                 ` Antoine Riard
2024-07-19 12:41 ` /dev /fd0
2024-07-19 23:56   ` Antoine Riard
2024-07-20  5:57     ` /dev /fd0
2024-07-20 15:08       ` Peter Todd
2024-07-21  2:13         ` Antoine Riard
2024-07-21  6:16         ` /dev /fd0
2024-07-21  2:12       ` Antoine Riard [this message]
2024-07-19 18:26 ` [bitcoindev] " Murch
2024-07-20 14:10   ` Peter Todd
2024-07-20  6:41 ` David A. Harding
2024-07-20 15:03   ` Peter Todd
2024-07-20 15:30     ` Peter Todd
2024-07-21 15:35     ` David A. Harding
2024-07-21 20:25       ` Peter Todd
2024-07-24  0:38       ` Antoine Riard
2024-07-21  2:10   ` Antoine Riard
2024-07-22 15:10     ` Peter Todd
2024-07-24  0:41       ` Antoine Riard
2024-07-30  4:57     ` David A. Harding
2024-07-30 19:38       ` Peter Todd
2024-08-16  4:45         ` Antoine Riard
2024-08-16  4:20       ` Antoine Riard
2024-07-22 11:45   ` [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not Peter Todd
2024-07-22 16:43     ` David A. Harding
2024-07-22 20:06       ` Peter Todd
2024-07-22 22:08         ` David A. Harding
2024-07-23 11:29           ` Peter Todd
2024-07-24  0:42           ` Antoine Riard
2024-07-22 17:13   ` [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6d52892b-db6c-4497-894a-cc6f337acb97n@googlegroups.com \
    --to=antoine.riard@gmail.com \
    --cc=bitcoindev@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox