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: Thu, 18 Jul 2024 16:04:47 -0700 (PDT) [thread overview]
Message-ID: <18fc443d-c347-4a84-94fe-81308ae20b76n@googlegroups.com> (raw)
In-Reply-To: <Zpk7EYgmlgPP3Y9D@petertodd.org>
[-- Attachment #1.1: Type: text/plain, Size: 12764 bytes --]
Hi Peter,
Thanks for the sharing of information about "free relay" attack.
I have one question I'm curious to know the answer which is how much time
have
been left the private report of this issue to the bitcoin-security mailing
list
and the public disclosure. With still in mind the conversation that happens
on
the other thread few months ago, and unless emergency I think it's good to
give
few weeks of leeway for a vendor team to answer substantially [0].
Beyond, if what you're saying is correct, in your administrative removal
from the
bitcoin-security mailing list by achow, I'm curious in achow explaining in
public
its rational in this unexpected decision and what did happen in its own
words.
I respect achow as a bitcoin core maintainer from years of collaboration on
the
repository and achow is one of the few bitcoin professionals I still
reasonably
trust in matters of security report and coordinated mitigation in this
space.
All that said, with the new information you're sharing and without achow's
substantial
answer, it let me ponder if achow is still worthy that it's someome with
whom I'll share
in the future security-sensitive related information to bitcoin core and
the base-layer
robustnes. After all, the bitcoin-security mailing list is just a
communication endpoint
and there is no adamant ethical rule abstraining a security researcher to
diligently
report issues.
About V3 / TRUC, I must say that originally few years ago when we
discovered all the
transaction pinning issues affecting lightning funds security in a strict
sense, I was
among the people advocating the design and deployment of new policy rules
as a way to
migitate the pinnings concerns [1]. I must say with more implementation
experiences of
policy rules, new discovery like replacement cycling issues and reasoning
on the mining
game-theory of policy rules, I've come incredebly skeptical that V3 / TRUC
is the "right
way" to mitigate pinnings vectors. At the very best, in my opinion it's a
"poor's man band
aid"'s in waiting that someone design something better.
This wouldn't bet the first time that less-than-perfect p2p / mempools
extensions are
introduced in bitcoin (e.g bip37) and with time more and more folks realize
that effectively
the design has more and more apparent weakeness with time.
About the new attack itself, which I beleive holds at first read, I think
your explanation
can benefit to layout more the mining topology configutation and policy
default which makes
the free-relay attack exploitable and explain step-by-step how the spend
and double-spend
are propagate in the transaction-relay network.
In my understanding, the attack efficiency varies widely in function of the
hashrate ressources
of the miner getting the high-feerate double-spend A2 transaction. I think
higher are the hashrate
ressources, lower would have been the transaction B (re)-broadcast
bandwidth waste.
I don't think the exploitation example with an exchange you're giving is
the more speaking
adversarial example, however I believe it's an interesting building block
for other types of
attacks, which is worthy of research.
On the TRUC / V3 creating new attacks vectors, this will all dependent if
the miners adopt
this change and if they estimate it's maximzing their mining income revenue
in average, it's
a one line of code to disable currently (L134 in `src/policy/policy.h`
tweaking the 3 back to 2).
Best,
Antoine
ots hash: d40d371e725626589feaf439dcc301af9ae287f5dc06eb26155b95fcd608438e
[0] I checked my own archive after writing this email on the "free relay"
thread [2]. In fact
even about time-dilation attack, I gave more than 2 weeks for the lightning
maintainers to do
something, if they wished so before to do a full-disclosure. 2 weeks is a
reasonable heuristic.
[1] See
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018063.html
[2] https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg
Le jeudi 18 juillet 2024 à 17:04:26 UTC+1, Peter Todd a écrit :
> # 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/18fc443d-c347-4a84-94fe-81308ae20b76n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 15576 bytes --]
next prev parent reply other threads:[~2024-07-18 23:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-18 15:56 [bitcoindev] " Peter Todd
2024-07-18 23:04 ` Antoine Riard [this message]
2024-07-19 1:05 ` [bitcoindev] " 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=18fc443d-c347-4a84-94fe-81308ae20b76n@googlegroups.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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