* [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
@ 2024-07-18 15:56 Peter Todd
2024-07-18 23:04 ` [bitcoindev] " Antoine Riard
` (3 more replies)
0 siblings, 4 replies; 37+ messages in thread
From: Peter Todd @ 2024-07-18 15:56 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 8003 bytes --]
# 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/Zpk7EYgmlgPP3Y9D%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
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 ` Antoine Riard
2024-07-19 1:05 ` Peter Todd
2024-07-19 12:41 ` /dev /fd0
` (2 subsequent siblings)
3 siblings, 1 reply; 37+ messages in thread
From: Antoine Riard @ 2024-07-18 23:04 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-18 23:04 ` [bitcoindev] " Antoine Riard
@ 2024-07-19 1:05 ` Peter Todd
2024-07-19 13:52 ` Antoine Riard
0 siblings, 1 reply; 37+ messages in thread
From: Peter Todd @ 2024-07-19 1:05 UTC (permalink / raw)
To: Antoine Riard; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]
On Thu, Jul 18, 2024 at 04:04:47PM -0700, Antoine Riard wrote:
> Hi Peter,
>
> 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 think you need to re-read the attack carefully before we discuss this
further. The % of hash power mining full-rbf does not significantly change the
cost efficiency of the attack as long as the fee-rate of the B transaction(s)
is below the minimum economic fee-rate necessary for miners to mine a
transaction. Above the minimum economic fee-rate, the cost efficiency is an
essentially linear function of % of full-rbf miners.
--
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/Zpm73WHBNIkkIT0Y%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
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 12:41 ` /dev /fd0
2024-07-19 23:56 ` Antoine Riard
2024-07-19 18:26 ` [bitcoindev] " Murch
2024-07-20 6:41 ` David A. Harding
3 siblings, 1 reply; 37+ messages in thread
From: /dev /fd0 @ 2024-07-19 12:41 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 9279 bytes --]
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/18a5e5a2-92b3-4345-853d-5a63b71d848bn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 12031 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-19 1:05 ` Peter Todd
@ 2024-07-19 13:52 ` Antoine Riard
2024-07-19 14:38 ` Peter Todd
0 siblings, 1 reply; 37+ messages in thread
From: Antoine Riard @ 2024-07-19 13:52 UTC (permalink / raw)
To: Peter Todd; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]
Hi Peter,
> I think you need to re-read the attack carefully before we discuss this
> further. The % of hash power mining full-rbf does not significantly
change the
> cost efficiency of the attack as long as the fee-rate of the B
transaction(s)
> is below the minimum economic fee-rate necessary for miners to mine a
> transaction. Above the minimum economic fee-rate, the cost efficiency is
an
> essentially linear function of % of full-rbf miners.
This is not the % of hash power mining _full-rbf_ I was pointing to, just
the indistinct
total % of hash power mining.
In my understanding, this is the scenario:
- Alice broadcasts small size, low-feerate transaction opt-in disabled A to
99% of the miners+network nodes mempools
- Alice broadcasts a double-spend of A, a high-feerate transaction A2 to
Mark, a single miner
- Network nodes does not relay transaction A to Mark and vice-versa Mark
does not relay transaction A2 to network nodes
- Alice broadcasts a child B of transaction A to 99% of the miners+network
nodes mempools
- Mark, the single miner confirms in a block A2, rendering as a waste A+B
network bandwidth
Correct if I'm wrong with this scenario and if it does not match the attack
vector you're describing.
The child B can be extended with a full chain of useless children within
max mempool limits.
The attack efficiency (i.e the total vB of bandwidth network waste) is
dependent on the delay
by which transaction A2 is included in Mark's block template and
subsequently mined. Back to
my observation, higher are Mark hashrate ressources, less there is latency
to let transaction B
spontaneously propagate on the network, or for Alice to (re)-broadcast in
cycle.
All that said, I think my open question to you at the beginning of my
answer is still there,
i.e how much time has been left between the private report of this issue to
the sec mailing
list and the public disclosure of your email.
Best,
Antoine
ots hash: 001081aba5b44bf98f8774090fcd62109061e1623965ab8ec71068274b46aaf8
Le ven. 19 juil. 2024 à 02:05, Peter Todd <pete@petertodd•org> a écrit :
> On Thu, Jul 18, 2024 at 04:04:47PM -0700, Antoine Riard wrote:
> > Hi Peter,
> >
> > 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 think you need to re-read the attack carefully before we discuss this
> further. The % of hash power mining full-rbf does not significantly change
> the
> cost efficiency of the attack as long as the fee-rate of the B
> transaction(s)
> is below the minimum economic fee-rate necessary for miners to mine a
> transaction. Above the minimum economic fee-rate, the cost efficiency is an
> essentially linear function of % of full-rbf miners.
>
> --
> 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/CALZpt%2BHJvBXM_geK7JC8umrt1goq8bc%2BpnY0mk%2Bo%2Br_%2Bbjrtew%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 4369 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-19 13:52 ` Antoine Riard
@ 2024-07-19 14:38 ` Peter Todd
2024-07-19 23:58 ` Antoine Riard
0 siblings, 1 reply; 37+ messages in thread
From: Peter Todd @ 2024-07-19 14:38 UTC (permalink / raw)
To: Antoine Riard; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 6279 bytes --]
On Fri, Jul 19, 2024 at 02:52:29PM +0100, Antoine Riard wrote:
> Hi Peter,
>
> > I think you need to re-read the attack carefully before we discuss this
> > further. The % of hash power mining full-rbf does not significantly
> change the
> > cost efficiency of the attack as long as the fee-rate of the B
> transaction(s)
> > is below the minimum economic fee-rate necessary for miners to mine a
> > transaction. Above the minimum economic fee-rate, the cost efficiency is
> an
> > essentially linear function of % of full-rbf miners.
>
> This is not the % of hash power mining _full-rbf_ I was pointing to, just
> the indistinct
> total % of hash power mining.
>
> In my understanding, this is the scenario:
> - Alice broadcasts small size, low-feerate transaction opt-in disabled A to
> 99% of the miners+network nodes mempools
> - Alice broadcasts a double-spend of A, a high-feerate transaction A2 to
> Mark, a single miner
> - Network nodes does not relay transaction A to Mark and vice-versa Mark
> does not relay transaction A2 to network nodes
Here I think you've misunderstood the attack.
A is a low fee-rate transaction with opt-in disabled. When it is broadcast, it
reaches 100% of nodes.
A2 is a full-RBF double-spend of A. When it is broadcast, it reaches all
nodes/miners with full-RBF enabled, replacing A. Full-RBF nodes do in fact
relay A2 to non-full-rbf nodes they're peered with. But those nodes reject A2
as it is a full-RBF replacement.
We are *not* trying to limit A2 to a single miner, or do any kind of
simultaneous broadcast. We don't need to.
> - Alice broadcasts a child B of transaction A to 99% of the miners+network
> nodes mempools
The % of miners/nodes that accept B isn't particularly relevant; this is an
attack primarily against nodes that have full-RBF disabled (though those nodes
will waste the bandwidth of their full-RBF peers).
> - Mark, the single miner confirms in a block A2, rendering as a waste A+B
> network bandwidth
Again, the attack does not depend on a single miner receiving A2. Indeed, it
works fine even if 100% of hash power is mining A2.
Also, A2 isn't necessarily what gets mined. A2 can be broadcast with a fee-rate
only slightly higher than A that is still below the minimum economic fee-rate,
and then replaced later with an even higher fee-rate double-spend that is a
high enough fee-rate to get mined. Remember that RBF Rule #6 prohibits a
replacement if the fee-rate of the replacement is lower than the directly
replaced transaction.
> Correct if I'm wrong with this scenario and if it does not match the attack
> vector you're describing.
You're not far off. But I believe you are still misunderstanding details, as
described above.
> The child B can be extended with a full chain of useless children within
> max mempool limits.
Correct. Although it's probably simplest to just pick a B that is large enough
to max out the mempool limits on its own.
> The attack efficiency (i.e the total vB of bandwidth network waste) is
> dependent on the delay
> by which transaction A2 is included in Mark's block template and
> subsequently mined. Back to
> my observation, higher are Mark hashrate ressources, less there is latency
> to let transaction B
> spontaneously propagate on the network, or for Alice to (re)-broadcast in
> cycle.
Again, A2 does not need to pay a high enough fee-rate to be economical to mine.
So there are no particular latency requirements between when A, B, and A2 are
broadcast.
All that is necessary for this class of attack is there be at least one miner
willing to mine A2 (or a further double-spend), who rejects A.
> All that said, I think my open question to you at the beginning of my
> answer is still there,
> i.e how much time has been left between the private report of this issue to
> the sec mailing
> list and the public disclosure of your email.
This attack is simply a variant of attacks that were publicly disclosed months
ago, that Core has chosen not to respond to at all, so the exact timeframe
isn't very relevant. This is not actually a new class of attack; the whole
point of my disclosure is to show that Core does not actually care about this
class of attack by showing they won't even bother to fix the simplest possible
version, even when the fix is trivial.
But anyway, I disclosed on Jul 7th giving a 7 day deadline before I'd publish
if I couldn't get any response. I publicly verified that achow (and others) had
received my email on Jul 10th, with achow promising a response. On Jul 12th
rather than replying, Core closed my full-RBF pull-req that fixes this issue.
On Jul 15th I reached out again, and after someone else pointed out that
failing to reply to me was degrading the value of the security mailing list,
and finally got achow and glozow to respond in a perfunctory fashion (glozow
recommended that I open a new full-RBF pull-req). So I published this on Jul
18th after my replies to achow and glozow didn't get any response. This whole
time no-one has asked me to not publish this attack; asking me to keep this
fact about mempools a secret would be rather duplicitous given that a key
argument for TRUC/V3 relies on "free" relay attacks not being possible.
Core could have *easily* responded by simply merging my pull-req to enable
full-RBF by default, a trivial change that has had lots of ACKs from technical
reviewers, which ~100% of hash power has adopted. No-one reasonable would have
questioned merging that pull-req. They chose not to do so, proving my point
that none of this has anything to do with a genuine technical concern.
I was previously on the bitcoin-security mailing list for years, and almost
every disclosed attack has gotten a response within 24 hours, with the longest
about 72 hours (I just skimmed through my archives to double check). Failing to
respond at all is very unusual.
--
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/Zpp6U00Mp7Z/bOej%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
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 12:41 ` /dev /fd0
@ 2024-07-19 18:26 ` Murch
2024-07-20 14:10 ` Peter Todd
2024-07-20 6:41 ` David A. Harding
3 siblings, 1 reply; 37+ messages in thread
From: Murch @ 2024-07-19 18:26 UTC (permalink / raw)
To: bitcoindev
On 7/18/24 11:56, Peter Todd wrote:
> # Summary
>
> This is a public disclosure of a vulnerability that I previously disclosed to
> the bitcoin-security mailing list.
It seems redundant to point out that some transactions are only relayed
by a subset of a node population if there are multiple diverging mempool
policies with significant adoption.
However, I concur that Bitcoin Core should match its default setting for
`mempoolfullrbf` to the behavior of miners, and there appears to be
palpable evidence that a supermajority of the hashrate has enabled
`mempoolfullrbf`.
Murch
--
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/6f6177b4-4fd3-4c22-ad13-97d430d7d0bc%40murch.one.
^ permalink raw reply [flat|nested] 37+ messages in thread
* [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-19 12:41 ` /dev /fd0
@ 2024-07-19 23:56 ` Antoine Riard
2024-07-20 5:57 ` /dev /fd0
0 siblings, 1 reply; 37+ messages in thread
From: Antoine Riard @ 2024-07-19 23:56 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 12375 bytes --]
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/9c4c2a65-2c87-47f1-85d1-137c32099fb7n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 15012 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
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
0 siblings, 1 reply; 37+ messages in thread
From: Antoine Riard @ 2024-07-19 23:58 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 15101 bytes --]
Hi Peter,
> A is a low fee-rate transaction with opt-in disabled. When it is
broadcast, it
> reaches 100% of nodes.
>
> A2 is a full-RBF double-spend of A. When it is broadcast, it reaches all
> nodes/miners with full-RBF enabled, replacing A. Full-RBF nodes do in fact
> relay A2 to non-full-rbf nodes they're peered with. But those nodes
reject A2
> as it is a full-RBF replacement.
>
> We are *not* trying to limit A2 to a single miner, or do any kind of
> simultaneous broadcast. We don't need to.
Okay, I see. Effectively, the attack holds are you're describing as
transaction A2
will propagate along the `mempoolfullrbf=1` transaction-relay network
paths. I think
the initial description could have been clearer with this additional
observation, as
somehow I think there is the low-odd marginal situation where the attacker
broadcasting
full-node is randomly peered with only transaction-relay `mempoolfullrbf=0`
neighboring
nodes, and as such the bandwidth waste denial-of-service negligeable.
This is correct there is no concurrent broadcast necessarily involved.
> The % of miners/nodes that accept B isn't particularly relevant; this is
an
> attack primarily against nodes that have full-RBF disabled (though those
nodes
> will waste the bandwidth of their full-RBF peers).
Yes I agree with this observation. In a world where a supermajority of
miners is running
full-rbf as policy settings, I'll let what the corrollorary means in terms
of transaction-relay
network decentralization to be fully explained by someone else.
> Again, the attack does not depend on a single miner receiving A2. Indeed,
it
> works fine even if 100% of hash power is mining A2.
>
> Also, A2 isn't necessarily what gets mined. A2 can be broadcast with a
fee-rate
> only slightly higher than A that is still below the minimum economic
fee-rate,
> and then replaced later with an even higher fee-rate double-spend that is
a
> high enough fee-rate to get mined. Remember that RBF Rule #6 prohibits a
> replacement if the fee-rate of the replacement is lower than the directly
> replaced transaction.
Yes, I think what you're pointing is what makes the attack quite
interesting as there
is no strict attacker necessity for A2 to be mined at some point in time
for the attack
effect to play out. Note, see bitcoin core issue #14895 were few years ago
such mempool
adaptive attacker were pondered about transaction pinnings affecting
lightning.
> You're not far off. But I believe you are still misunderstanding details,
as
described above.
See above.
> Correct. Although it's probably simplest to just pick a B that is large
enough
to max out the mempool limits on its own.
I believe this observation can be still game out more at the advantage of
the attacker.
> Again, A2 does not need to pay a high enough fee-rate to be economical to
mine.
> So there are no particular latency requirements between when A, B, and A2
are
> broadcast.
>
> All that is necessary for this class of attack is there be at least one
miner
> willing to mine A2 (or a further double-spend), who rejects A.
Yes, I see more what is interesting with this attack by playing out on
network
mepool feerate segment asymmetries arising from transaction-relay policy
divergence.
> This attack is simply a variant of attacks that were publicly disclosed
months
> ago, that Core has chosen not to respond to at all, so the exact timeframe
> isn't very relevant. This is not actually a new class of attack; the whole
> point of my disclosure is to show that Core does not actually care about
this
> class of attack by showing they won't even bother to fix the simplest
possible
> version, even when the fix is trivial.
As I said few months ago, I don't think this is a new class of attacks in
bitcoin dev
circles conversations about network DoS. To point out more historical
conversation this
class of attack was pointed out by gmaxwell years ago on the bitcoin core
pr #16698 few
years ago [0].
[0] https://github.com/bitcoin/bitcoin/pull/16698#issuecomment-571399346
I think rather to accuse people currently maintaining the bitcoin-core sec
mailing list
of malovencly, it's more constructive to question if this set of people
still have the
competency and bitcoin security culture to diligently understand and
address this class
of attacks (and with gmaxwell in its own recent words on another channel
being far far less
active in bitcoin protocol dev it's not a purely rhetorical question).
In general, there is no necessity to assign to malevolency what can be
assigned to
genuine incompetence or willful laziness.
> But anyway, I disclosed on Jul 7th giving a 7 day deadline before I'd
publish
> if I couldn't get any response. I publicly verified that achow (and
others) had
> received my email on Jul 10th, with achow promising a response. On Jul
12th
> rather than replying, Core closed my full-RBF pull-req that fixes this
issue.
> On Jul 15th I reached out again, and after someone else pointed out that
> failing to reply to me was degrading the value of the security mailing
list,
> and finally got achow and glozow to respond in a perfunctory fashion
(glozow
> recommended that I open a new full-RBF pull-req). So I published this on
Jul
> 18th after my replies to achow and glozow didn't get any response. This
whole
> time no-one has asked me to not publish this attack; asking me to keep
this
> fact about mempools a secret would be rather duplicitous given that a key
> argument for TRUC/V3 relies on "free" relay attacks not being possible.
>
> Core could have *easily* responded by simply merging my pull-req to enable
> full-RBF by default, a trivial change that has had lots of ACKs from
technical
> reviewers, which ~100% of hash power has adopted. No-one reasonable would
have
> questioned merging that pull-req. They chose not to do so, proving my
point
> that none of this has anything to do with a genuine technical concern.
Okay, with more information I think both achow and glozow answers are
reasonable
in matters of formal responsiveness.
That they pointed out to carry with a public process to fix that category
of attacks
only give more ground at my hypothesis highlighted above that it can be a
problem of
security culture knowledge or lack of experience know-how in handling
"half" / full
covert fixes.
Sadly, I must say this is matching my historical experience with the
bitcoin security
mailing list (and I had far more seasoned interlocutors) or the ones of
other security
issues reporters I'm aware off.
> I was previously on the bitcoin-security mailing list for years, and
almost
> every disclosed attack has gotten a response within 24 hours, with the
longest
> about 72 hours (I just skimmed through my archives to double check).
Failing to
> respond at all is very unusual.
As said in one my previous email, I'm still curious about achow101
explaining publicly
why you have been kicked-out of the bitcoin-security mailing list, when you
were certainly
more senior than achow101 in matters of base-layer security issues or even
hard technical
issues like consensus interactions (e.g bip65). I'll re-iterate my respect
towards achow101
as a maintainer from years of collaboration, though this is a topic worthy
of an answer.
Without a public answer under 2 weeks, I'll remove achow101 from among the
future security
reports recipients I can make about the bitcoin core project, be it a
report that is codebase-only
or any security issues related to the base layer and affecting all
full-nodes implementations
or the mining stack.
Under the information shared and from my perspective, achow101 argued
conduct of playing
for unknown reasons with an adminstrative communication endpoint creates a
moral hazard
and this would be further unethical for me as a security researcher to
share sensitive security
information with that bitcoin maintainer.
Best,
Antoine
ots hash: e8a6473014d397c35779fd4d165bea20ea03c14091078d6140b3394c6a88a464
Le vendredi 19 juillet 2024 à 19:27:40 UTC+1, Peter Todd a écrit :
> On Fri, Jul 19, 2024 at 02:52:29PM +0100, Antoine Riard wrote:
> > Hi Peter,
> >
> > > I think you need to re-read the attack carefully before we discuss this
> > > further. The % of hash power mining full-rbf does not significantly
> > change the
> > > cost efficiency of the attack as long as the fee-rate of the B
> > transaction(s)
> > > is below the minimum economic fee-rate necessary for miners to mine a
> > > transaction. Above the minimum economic fee-rate, the cost efficiency
> is
> > an
> > > essentially linear function of % of full-rbf miners.
> >
> > This is not the % of hash power mining _full-rbf_ I was pointing to, just
> > the indistinct
> > total % of hash power mining.
> >
> > In my understanding, this is the scenario:
> > - Alice broadcasts small size, low-feerate transaction opt-in disabled A
> to
> > 99% of the miners+network nodes mempools
> > - Alice broadcasts a double-spend of A, a high-feerate transaction A2 to
> > Mark, a single miner
> > - Network nodes does not relay transaction A to Mark and vice-versa Mark
> > does not relay transaction A2 to network nodes
>
> Here I think you've misunderstood the attack.
>
> A is a low fee-rate transaction with opt-in disabled. When it is
> broadcast, it
> reaches 100% of nodes.
>
> A2 is a full-RBF double-spend of A. When it is broadcast, it reaches all
> nodes/miners with full-RBF enabled, replacing A. Full-RBF nodes do in fact
> relay A2 to non-full-rbf nodes they're peered with. But those nodes reject
> A2
> as it is a full-RBF replacement.
>
> We are *not* trying to limit A2 to a single miner, or do any kind of
> simultaneous broadcast. We don't need to.
>
> > - Alice broadcasts a child B of transaction A to 99% of the
> miners+network
> > nodes mempools
>
> The % of miners/nodes that accept B isn't particularly relevant; this is an
> attack primarily against nodes that have full-RBF disabled (though those
> nodes
> will waste the bandwidth of their full-RBF peers).
>
> > - Mark, the single miner confirms in a block A2, rendering as a waste A+B
> > network bandwidth
>
> Again, the attack does not depend on a single miner receiving A2. Indeed,
> it
> works fine even if 100% of hash power is mining A2.
>
> Also, A2 isn't necessarily what gets mined. A2 can be broadcast with a
> fee-rate
> only slightly higher than A that is still below the minimum economic
> fee-rate,
> and then replaced later with an even higher fee-rate double-spend that is a
> high enough fee-rate to get mined. Remember that RBF Rule #6 prohibits a
> replacement if the fee-rate of the replacement is lower than the directly
> replaced transaction.
>
> > Correct if I'm wrong with this scenario and if it does not match the
> attack
> > vector you're describing.
>
> You're not far off. But I believe you are still misunderstanding details,
> as
> described above.
>
> > The child B can be extended with a full chain of useless children within
> > max mempool limits.
>
> Correct. Although it's probably simplest to just pick a B that is large
> enough
> to max out the mempool limits on its own.
>
> > The attack efficiency (i.e the total vB of bandwidth network waste) is
> > dependent on the delay
> > by which transaction A2 is included in Mark's block template and
> > subsequently mined. Back to
> > my observation, higher are Mark hashrate ressources, less there is
> latency
> > to let transaction B
> > spontaneously propagate on the network, or for Alice to (re)-broadcast in
> > cycle.
>
> Again, A2 does not need to pay a high enough fee-rate to be economical to
> mine.
> So there are no particular latency requirements between when A, B, and A2
> are
> broadcast.
>
> All that is necessary for this class of attack is there be at least one
> miner
> willing to mine A2 (or a further double-spend), who rejects A.
>
> > All that said, I think my open question to you at the beginning of my
> > answer is still there,
> > i.e how much time has been left between the private report of this issue
> to
> > the sec mailing
> > list and the public disclosure of your email.
>
> This attack is simply a variant of attacks that were publicly disclosed
> months
> ago, that Core has chosen not to respond to at all, so the exact timeframe
> isn't very relevant. This is not actually a new class of attack; the whole
> point of my disclosure is to show that Core does not actually care about
> this
> class of attack by showing they won't even bother to fix the simplest
> possible
> version, even when the fix is trivial.
>
> But anyway, I disclosed on Jul 7th giving a 7 day deadline before I'd
> publish
> if I couldn't get any response. I publicly verified that achow (and
> others) had
> received my email on Jul 10th, with achow promising a response. On Jul 12th
> rather than replying, Core closed my full-RBF pull-req that fixes this
> issue.
> On Jul 15th I reached out again, and after someone else pointed out that
> failing to reply to me was degrading the value of the security mailing
> list,
> and finally got achow and glozow to respond in a perfunctory fashion
> (glozow
> recommended that I open a new full-RBF pull-req). So I published this on
> Jul
> 18th after my replies to achow and glozow didn't get any response. This
> whole
> time no-one has asked me to not publish this attack; asking me to keep this
> fact about mempools a secret would be rather duplicitous given that a key
> argument for TRUC/V3 relies on "free" relay attacks not being possible.
>
> Core could have *easily* responded by simply merging my pull-req to enable
> full-RBF by default, a trivial change that has had lots of ACKs from
> technical
> reviewers, which ~100% of hash power has adopted. No-one reasonable would
> have
> questioned merging that pull-req. They chose not to do so, proving my point
> that none of this has anything to do with a genuine technical concern.
>
> I was previously on the bitcoin-security mailing list for years, and almost
> every disclosed attack has gotten a response within 24 hours, with the
> longest
> about 72 hours (I just skimmed through my archives to double check).
> Failing to
> respond at all is very unusual.
>
> --
> 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/4d950527-4430-49f2-8e38-3755bc58e301n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 17011 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
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
0 siblings, 1 reply; 37+ messages in thread
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-07-20 0:46 UTC (permalink / raw)
To: bitcoindev
On 07/19/2024 07:58 PM, Antoine Riard wrote:
> As said in one my previous email, I'm still curious about achow101
> explaining publicly
> why you have been kicked-out of the bitcoin-security mailing list, when
> you were certainly
> more senior than achow101 in matters of base-layer security issues or
> even hard technical
> issues like consensus interactions (e.g bip65). I'll re-iterate my
> respect towards achow101
> as a maintainer from years of collaboration, though this is a topic
> worthy of an answer.
I am not the one that removed Peter from the mailing list, nor do I even
have the login(s) to do so.
There was a discussion amongst several members of the security list
about who was on the list, and who should be on the list. Given that the
security list is the _Bitcoin Core_ security list, we determined that
the people who should be on the list are people who still actively
contribute to the project. As Peter Todd no longer actively contribute
code nor code review to the project, we decided that it didn't make
sense to continue to have him on the list.
My recollection is that multiple other people were removed from the list
for the same reason at the same time.
Ava
--
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/4f7eddff-9e2d-4beb-bcc6-832584cb939d%40achow101.com.
^ permalink raw reply [flat|nested] 37+ messages in thread
* [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
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:12 ` Antoine Riard
0 siblings, 2 replies; 37+ messages in thread
From: /dev /fd0 @ 2024-07-20 5:57 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 14845 bytes --]
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/fd1e1dd3-ffda-416b-9bc8-900d0b69c8c1n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 17942 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-18 15:56 [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd
` (2 preceding siblings ...)
2024-07-19 18:26 ` [bitcoindev] " Murch
@ 2024-07-20 6:41 ` David A. Harding
2024-07-20 15:03 ` Peter Todd
` (3 more replies)
3 siblings, 4 replies; 37+ messages in thread
From: David A. Harding @ 2024-07-20 6:41 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoindev
On 2024-07-18 05:56, Peter Todd wrote:
> I disclosed it to the bitcoin-security mailing list as a test: does
> Bitcoin Core actually care about free relay attacks?
They do. Several free relay attacks that were present in earlier
versions of Bitcoin were eliminated in later versions. New proposals
are evaluated for their potential to create new permanent free relay
vectors. The discovery of free relay is almost always reason enough to
reject a proposal.
The free relay attack you describe in your email and the type of free
relay enabled by your replace-by-feerate (RBFr) proposal can allow an
attacker to 10x to 100x the amount of bandwidth used network wide by
relay nodes for a cost of $10,000 to $50,000 a day (or, as you mention,
effectively for free if they were going to send a bunch of transactions
anyway).
I cannot imagine what would make you think that protocol developers are
not concerned about attacks that could drive large numbers of relay
nodes off the network for a cost easily affordable to any well-funded
adversary.
In this case, you've found a specific instance (full-RBF vs signaled
RBF) of a well-known general problem (optional policies leading to
mempool inconsistencies, allowing free relay) and appear to be arguing
that devs don't care about free relay because they refused to reverse a
previous decision (to not change the RBF configuration default) that has
been hotly debated multiple times.
An alternative interpretation is that they (1) do care about free relay,
(2) recognize that solving free relay is a hard problem that requires
research and development, and (3) refuse to be forced into restarting
debate on an already overdiscussed issue that gets nobody closer to
fundamental solutions.
> 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
Differences in node policy leading to mempool inconsistencies (which
allows free relay) is a well known problem that's the result of Bitcoin
being an open protocol based on free/libre software (two things I think
we all want). Many protocol developers have attempted to address the
problem over the years, most recently just a few months ago with an
updated proposal for using weak blocks as a first step to address
"diverging mempool policies".[1]
A currently unsolved problem is not necessarily an unavoidable problem
and it seems reasonable to me for devs to be skeptical of proposals like
RBFr that add to the list of things that enable free relay.
> I believe the authors of [BIP431...] don't want to admit that they've
> wasted a large amount of engineering time on a bad proposal.
You've previously argued against designing contract protocols to depend
CPFP-style fee bumping for their offchain transactions, however that is
what is widely used by LN today and it appears to be what LN and other
offchain protocol developers want to use in the future. If we accept
that, at least for the purposes of argument, what can we do to improve
CPFP fee bumping for LN?
All we really need at this point is to enable package relay so that
parent transactions are no longer subject to a dynamic mempool minimum
when they're bundled with a high-feerate child. Preliminary support for
that should be released in the next major version of Bitcoin Core, with
improved support being worked on for later releases.
Package relay is the only thing we need at this point because the
existing LN protocol makes use of CPFP carve-out, which minimizes
transaction pinning issues.
However, another substantial Bitcoin Core improvement, cluster mempool,
is incompatible with CPFP carve-out. TRUC is an alternative to CPFP
carve-out that is easy to reason about, easy to use, more general in
nature (good news for newer contract protocols), and which can possibly
be automatically applied to existing LN onchain transactions, allowing
cluster mempool to be deployed ASAP without requiring any significant
changes to anyone else's software.
As you've shown[2], the main downside of TRUC transactions (if we're
going to depend on CPFP-style fee bumping anyway) is that users of TRUC
transactions who have a malicious counterparty might need to pay a
slightly higher onchain feerate than they would need to pay under the
same situation with CPFP carve-out. However, the increase is small
enough that most honest parties should be able to afford it, so there's
no incentive for a counterparty to do it. I don't think we need to be
overly concerned about large numbers of LN users suddenly performing a
malicious action that does not benefit them and does not put the network
at risk.
The alternative to TRUC that you've proposed is replace-by-feerate
(RBFr). This is also compatible with existing LN transactions and it's
conceptually super simple (I assume the code is too), which is
wonderful. However, it's downsides are:
1. It fundamentally enables a significant amount of free relay. I'll
sketch a super basic attack at the end of this email that costs 0.55
BTC per day ($67,000 USD) to 100x the amount of bandwidth used by
relay nodes. I'm sure more efficient attacks are possible.
An attacker who is able to consume an excessive amount of relay node
bandwidth at relatively low cost may be able to create both
short-term and long-term problems for all Bitcoin users. If the
created problems result in a rapid increase in user feerates, then
free relay attacks become cheaper due to low feerate transactions
being automatically evicted from the bottom of the mempool.
2. It may allow empting the mempool at relatively low cost. An attacker
sending just 750 transactions at the top mempool feerate can
guarantee eviction of every honest user's transactions. The attacker
can then replace 300 MB of transactions with a single 43,179 vbyte
transaction. Even if the replacement transaction pays 100
sats/vbyte, when you compare that to the 1,000,000 vbytes of
next-block transactions each miner lost, the miner is only earning an
effective feerate of 4.3 sats/vbyte.
Further, it's easy to imagine situations where evicting
time-sensitive transactions from mempools might allow theft of funds
in excess of a few thousand dollars (my immediate thoughts go to
situations involving watchtowers).
3. Limiting the worst-case free relay and excessive mempool eviction
requires additional rules (e.g. one-shot RBFr) that are challenging
to implement and analyze at present, as several devs have noted[3].
Both implementation and analysis should become much easier if cluster
mempool is deployed (also noted by devs), but the deployment of
cluster mempool requires removal of CPFP carve-out, and removal of
CPFP carve-out requires either the upgrade of thousands of LN nodes
and channels or a drop-in solution (ideally one that can be analyzed
independently from cluster mempool, like TRUC).
To me, TRUC seems like an excellent approach. It's something that can
be evaluated independently of cluster mempool but which can help allow
that deployment to proceed (in addition to the other previously
described benefits that TRUC brings).
There have already been multiple public discussions about how improved
RBF policies can be implemented once cluster mempool is available, many
of which bring us closer to something like RBFr in a way that's easier
to prove won't enable free relay, and perusing that seems to me like a
productive outlet if you are interested.
> this is quite an odd case of Core politics
I began writing this reply to force me to examine your claims for
myself. You have a long history of noticing things other people missed.
I was worried that some compelling point of yours was being ignored as
the result of past controversies.
After several hours of writing and thinking, I don't see any problems
with the current approach using TRUC or with the general lack of
interest in RBFr solutions at this time. I've tried to explain how I
arrived at my conclusions at each step and I welcome any corrections.
Thanks,
-Dave
[1] https://delvingbitcoin.org/t/second-look-at-weak-blocks/805
[2]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022211.html
[3]
https://bitcoinops.org/en/newsletters/2024/02/07/#proposal-for-replace-by-feerate-to-escape-pinning
---
A simple free relay attack using RBFr
## Constants
100,000 vbytes == ~400,000 bytes
A 1-input, 1-output P2TR scriptpath spend with the maximum amount
of witness data allowed by Bitcoin Core defaults
111 vbytes == 162 bytes
A 1-input, 1-output P2TR keypath spend
## Attack
- Attacker obtains 500,000 UTXOs
- For each UTXO
- At the dynamic mempool minimum, broadcasts a 100,000 vbyte (400,000
byte) transacton.
- Waits for it to propagate.
- At 1.25x the dynamic mempool minimum, broadcasts a RBFr replacement
that is 111 vbytes (162 bytes).
## Analysis
- At 162 bytes each, 500,000 transactions is 81 MB. I think that will
fit in a default-sized mempool.
- The total amount of transaction data relayed is 500_000 * (400_000 +
162), or about 200 GB.
- The typical daily bandwidth requirement of a blocks-only node is
roughly 2.5 MB * 144, or about 0.36 GB per day. Ideally a relaying
node is about the same due to compact blocks, but realistically, it's
a small multiple of that. Call it 2 GB per day.
- This implies the attack push each RBFr relay node to use 100x a
non-RBFr relay node.
- At 111 vbytes each, 500,000 transactions is 55.5 million vbytes. At
my nodes current mempoolminfee (1 sat/vb), that's 55.5 million sats,
or 0.55 BTC (about $37,000 USD).
- This analysis ignores the cost of obtaining the UTXOs and possibly
later consolidating them, but it also ignores some easy optimizations
such as batching the replacements.
--
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/c6593662694f9d4a4fe999dd432f87ff%40dtrt.org.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-19 18:26 ` [bitcoindev] " Murch
@ 2024-07-20 14:10 ` Peter Todd
0 siblings, 0 replies; 37+ messages in thread
From: Peter Todd @ 2024-07-20 14:10 UTC (permalink / raw)
To: Murch; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]
On Fri, Jul 19, 2024 at 02:26:44PM -0400, Murch wrote:
> On 7/18/24 11:56, Peter Todd wrote:
> > # Summary
> >
> > This is a public disclosure of a vulnerability that I previously disclosed to
> > the bitcoin-security mailing list.
>
> It seems redundant to point out that some transactions are only relayed by a
> subset of a node population if there are multiple diverging mempool policies
> with significant adoption.
1) So you agree with me in general that this is just one of a large class of
"free" relay attacks?
2) You should re-read my analysis. You do _not_ need significant adoption of
the diverging mempool policy for this attack to work. Literally a single miner
is sufficient.
Indeed, as I pointed out one month ago on this mailing list, a "free" relay
"attack" was happening by accident due to good samaritans attemping to spend
Lightning anchor outputs to clean up the UTXO set, accidentally pinning
Lightning nodes in the process, and the fact that Libre Relay's RBFR was
already sufficent to get the intended transactions mined:
"Libre Relay v27.1 released with lower 1.25x replacement threshold" - Jun 20th 2024
https://groups.google.com/g/bitcoindev/c/n2GNmnz0btw/m/IemUVKBoAgAJ
> However, I concur that Bitcoin Core should match its default setting for
> `mempoolfullrbf` to the behavior of miners, and there appears to be palpable
> evidence that a supermajority of the hashrate has enabled `mempoolfullrbf`.
Thanks!
--
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/ZpvFaRDoNbzSOgIq%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
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 2:10 ` Antoine Riard
` (2 subsequent siblings)
3 siblings, 2 replies; 37+ messages in thread
From: Peter Todd @ 2024-07-20 15:03 UTC (permalink / raw)
To: David A. Harding; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 5133 bytes --]
On Fri, Jul 19, 2024 at 08:41:07PM -1000, David A. Harding wrote:
> On 2024-07-18 05:56, Peter Todd wrote:
> > I disclosed it to the bitcoin-security mailing list as a test: does
> > Bitcoin Core actually care about free relay attacks?
>
> They do. Several free relay attacks that were present in earlier
> versions of Bitcoin were eliminated in later versions.
I can think of two such eliminated attacks, both significantly more "free" than
anything we're discussing here, and interestingly, both attacks that I
participated in discovering or fixing:
1) The fact that non-final transactions were accepted into the mempool, even if
they wouldn't be valid for thousands of years (IIRC I exploited the
mempool.space mixer with this).
2) nSequence replacement, which replace-by-fee ultimately fixed.
What other "free" relay attacks can you think of that were fixed?
> New proposals
> are evaluated for their potential to create new permanent free relay
> vectors. The discovery of free relay is almost always reason enough to
> reject a proposal.
Yet even though Murch (I think quite accurately) said that the full-rbf "free"
relay attack was a fairly obvious attack, my pull-req to enable it sat for over
a year without any comment from Core... Surely, if Core was genuinely concerned
about these attacks, Core would rush to quietly fix them; we could have shipped
full-RBF by default something like six months ago.
And in spite of this apparent concern about "free" relay, I don't see anyone
trying to mitigate the "free" relay attack that the introduction of TRUC/V3
transactions will cause.
It's also notable that Core *introduced* a new form of "free" relay a few years
back with mempool expiration.
> The free relay attack you describe in your email and the type of free
> relay enabled by your replace-by-feerate (RBFr) proposal can allow an
> attacker to 10x to 100x the amount of bandwidth used network wide by
> relay nodes for a cost of $10,000 to $50,000 a day (or, as you mention,
> effectively for free if they were going to send a bunch of transactions
> anyway).
Did you actually read my One-Shot RBFR proposal? I covered DoS attacks:
https://petertodd.org/2024/one-shot-replace-by-fee-rate#denial-of-service-attacks
The *status quo* is that free relay attacks are unavoidable, because, at
minimum, you can always pull them off by simultaneous broadcast of
contradictory transactions (especially if you, eg, need to do consolidation
transactions anyway). RBFR does not change that.
> I cannot imagine what would make you think that protocol developers are
> not concerned about attacks that could drive large numbers of relay
> nodes off the network for a cost easily affordable to any well-funded
> adversary.
>
> In this case, you've found a specific instance (full-RBF vs signaled
> RBF) of a well-known general problem (optional policies leading to
> mempool inconsistencies, allowing free relay) and appear to be arguing
> that devs don't care about free relay because they refused to reverse a
> previous decision (to not change the RBF configuration default) that has
> been hotly debated multiple times.
...and your point is? Are you saying that Core developers put politics above
security, by refusing to fix a known "free" relay attack simply because it was
"hotly debated"?
> > 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
>
> Differences in node policy leading to mempool inconsistencies (which
> allows free relay) is a well known problem that's the result of Bitcoin
> being an open protocol based on free/libre software (two things I think
> we all want). Many protocol developers have attempted to address the
> problem over the years, most recently just a few months ago with an
> updated proposal for using weak blocks as a first step to address
> "diverging mempool policies".[1]
Weak blocks are not a solution to any of the "free" relay attacks I've
disclosed, and your source, https://delvingbitcoin.org/t/second-look-at-weak-blocks/805,
does not claim that they are a "free" relay solution.
Weak blocks simply aren't relevant until a miner has received a transaction and
found a weak block. By that point the "free" relay has already happened.
Anyway, before I spend time replying to the rest of your email, I think it'd be
helpful if you confirm two things to make sure we're actually on the same page:
1) Have you've read my One Shot RBFR proposal? In particular, my analysis of
DoS attacks *including* existing DoS attacks like simultaneous broadcast.
2) Do you agree or disagree with me that these existing DoS attacks are real?
--
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/ZpvRvRybauFFnhQV%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
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
1 sibling, 2 replies; 37+ messages in thread
From: Peter Todd @ 2024-07-20 15:08 UTC (permalink / raw)
To: /dev /fd0; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]
On Fri, Jul 19, 2024 at 10:57:40PM -0700, /dev /fd0 wrote:
> 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.
It's quite bizzare to use "off topic comments" as an excuse to close a pull-req
fixing a specific security vulnerability, assuming you actually care about that
vulnerability. As I've said elsewhere, Core could have easily and quietly
merged that pull-req as-is, possibly by having a few people write some obvious
ACK rationals.
The only good explanation for closing it is to further delay merging the
pull-req, as well as disclosing the vulnerability.
--
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/ZpvS2haduzUQiojV%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-20 15:03 ` Peter Todd
@ 2024-07-20 15:30 ` Peter Todd
2024-07-21 15:35 ` David A. Harding
1 sibling, 0 replies; 37+ messages in thread
From: Peter Todd @ 2024-07-20 15:30 UTC (permalink / raw)
To: David A. Harding; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 734 bytes --]
On Sat, Jul 20, 2024 at 03:03:25PM +0000, Peter Todd wrote:
> 1) The fact that non-final transactions were accepted into the mempool, even if
> they wouldn't be valid for thousands of years (IIRC I exploited the
> mempool.space mixer with this).
Brainfart! I mean, the blockchain.info space mixer obviously.
--
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/ZpvYJPB0B0aHczab%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
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
0 siblings, 1 reply; 37+ messages in thread
From: Antoine Riard @ 2024-07-21 2:06 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 5883 bytes --]
Hi Ava,
Thanks for the answer and the additional information.
I think this is unclear to me if Peter himself was part of the discussion
amongst several members of the security list on re-examining if their
presence
and the ones of others was still worthy on the list, be it online or
offline.
I fully understrand this is a kind of conversation which certainly does not
warrant to be public, and I mostly agree with that. Yet I believe it's
ethically
bordeline to not invite someome to express its own viewpoint in asking to be
removal of its own access, especially in a project that aims to be
decentralized
and a technnical meritocracy (-- I believe an ideal we aspire all).
Beyond, and forgive the expression if it's a bit rude, I believe it's a bit
"naive",
"short-sighted" as a position of the members of the security list, with
whatever
level of true consensus such removal has being done (-- and I'm not aware
there
was operational security emergency that justified such removal).
"Naive", as saying this is the _Bitcoin Core_ project list only can only
provoke blind
spot among the list members if the security issues are either affecting old
part of
the codebases that younger members have less experiences with (some parts
like consensus
or block-relay are modified only every 5 years) or novel factors from
upstream or downstream
(e.g the internet networking stack or implications on deployed contract
protocols like
lightning). On both the former and latter criterias, I think Peter overly
meets the bar.
"Short-sighted", as it's making the members of the security list both party
and arbiter
of appreciating what is an _active_ contributor among themselves (all in a
very ethically
bordeline fashion). In my experience with lightning over the past years,
with discovering
more and more issues which in fact that arises from imperfect interfacting
with the base-layer,
I was progressively lead to spend more and more time on the core side as it
was natural to
have things fixed thhere (or at least advocate so). Of course, I was in
consequence less active
on the lighting development day-to-day side. Did it make be less competent
to be responsive when
issues affected lighting ? I don't believe so (though obviously I'll let
other lightning experts
corroborate or infirm this self-cogtratulory statement of mine).
Same for Peter, if he had make the choices to consencrate its open-source
time on more long-term
things like transaction denial-of-service vectors or analyzing new
consensus changes proposals
(whatever the long-erm outcome, R&D is a stochastic process -- his track
records with things like
bip65 shall give him a positive presumption)
I think as a community to give such cultural margin to do so, even if it's
as the trade-off of
less review on day-to-day core things with a more reduced global scope like
the gui or the wallet.
When you've big sh*t hitting the fan like inflation bugs or level DB 2013
unexpected fork you
prefer have experts with a decade of experience to collaborate with, and
sharing the same cultural
and ethical norms of the active contributors evaluated by numbers on
commits on the last single-digit
years.
I'll repropose Peter admission on the security list mailing list in the
coming weeks by opening an
issue on the bitcoin-meta repository, once this current mailing list thread
has slowed down a bit,
or at least the technical analysis has been dissociated from the
proceedings which have all been
bundle in a big message. In my very personal opinion, I still trust more
Peter competence and experience
than some other people I know who are on the security mailing list.
All that said I appreciate your answer and I'm satisfied from the personal
role you've have played
in the matter with, and be reassured I'll keep you among the recipient of
future security issues with
a potential impact on bitcoin core that I might find or be aware off.
Best,
Antoine
ots hash: db441b51684ad3a6897f67d42c74ccfcb9a4ffed40d4bdbe30a2edd867ccdd54
Le samedi 20 juillet 2024 à 01:50:25 UTC+1, Ava Chow a écrit :
> On 07/19/2024 07:58 PM, Antoine Riard wrote:
> > As said in one my previous email, I'm still curious about achow101
> > explaining publicly
> > why you have been kicked-out of the bitcoin-security mailing list, when
> > you were certainly
> > more senior than achow101 in matters of base-layer security issues or
> > even hard technical
> > issues like consensus interactions (e.g bip65). I'll re-iterate my
> > respect towards achow101
> > as a maintainer from years of collaboration, though this is a topic
> > worthy of an answer.
>
> I am not the one that removed Peter from the mailing list, nor do I even
> have the login(s) to do so.
>
> There was a discussion amongst several members of the security list
> about who was on the list, and who should be on the list. Given that the
> security list is the _Bitcoin Core_ security list, we determined that
> the people who should be on the list are people who still actively
> contribute to the project. As Peter Todd no longer actively contribute
> code nor code review to the project, we decided that it didn't make
> sense to continue to have him on the list.
>
> My recollection is that multiple other people were removed from the list
> for the same reason at the same time.
>
> Ava
>
>
--
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/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 6638 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-20 6:41 ` David A. Harding
2024-07-20 15:03 ` Peter Todd
@ 2024-07-21 2:10 ` Antoine Riard
2024-07-22 15:10 ` Peter Todd
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 17:13 ` [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd
3 siblings, 1 reply; 37+ messages in thread
From: Antoine Riard @ 2024-07-21 2:10 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 25607 bytes --]
Hi Dave,
Thanks for your thoughtful answer (even if its wasn't addressed to me
primarly).
> I cannot imagine what would make you think that protocol developers are
> not concerned about attacks that could drive large numbers of relay
> nodes off the network for a cost easily affordable to any well-funded
> adversary.
From my experience code reviewing the wallet / mempool re-broadcast of few
years ago, free tx-relay / bandwidth waste attacks were far to be
understood
or plainly weighted by some contributors of a newer generations, including
by
the own champion of the proposal. The proposal was finally abandonned when a
more senior dev came up with quantitative analysis of code changes [0].
[0] https://github.com/bitcoin/bitcoin/pull/21061#issuecomment-851563105
> In this case, you've found a specific instance (full-RBF vs signaled
> RBF) of a well-known general problem (optional policies leading to
> mempool inconsistencies, allowing free relay) and appear to be arguing
> that devs don't care about free relay because they refused to reverse a
> previous decision (to not change the RBF configuration default) that has
> been hotly debated multiple times.
I think what is more interesting and noteworhty in the whole line of
reaosning
of Peter with the present disclosure is how much the adversial effect is
favor
by the supermajority of miners running `mempoolfullrbf` [1].
[1] https://github.com/bitcoin/bitcoin/pull/28132#issue-1817178316
That Peter's sample calls for empirical measures of their own by other
contributors
that can only make the whole review process and consensus-building towards
a change
or the status quo better. Being able to empirically measure how bitcoin
full-node
software is practically used by end-users, be it miners, second-layers
nodes, simple
coins wallet users, exchanges, and making that a protocol development
standard I believe
that how we progress as an ecosystem.
> An alternative interpretation is that they (1) do care about free relay,
> (2) recognize that solving free relay is a hard problem that requires
> research and development, and (3) refuse to be forced into restarting
> debate on an already overdiscussed issue that gets nobody closer to
> fundamental solutions.
The strong statement we have from the bitcoin core about attacks and
vulnerabilities
mitigation, which probably represents the viewpoint of many generation of
contributors is the following as old than few weeks ago:
"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."
[2] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w
Under those conditions, where it took 9 years for the bitcoin core project
to disclosre
some vulnerabilitires, personally I'm more likely to understand that the
bitcoin core project
is under-staffed is competent experts to keep public disclosure in
reasonable timeframe (-- at
least equivalent to the kernel world), and as corollorary to fully evaluate
technical proposal
with all its strength and weaknesses.
Saying an "already overdiscussed issues that gets nobody closer to
fundamental solutions" is
insulting for Peter, honestly.
> Many protocol developers have attempted to address the problem over the
years, most recently just
> a few months ago with an updated proposal for using weak blocks as a
first step to address
> "diverging mempool policies".[1]
With all my respect for the developers involved in the design of this
proposal who are skilled bitcoin
engineers in themsleves, I think betting on the "weak blocks" idea is a
dead end in itself as in relying
on the slow convergence idea, that it's at the heart of the ghost, block
dag and other ideas we've seen
10 years ago to make mining income "more fair" among geographically
distributed mining pools.
I conjecture, it's a dead end as you will more or less have to re-build a
secondary consensus algorithm
in the block-relay stack or in the mining stack, which is going to run
intou its own mempool convergence
issues again, in a recursive fashion.
I believe such proposal is more an instance of the ill-managed conflict of
interest blockstream-style
syndrom that bitcoin protocol devs, who ever they care can be affected
with. In the present instance:
"My employer has gained a commercial interest in mining business recently
so now let's advocate a very
complex bitcoin p2p protocol changes, rather than humbly realize that
mining economic units are more akin
to a traditional energy company which not really in the less than 2-decades
corporate DNA of said employer,
and why actually the economic units results of our mining division are
floppy and now we engage in bitcoin
core changes at our advantage" (in my own reasonable view -- though I can
only invite the "weak block" employer
company corporate board to comment here if they diverge on my analysis).
From a more pure technical viewpoint, I think bitcoin core compact blocks
block-relay handling code, after
7 years of having been merged in bitcoin core has still `TODO` left in the
codebase, and it could be an area
worhty of more testing / cleaning refactoring, I'm just saying by the way.
> You've previously argued against designing contract protocols to depend
> CPFP-style fee bumping for their offchain transactions, however that is
> what is widely used by LN today and it appears to be what LN and other
> offchain protocol developers want to use in the future. If we accept
> that, at least for the purposes of argument, what can we do to improve
> CPFP fee bumping for LN?
As an offchain protocol developers which has been involved in the majority
of technical conversations,
implementations and deployment of the "anchor output" upgrade, I believe on
the long-term CPFP-style fee-bumping
of contract protocol, including lighting, is not the most robust technical
solutions. I think anyone can check
in the bitcoin optech anchor output glossary the numerous vulnerabilities
that have plagued this fee-bumping
solutions over the past years.
Pursuing on that trend will more only probably lead to a current state of
what we have with DNS / BGP at the
internet-stack level, which are still constantly the sources of new
security vulnerabilitiies and single-point
of-failure securiyt solutions like X509 certificates management (do we wish
bitcoin to be plagued by crowdstyle
technical incident 15 years from now ? I'm not so sure).
> All we really need at this point is to enable package relay so that
> parent transactions are no longer subject to a dynamic mempool minimum
> when they're bundled with a high-feerate child. Preliminary support for
> that should be released in the next major version of Bitcoin Core, with
> improved support being worked on for later releases.
>
> Package relay is the only thing we need at this point because the
> existing LN protocol makes use of CPFP carve-out, which minimizes
> transaction pinning issues.
I don't disagree on package relay deployment at this stage, with the some
degree of technical skeptiscism
that shall accomaphny all p2p proposals. Let's remember things that have
been rollback or slowly rollout like
bip37 or `MEMPOOL` p2p message.
> However, another substantial Bitcoin Core improvement, cluster mempool,
> is incompatible with CPFP carve-out. TRUC is an alternative to CPFP
> carve-out that is easy to reason about, easy to use, more general in
> nature (good news for newer contract protocols), and which can possibly
> be automatically applied to existing LN onchain transactions, allowing
> cluster mempool to be deployed ASAP without requiring any significant
> changes to anyone else's software.
If you or anoyone think TRUC as an alternative to the CPFP as a transsction
pinning mitigation as argued
in its merged BIP is easy to reason on, thanks to communicate your
lightning node pubkey, with TRUC patch
applied and a GPG-signed message authorizing me to demonstrate the security
properties of this solutions have
not been submitted to a fully contradictory evaluation.
I pointed out few years ago that relying on mempool-policy changes as a
fully hardening solution was very
likely limited to mitigate econommical-based pinnings (i.e bip125 absolute
fee rule), and this was before
the discovery of new transaction-relay jamming vector (a terminology
catched by your himself in some
private conversation if my memory is correct) like replacement cycling
attacks [4].
[4]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019084.html
"high-half" in this post
corresponds to what roughly is bip331 today.
> I don't think we need to be overly concerned about large numbers of LN
users suddenly performing a malicious
> action that does not benefit them and does not put the network at risk.
Have a look on base-layer based exploitation description that could provoke
a large number of LN users, without
their own involvement, that could put the base-network at risk [5].
[5]
https://github.com/jamesob/mempool.work?tab=readme-ov-file#failure-one-mempool-to-rule-them-all
> The alternative to TRUC that you've proposed is replace-by-feerate
> (RBFr). This is also compatible with existing LN transactions and it's
> conceptually super simple (I assume the code is too), which is
> wonderful. However, it's downsides are:
About replace-by-feerate, I think it's a solution that have downside on its
own, especially for
second-layers like lightning. I never took time to write a canonical post
as infosec ethics would ask
me to notice lightning maininters to do first, even if the vulnerability
idea has been vaguely sketched
out to few years ago.
On all your replace-by-feerate analysis, I think it deserves a thread on
its own, as somehow the issue
can have interactions with degree of fulfillness of miner block templates,
a conversation we had when V3
was proposed as solution [6].
[6]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html
and following answers
> but the deployment of cluster mempool requires removal of CPFP carve-out,
and removal of CPFP carve-out requires
> either the upgrade of thousands of LN nodes and channels or a drop-in
solution (ideally one that can be analyzed
> independently from cluster mempool, like TRUC)
And as I observed on one of the V3 PR threads and corresponding
conversations, the CPFP carve-out do not provide
security to lightning implementation as (a) old revoked commitment
transactions can be used to fail the CPFP bump,
V3 or not V3 and (b) there is no base-layer p2p protocol discovery of txids
[6]. And I won't observe that when I looked
on lightning implementations code, only Eclair have minimal correct
implementation of remote valid commitment transactions
broadcast, not the other one as it's not even in the bolt spec.
[6] https://github.com/bitcoin/bitcoin/pull/28948
So unless someone argued to the contrary, saying TRUC was needed to then
deploy cluster mempool is an intellectual
fallacy, of which the origin could likely arises from the back macket of PR
reviews trading happening in the bitcoin core
project for people to advance their own pet projects. At the very least,
from my own code review of the folks bitcoin
core PR related to this line of deployment you're exposing, I'm not sure
they're understanding so well cross-layers issues [7].
[7] https://github.com/bitcoin/bitcoin/pull/29427
I think you're rather making the points that the current group of most
active bitcoin core contributors, are indeed
skilled bitcoin engineers, vetted with project-management know-how and
informed about bitcoin technical history and know
how to stay polite and civil (most of the time) to create a fruitful
technical conversation atmosphere. They're not necessarily
the most astute and adversarial minds to spot on the flight the weakness of
new technical proposals, neither with the character
to say so _at the cost_ of sometimes being rude and negative in the
communication tone. And this in line with my point above
recalling that the bitcoin core group of people themselves estimate
themsleves they don't do a good job in term of security
vulnerabilties handling.
> There have already been multiple public discussions about how improved
> RBF policies can be implemented once cluster mempool is available, many
> of which bring us closer to something like RBFr in a way that's easier
> to prove won't enable free relay, and perusing that seems to me like a
> productive outlet if you are interested.
I already reviewed some parts of cluster mempool. Fundamentally, economical
mempool pinnings for second-layers (bip125 absolute
fee) with pre-signed time-sensitive transactions arises from a world where
there is (a) an asynchronicity of mempools and (b) one
cannot guess feerates at block + 1 (-- let's say in a deterministic fashion
as understood by traditional cryptographic litterature
when doing cryptanalysis). Better RBF policies won't solve that, including
RBFr.
> After several hours of writing and thinking, I don't see any problems
> with the current approach using TRUC or with the general lack of
> interest in RBFr solutions at this time. I've tried to explain how I
> arrived at my conclusions at each step and I welcome any corrections.
On my personal perspective, and after careful considerations of all the
technical points you've raised. I still think TRUC
has a lot of problems. RBRFr too has technical problems. About TRUC I think
it's an acceptable temporary solution to minimize
the pinning surface of lightning implementations, pending for the design of
a better solution (more likely at the consensus-level,
here consistently as I pointed out 3 years ago). Though we shall be honest
with ourselves and not engage in overdue security theater
about TRUC properties.
To finish, I'll re-assert what is my appreciation. Currently, I don't think
the bitcoin core folks handling the security list has
necessarily the proven level of competency to fully evaluate the issues
reported by Peter, however I don't believe in the present
case they have done anything wrong infosec ethically-wise.
Best,
Antoine
ots hash: 001e8dc7fbced4cb9ea30c8a3b7fa22dc1b07939e7125cb46e7a3d65b256caa7
Le samedi 20 juillet 2024 à 07:45:24 UTC+1, David A. Harding a écrit :
> On 2024-07-18 05:56, Peter Todd wrote:
> > I disclosed it to the bitcoin-security mailing list as a test: does
> > Bitcoin Core actually care about free relay attacks?
>
> They do. Several free relay attacks that were present in earlier
> versions of Bitcoin were eliminated in later versions. New proposals
> are evaluated for their potential to create new permanent free relay
> vectors. The discovery of free relay is almost always reason enough to
> reject a proposal.
>
> The free relay attack you describe in your email and the type of free
> relay enabled by your replace-by-feerate (RBFr) proposal can allow an
> attacker to 10x to 100x the amount of bandwidth used network wide by
> relay nodes for a cost of $10,000 to $50,000 a day (or, as you mention,
> effectively for free if they were going to send a bunch of transactions
> anyway).
>
> I cannot imagine what would make you think that protocol developers are
> not concerned about attacks that could drive large numbers of relay
> nodes off the network for a cost easily affordable to any well-funded
> adversary.
>
> In this case, you've found a specific instance (full-RBF vs signaled
> RBF) of a well-known general problem (optional policies leading to
> mempool inconsistencies, allowing free relay) and appear to be arguing
> that devs don't care about free relay because they refused to reverse a
> previous decision (to not change the RBF configuration default) that has
> been hotly debated multiple times.
>
> An alternative interpretation is that they (1) do care about free relay,
> (2) recognize that solving free relay is a hard problem that requires
> research and development, and (3) refuse to be forced into restarting
> debate on an already overdiscussed issue that gets nobody closer to
> fundamental solutions.
>
> > 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
>
> Differences in node policy leading to mempool inconsistencies (which
> allows free relay) is a well known problem that's the result of Bitcoin
> being an open protocol based on free/libre software (two things I think
> we all want). Many protocol developers have attempted to address the
> problem over the years, most recently just a few months ago with an
> updated proposal for using weak blocks as a first step to address
> "diverging mempool policies".[1]
>
> A currently unsolved problem is not necessarily an unavoidable problem
> and it seems reasonable to me for devs to be skeptical of proposals like
> RBFr that add to the list of things that enable free relay.
>
> > I believe the authors of [BIP431...] don't want to admit that they've
> > wasted a large amount of engineering time on a bad proposal.
>
> You've previously argued against designing contract protocols to depend
> CPFP-style fee bumping for their offchain transactions, however that is
> what is widely used by LN today and it appears to be what LN and other
> offchain protocol developers want to use in the future. If we accept
> that, at least for the purposes of argument, what can we do to improve
> CPFP fee bumping for LN?
>
> All we really need at this point is to enable package relay so that
> parent transactions are no longer subject to a dynamic mempool minimum
> when they're bundled with a high-feerate child. Preliminary support for
> that should be released in the next major version of Bitcoin Core, with
> improved support being worked on for later releases.
>
> Package relay is the only thing we need at this point because the
> existing LN protocol makes use of CPFP carve-out, which minimizes
> transaction pinning issues.
>
> However, another substantial Bitcoin Core improvement, cluster mempool,
> is incompatible with CPFP carve-out. TRUC is an alternative to CPFP
> carve-out that is easy to reason about, easy to use, more general in
> nature (good news for newer contract protocols), and which can possibly
> be automatically applied to existing LN onchain transactions, allowing
> cluster mempool to be deployed ASAP without requiring any significant
> changes to anyone else's software.
>
> As you've shown[2], the main downside of TRUC transactions (if we're
> going to depend on CPFP-style fee bumping anyway) is that users of TRUC
> transactions who have a malicious counterparty might need to pay a
> slightly higher onchain feerate than they would need to pay under the
> same situation with CPFP carve-out. However, the increase is small
> enough that most honest parties should be able to afford it, so there's
> no incentive for a counterparty to do it. I don't think we need to be
> overly concerned about large numbers of LN users suddenly performing a
> malicious action that does not benefit them and does not put the network
> at risk.
>
> The alternative to TRUC that you've proposed is replace-by-feerate
> (RBFr). This is also compatible with existing LN transactions and it's
> conceptually super simple (I assume the code is too), which is
> wonderful. However, it's downsides are:
>
> 1. It fundamentally enables a significant amount of free relay. I'll
> sketch a super basic attack at the end of this email that costs 0.55
> BTC per day ($67,000 USD) to 100x the amount of bandwidth used by
> relay nodes. I'm sure more efficient attacks are possible.
>
> An attacker who is able to consume an excessive amount of relay node
> bandwidth at relatively low cost may be able to create both
> short-term and long-term problems for all Bitcoin users. If the
> created problems result in a rapid increase in user feerates, then
> free relay attacks become cheaper due to low feerate transactions
> being automatically evicted from the bottom of the mempool.
>
> 2. It may allow empting the mempool at relatively low cost. An attacker
> sending just 750 transactions at the top mempool feerate can
> guarantee eviction of every honest user's transactions. The attacker
> can then replace 300 MB of transactions with a single 43,179 vbyte
> transaction. Even if the replacement transaction pays 100
> sats/vbyte, when you compare that to the 1,000,000 vbytes of
> next-block transactions each miner lost, the miner is only earning an
> effective feerate of 4.3 sats/vbyte.
>
> Further, it's easy to imagine situations where evicting
> time-sensitive transactions from mempools might allow theft of funds
> in excess of a few thousand dollars (my immediate thoughts go to
> situations involving watchtowers).
>
> 3. Limiting the worst-case free relay and excessive mempool eviction
> requires additional rules (e.g. one-shot RBFr) that are challenging
> to implement and analyze at present, as several devs have noted[3].
> Both implementation and analysis should become much easier if cluster
> mempool is deployed (also noted by devs), but the deployment of
> cluster mempool requires removal of CPFP carve-out, and removal of
> CPFP carve-out requires either the upgrade of thousands of LN nodes
> and channels or a drop-in solution (ideally one that can be analyzed
> independently from cluster mempool, like TRUC).
>
> To me, TRUC seems like an excellent approach. It's something that can
> be evaluated independently of cluster mempool but which can help allow
> that deployment to proceed (in addition to the other previously
> described benefits that TRUC brings).
>
> There have already been multiple public discussions about how improved
> RBF policies can be implemented once cluster mempool is available, many
> of which bring us closer to something like RBFr in a way that's easier
> to prove won't enable free relay, and perusing that seems to me like a
> productive outlet if you are interested.
>
> > this is quite an odd case of Core politics
>
> I began writing this reply to force me to examine your claims for
> myself. You have a long history of noticing things other people missed.
> I was worried that some compelling point of yours was being ignored as
> the result of past controversies.
>
> After several hours of writing and thinking, I don't see any problems
> with the current approach using TRUC or with the general lack of
> interest in RBFr solutions at this time. I've tried to explain how I
> arrived at my conclusions at each step and I welcome any corrections.
>
> Thanks,
>
> -Dave
>
> [1] https://delvingbitcoin.org/t/second-look-at-weak-blocks/805
> [2]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022211.html
> [3]
>
> https://bitcoinops.org/en/newsletters/2024/02/07/#proposal-for-replace-by-feerate-to-escape-pinning
>
> ---
> A simple free relay attack using RBFr
>
> ## Constants
>
> 100,000 vbytes == ~400,000 bytes
> A 1-input, 1-output P2TR scriptpath spend with the maximum amount
> of witness data allowed by Bitcoin Core defaults
>
> 111 vbytes == 162 bytes
> A 1-input, 1-output P2TR keypath spend
>
> ## Attack
>
> - Attacker obtains 500,000 UTXOs
>
> - For each UTXO
>
> - At the dynamic mempool minimum, broadcasts a 100,000 vbyte (400,000
> byte) transacton.
>
> - Waits for it to propagate.
>
> - At 1.25x the dynamic mempool minimum, broadcasts a RBFr replacement
> that is 111 vbytes (162 bytes).
>
> ## Analysis
>
> - At 162 bytes each, 500,000 transactions is 81 MB. I think that will
> fit in a default-sized mempool.
>
> - The total amount of transaction data relayed is 500_000 * (400_000 +
> 162), or about 200 GB.
>
> - The typical daily bandwidth requirement of a blocks-only node is
> roughly 2.5 MB * 144, or about 0.36 GB per day. Ideally a relaying
> node is about the same due to compact blocks, but realistically, it's
> a small multiple of that. Call it 2 GB per day.
>
> - This implies the attack push each RBFr relay node to use 100x a
> non-RBFr relay node.
>
> - At 111 vbytes each, 500,000 transactions is 55.5 million vbytes. At
> my nodes current mempoolminfee (1 sat/vb), that's 55.5 million sats,
> or 0.55 BTC (about $37,000 USD).
>
> - This analysis ignores the cost of obtaining the UTXOs and possibly
> later consolidating them, but it also ignores some easy optimizations
> such as batching the replacements.
>
--
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/99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 28823 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-20 5:57 ` /dev /fd0
2024-07-20 15:08 ` Peter Todd
@ 2024-07-21 2:12 ` Antoine Riard
1 sibling, 0 replies; 37+ messages in thread
From: Antoine Riard @ 2024-07-21 2:12 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-20 15:08 ` Peter Todd
@ 2024-07-21 2:13 ` Antoine Riard
2024-07-21 6:16 ` /dev /fd0
1 sibling, 0 replies; 37+ messages in thread
From: Antoine Riard @ 2024-07-21 2:13 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2314 bytes --]
Hi Peter,
> It's quite bizzare to use "off topic comments" as an excuse to close a
pull-req
> fixing a specific security vulnerability, assuming you actually care
about that
> vulnerability.
Do not assign to malovelence what can be assigned to genuine incompentence
or willful laziness.
In the present case, it's all to bet that the moderators close the PRs,
without being
aware of your reported security issue on the mailing list. This what you
expect in
a open-source community managing sensitive security information, where it
is formally
segregated between actors. I'm certainly not trusting will-ark with bitcoin
security
information, at least anything beyond begnign issues.
> As I've said elsewhere, Core could have easily and quietly
> merged that pull-req as-is, possibly by having a few people write some
obvious
> ACK rationals.
I think this is the kind of issues, given the plausibility we still have
laggards
of when `mempoolfullrbf` was introduced almost 2 years ago to reconsider
their
bitcoin infrastructure deployment, or 0conf acceptance flow. It's always
polite
and it can only help building strong cultural norms in an ecosystem where
the economic
traffic is deal with more and more by codebase which are not bitcoin core.
> The only good explanation for closing it is to further delay merging the
> pull-req, as well as disclosing the vulnerability.
I think this is the issue where it is worhty to purse the conservation:
https://github.com/bitcoin-core/meta/issues/5
All that said, I'll re-advocate your integration to the bitcoin security
mailing list by re-opening an issue on the github repository ?
Thanks to confirm you're okay with that (this can be done in private).
Very pragmatically, I'm trusting you more than most of the folks on the
list right now if I have issues to report.
Best,
Antoine
ots hash: 6c6ab1f4264c63245063a35da7f29f9e874a152a68e521b7f2ca2a972584a95d
--
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/a7ae8eee-11c8-48ea-80f8-4411741c3d3en%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 2790 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-20 15:08 ` Peter Todd
2024-07-21 2:13 ` Antoine Riard
@ 2024-07-21 6:16 ` /dev /fd0
1 sibling, 0 replies; 37+ messages in thread
From: /dev /fd0 @ 2024-07-21 6:16 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 2832 bytes --]
Hi Peter,
I agree that handling of vulnerability reports could be improved, although
I have less expectations from bitcoin core to acknowledge any feedback.
Here are a few things that we can do to improve the process:
- Report vulnerabilities anonymously and share real identity with
disclosure later if required.
- Send the email to achow101 or sipa or fanquake and keep
security@bitcoincore•org in Cc.
- Lets create a hall of fame webpage which has the name of all developers
who reported vulnerabilities along with other details. Community could also
donate directly to developers.
- Do not expect response on weekends and wait for at least 7-30 days before
full disclosure if vulnerability report is ignored.
Maybe you and others on mailing list could add suggest more improvements.
/dev/fd0
floppy disk guy
On Saturday, July 20, 2024 at 3:12:46 PM UTC Peter Todd wrote:
> On Fri, Jul 19, 2024 at 10:57:40PM -0700, /dev /fd0 wrote:
> > 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.
>
> It's quite bizzare to use "off topic comments" as an excuse to close a
> pull-req
> fixing a specific security vulnerability, assuming you actually care about
> that
> vulnerability. As I've said elsewhere, Core could have easily and quietly
> merged that pull-req as-is, possibly by having a few people write some
> obvious
> ACK rationals.
>
> The only good explanation for closing it is to further delay merging the
> pull-req, as well as disclosing the vulnerability.
>
> --
> 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/955e7097-ca7a-452a-953f-718aca14cdc6n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4032 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
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
1 sibling, 2 replies; 37+ messages in thread
From: David A. Harding @ 2024-07-21 15:35 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoindev
On 2024-07-20 05:03, Peter Todd wrote:
> What other "free" relay attacks can you think of that were fixed?
The two you mention were the two I had in mind.
> Did you actually read my One-Shot RBFR proposal?
Yes. It didn't provide any examples of RBFr free relay and I wanted to
see whether a basic RBFr free relay attack would use significantly more,
significantly less, or about the same amount of bandwidth per dollar
spent as other free relay attacks. My conclusion is that it's about the
same.
> Weak blocks are not a solution to any of the "free" relay attacks I've
> disclosed and your source does not claim that they are a "free" relay
> solution.
It does not explicitly say that, but it does say: "bonus use-cases:
“Forcible insertion” of transactions that are incentive-compatible but
violate anti-DoS rules".
For example, in some of the scenarios you describe, the attacker sends
an appealing transaction to miners and then sends less appealing
versions of that transaction to relay nodes. If the appealing
transaction enters the top mempool and gets included in a weak block,
relay nodes will stop relaying less appealing variations minutes to
hours before they otherwise would.
Weak blocks also provide a decentralized DoS-resistant mechanism for
voluntarily communicating all sorts of information from miners to other
miners and relay nodes. That makes them an excellent tool for resolving
any attack that depends on miners and relay nodes having a divergent set
of transactions.
> 1) Have you've read my One Shot RBFR proposal? In particular, my
> analysis of DoS attacks *including* existing DoS attacks like
> simultaneous broadcast.
>
> 2) Do you agree or disagree with me that these existing DoS attacks
> are real?
Yes, I've read your proposal, and I agree those attacks are plausible.
In my mind, the major difference between those free relay attacks
and RBFR free relay attacks is how solvable they are.
I think it's easy to sketch a significant mitigation to all free relay
attacks (including RBFR):
- Reduce the maximum size of both relayable transactions and in-mempool
packages, e.g. from 100,000 vbytes to 1,000 vbytes.
- Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB.
- Increase the default mempool feerate floor, e.g. from e.g. from 1
sat/vb to 100 sat/vb.
That would break relay of many existing presigned transactions,
potentially leading to money loss, and would break other existing
usecases, not to mention introduce other problems. However, I think
it's sufficient to prove that a mitigation to free relay is possible
without rendering the network unusable.
Of course, an ideal solution wouldn't require placing any additional
constraints on mempool policy. For the case of free relay due to
divergent mempool policies, maybe it's something that could be done with
transaction set reconciliation (~erlay), functions for allowing
independent nodes to come to consistent conclusions about the best
revenue set of transactions (~cluster mempool), P2P relay of non-obvious
cluster linearizations[1], and miners voluntarily committing to their
mempool contents in candidate blocks and P2P relaying those commitments
in weak blocks.
Innovations like that don't work for RBFR. If mempool policy is kept
the same, free relay attacks with RBFR remain equally effective no
matter what mechanisms we implement to improve preconsensus consistency.
If pure RBFR is added and clever protocol developers find ways to
largely fix other free relay attacks, then devs will either need to
significantly restrict mempool policy anyway or will need to restrict or
remove RBFR to make Bitcoin Core safe. Given that, it seems to me like
a very reasonable decision not to add pure RBFR and to wait until better
tools like cluster mempool become available before evaluating
significant changes to RBF policy (like one-shot RBFR).
Thanks,
-Dave
[1]
https://github.com/bitcoinops/bitcoinops.github.io/pull/1421#discussion_r1415834695
--
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/d57a02a84e756dbda03161c9034b9231%40dtrt.org.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
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:35 ` Antoine Riard
0 siblings, 2 replies; 37+ messages in thread
From: 'Ava Chow' via Bitcoin Development Mailing List @ 2024-07-21 20:17 UTC (permalink / raw)
To: bitcoindev
On 07/20/2024 10:06 PM, Antoine Riard wrote:
> "Naive", as saying this is the _Bitcoin Core_ project list only can only
> provoke blind
> spot among the list members if the security issues are either affecting
> old part of
> the codebases that younger members have less experiences with (some
> parts like consensus
> or block-relay are modified only every 5 years) or novel factors from
> upstream or downstream
> (e.g the internet networking stack or implications on deployed contract
> protocols like
> lightning). On both the former and latter criterias, I think Peter
> overly meets the bar.
Peter was not the only "senior" person on the security list. Obviously I
will not disclose non-public information, but certainly there are people
on the security list who are just as, if not more, senior than Peter.
Furthermore, the "old parts" still do get changed, and someone who no
longer actively contributes to the project is more likely to be unaware
of how the code actually works today, even if they are familiar with
components that change infrequently.
> When you've big sh*t hitting the fan like inflation bugs or level DB
> 2013 unexpected fork you
> prefer have experts with a decade of experience to collaborate with, and
> sharing the same cultural
> and ethical norms of the active contributors evaluated by numbers on
> commits on the last single-digit
> years.
Not being on the list does not preclude him from being consulted if the
need arises.
With the two examples you provide, I am not aware of Peter being
actively involved in the resolution of both of those, whereas there are
current members of the list who were.
In general though, it is not clear to me how it was beneficial to have
Peter on the security list, nor how not having him is directly harmful.
In the 2 years that I have been on the security list, I was unaware that
Peter was a recipient until shortly before he was removed. My
understanding is that others who have been on the list longer than me
were also unaware.
Ava
>
> I'll repropose Peter admission on the security list mailing list in the
> coming weeks by opening an
> issue on the bitcoin-meta repository, once this current mailing list
> thread has slowed down a bit,
> or at least the technical analysis has been dissociated from the
> proceedings which have all been
> bundle in a big message. In my very personal opinion, I still trust more
> Peter competence and experience
> than some other people I know who are on the security mailing list.
>
> All that said I appreciate your answer and I'm satisfied from the
> personal role you've have played
> in the matter with, and be reassured I'll keep you among the recipient
> of future security issues with
> a potential impact on bitcoin core that I might find or be aware off.
>
> Best,
> Antoine
> ots hash: db441b51684ad3a6897f67d42c74ccfcb9a4ffed40d4bdbe30a2edd867ccdd54
>
> Le samedi 20 juillet 2024 à 01:50:25 UTC+1, Ava Chow a écrit :
>
> On 07/19/2024 07:58 PM, Antoine Riard wrote:
> > As said in one my previous email, I'm still curious about achow101
> > explaining publicly
> > why you have been kicked-out of the bitcoin-security mailing
> list, when
> > you were certainly
> > more senior than achow101 in matters of base-layer security
> issues or
> > even hard technical
> > issues like consensus interactions (e.g bip65). I'll re-iterate my
> > respect towards achow101
> > as a maintainer from years of collaboration, though this is a topic
> > worthy of an answer.
>
> I am not the one that removed Peter from the mailing list, nor do I
> even
> have the login(s) to do so.
>
> There was a discussion amongst several members of the security list
> about who was on the list, and who should be on the list. Given that
> the
> security list is the _Bitcoin Core_ security list, we determined that
> the people who should be on the list are people who still actively
> contribute to the project. As Peter Todd no longer actively contribute
> code nor code review to the project, we decided that it didn't make
> sense to continue to have him on the list.
>
> My recollection is that multiple other people were removed from the
> list
> for the same reason at the same time.
>
> Ava
>
> --
> 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
> <mailto:bitcoindev+unsubscribe@googlegroups•com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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/a8eac5f2-b85a-434f-868e-eba7fd2558c6%40achow101.com.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-21 15:35 ` David A. Harding
@ 2024-07-21 20:25 ` Peter Todd
2024-07-24 0:38 ` Antoine Riard
1 sibling, 0 replies; 37+ messages in thread
From: Peter Todd @ 2024-07-21 20:25 UTC (permalink / raw)
To: David A. Harding; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 8772 bytes --]
On Sun, Jul 21, 2024 at 05:35:31AM -1000, David A. Harding wrote:
> On 2024-07-20 05:03, Peter Todd wrote:
> > What other "free" relay attacks can you think of that were fixed?
>
> The two you mention were the two I had in mind.
Right. So in the entire history of Core, we have two quite ridiculous free
relay attacks that got fixed, and we *added* a significant free-relay
vulnerability by adding mempool expiration. We also added a free-relay
vulnerability, and a fill-and-dump vulnerability, with the mempool size limit.
That's not evidence that Core actually cares much about "free" relay.
> > Did you actually read my One-Shot RBFR proposal?
>
> Yes. It didn't provide any examples of RBFr free relay and I wanted to
> see whether a basic RBFr free relay attack would use significantly more,
> significantly less, or about the same amount of bandwidth per dollar
> spent as other free relay attacks. My conclusion is that it's about the
> same.
Good. So you basically agree with me that RBFR does _not_ significantly change
the status quo.
I'll respond to the specifics of your RBFR analysis separately; it does *not*
apply to one-shot RBFR.
> > Weak blocks are not a solution to any of the "free" relay attacks I've
> > disclosed and your source does not claim that they are a "free" relay
> > solution.
>
> It does not explicitly say that, but it does say: "bonus use-cases:
> “Forcible insertion” of transactions that are incentive-compatible but
> violate anti-DoS rules".
>
> For example, in some of the scenarios you describe, the attacker sends
> an appealing transaction to miners and then sends less appealing
> versions of that transaction to relay nodes. If the appealing
> transaction enters the top mempool and gets included in a weak block,
> relay nodes will stop relaying less appealing variations minutes to
> hours before they otherwise would.
Yes, "minutes to hours". Transactions relay on the order of seconds to tens of
seconds. Weak blocks simply aren't relevant.
Also, the attacks I've described are ones that can be pulled off by having a
tiny minority of hash power mine a double spend. Weak blocks don't help you
there, as that tiny minority isn't likely to even find a weak block.
> Weak blocks also provide a decentralized DoS-resistant mechanism for
> voluntarily communicating all sorts of information from miners to other
> miners and relay nodes. That makes them an excellent tool for resolving
> any attack that depends on miners and relay nodes having a divergent set
> of transactions.
For weak blocks to be a solution, you at minimum need to take away the ability
of miners to choose what transactions they mine. For example, consider the
scenario where you do a "free" relay attack by broadcasting transactions that
OCEAN rejects, and then double-spending them via OCEAN _after_ the transactions
have been broadcast. Equally, you'd need to take away the ability of RBFR
miners to do the revenue maximizing thing: mining RBFR replacements.
I'll also second Antoine Riard's objections to this class of idea in general:
you're really proposing a secondary pseudo-consensus mechanism to solve the
problems in your first pseud-consensus mechanism.
> > 1) Have you've read my One Shot RBFR proposal? In particular, my
> > analysis of DoS attacks *including* existing DoS attacks like
> > simultaneous broadcast.
> >
> > 2) Do you agree or disagree with me that these existing DoS attacks
> > are real?
>
> Yes, I've read your proposal, and I agree those attacks are plausible.
> In my mind, the major difference between those free relay attacks
> and RBFR free relay attacks is how solvable they are.
>
> I think it's easy to sketch a significant mitigation to all free relay
> attacks (including RBFR):
>
> - Reduce the maximum size of both relayable transactions and in-mempool
> packages, e.g. from 100,000 vbytes to 1,000 vbytes.
>
> - Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB.
>
> - Increase the default mempool feerate floor, e.g. from e.g. from 1
> sat/vb to 100 sat/vb.
>
> That would break relay of many existing presigned transactions,
> potentially leading to money loss, and would break other existing
> usecases, not to mention introduce other problems. However, I think
> it's sufficient to prove that a mitigation to free relay is possible
> without rendering the network unusable.
The irony here is you've almost described a _good_ mitigation to "free" relay
attacks: just reduce the size of the default mempool. A big reason why we have
"free" relay attacks right now is because we allow transactions to be broadcast
that are uneconomical to mine; if you limit transaction broadcast to
transactions that are economical to mine in the near future, relay is more
expensive.
For miners, you can make a decent argument that they want to have on-hand a big
backlog of transactions in case mempools empty out; in my conversations with
miners almost all of them claim they run with much larger than default mempools
(eg >1GB). I've even discussed mempool emptying attacks and RBFR in this
context with miners: they didn't think they were an issue as replacing their
mempools was absurdly expensive.
Fee estimation of course can make use of knowing what backlog of transactions
exist. But I'm sure only a small minority of nodes do fee estimation.
A variant of this solution would be to just pick the minimum relay fee to be
some number N blocks worth of transactions "back" from the highest fee-rate tip
of the mempool. Obviously, this will be easier to implement with a cluster
mempool, and requires package relay for the CPFP case.
> Of course, an ideal solution wouldn't require placing any additional
> constraints on mempool policy. For the case of free relay due to
> divergent mempool policies, maybe it's something that could be done with
> transaction set reconciliation (~erlay), functions for allowing
Erlay (and transaction set reconciliation in general) does not help you
reconcile conflicting transactions. It simply lets you efficiently learn about
the total set of known transactions. Notice how the Erlay is based on WTXIDs,
and the BIP doesn't even talk about dealing with conflicts.
> independent nodes to come to consistent conclusions about the best
> revenue set of transactions (~cluster mempool),
That's quite irrelevant as RBFR _is_ the highest revenue policy in lots of
situations. That's one reason why in my discussions with miners/pools, they're
interested in implementing it (mining pools have very low profit margins, so
every cent counts, and RBFR replacements are reasonably common already). Mining
pools implemented full-RBF against the wishes of Core for the same reason:
full-RBF earns you more revenue, and I made it easy to implement.
Implementing one-shot RBFR is probably going to be quite a bit cleaner with
cluster mempools, as it'll provide a nice way to rapidly determine what the
minimum economic fee-rate is to get into the next (N) blocks. (though you can
do this in a less clean way by just periodically assembling a trial block and
recording the value, or using the fee estimation code)
Finally, why are clusters even relevant to "free" relay? Most "free" relay
attacks don't even need transaction packages. The really boring and unsolvable
"free" relay attack of simply broadcasting large transactions that conflict
with small ones is done with single transaction packages.
> P2P relay of non-obvious
> cluster linearizations[1], and miners voluntarily committing to their
> mempool contents in candidate blocks and P2P relaying those commitments
> in weak blocks.
As I explained above, weak blocks is not a "free" relay solution.
> Innovations like that don't work for RBFR. If mempool policy is kept
> the same, free relay attacks with RBFR remain equally effective no
> matter what mechanisms we implement to improve preconsensus consistency.
I could also argue that magic ponies will solve "free" relay. We have to weight
that hope with the likelyhood it will happen; none of the technical
advancements you have mentioned even come close.
Anyway, I'll reply to the rest of your other email separately.
--
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/Zp1utYduhnWf4oA4%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
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-07-24 0:35 ` Antoine Riard
1 sibling, 1 reply; 37+ messages in thread
From: 'Anonymous User' via Bitcoin Development Mailing List @ 2024-07-22 1:59 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 9456 bytes --]
I came from some twitter discussion so I think this thread is trending. I
think we need to figure a way out onward.
Here is a last resort solution by launching this attack in production. We
should avoid making this last resort solution, but from what Peter Todd
said, below seems completely practical.
Please treat it as story reading and do not overthink that this is the way
to go.
- a few people in the list form a group and fork bitcoin core and apply the
patch from Peter Todd
- work with a few miners to massively perform the free relay attacks and
other mempool related attacks in an effort to force mining pools and miners
to switch from bitcoin core into the fork in order for their nodes to
continue running in a healthy manner
- build a free service for file transfer or VPN taking advantage of rbf in
the Bitcoin network and make it a public good that millions of users can
use, causing most of the mempool transactions to be conflicting (due to
different implementations of rbf) and therefore wallets have to eventually
stop broadcasting transactions to bitcoin core nodes (which could be using
a completely new list of seed nodes, disabling the existing seed node
list), and non-bitcoin-core nodes, in order to have more healthy
transaction flows and mempool data sharing, would start node-shopping by
disconnecting themselves from bitcoin core nodes and refusing to be their
peers
- core is forced to find a way onward, or the core gives up and archives
the bitcoin core repo
The damage is probably just a few days of slower transaction processing,
much smaller than the price spike caused by ordinals last year.
Democracy starts with people having different opinions that DO NOT need to
reconcile. So, it is not about how we get different people in this mail
list, or the non-public security list, to achieve the same opinions, like
whether full RBF is needed. It is about how Bitcoin can allow two groups of
people that have fundamentally different opinions and are unwilling and
impossible to reconcile. We can have 5-10 security disclosure mail lists by
different groups of people, and good-faith vulnerability reporters can
choose to exclusively report the bugs to some groups that the reporters
feel to be knowledgeable and responsive and, importantly, have the capacity
and the motivation to work on it.
I feel bad for Peter Todd. If I were him, I wouldn't report the bug. I
would sell the bug because I got nothing in return, but probably more
jealousy or more retaliation for being the only person serious about an
issue.
Btw, Peter already has a fork.
Ethereum has great software development process as well as its ecosystem.
Smart contracts get heavily audited not because people care about security.
It is because North Korea has successfully stolen probably hundreds of
millions of dollars from different projects and even causing some projects
to fall apart. This is in essence similar to, if one day Bitcoin has a
memory exploit issue that causes a massive amount of miners to lose coins
that they own, and the network again needs to decide whether to do a hard
fork, that is the time when we will be discussing if stopping development
in C/C++ and limiting Bitcoin core development to Rust and Rust only are
the way forward.
Thanks,
Anonymous user, as the floppy disk guy recommends this might be the best
way to engage in the mailing list onward
I strongly encourage people to try engaging in this email list anonymously.
It feels great to say things out loud without worrying about retaliation on
unrelated matters. Also, this should be permitted. We still don't know who
Satoshi is. If I were Satoshi, I probably also wouldn't report a bug I
know.
On Sunday, July 21, 2024 at 1:49:10 PM UTC-7 Ava Chow wrote:
> On 07/20/2024 10:06 PM, Antoine Riard wrote:
> > "Naive", as saying this is the _Bitcoin Core_ project list only can only
> > provoke blind
> > spot among the list members if the security issues are either affecting
> > old part of
> > the codebases that younger members have less experiences with (some
> > parts like consensus
> > or block-relay are modified only every 5 years) or novel factors from
> > upstream or downstream
> > (e.g the internet networking stack or implications on deployed contract
> > protocols like
> > lightning). On both the former and latter criterias, I think Peter
> > overly meets the bar.
>
> Peter was not the only "senior" person on the security list. Obviously I
> will not disclose non-public information, but certainly there are people
> on the security list who are just as, if not more, senior than Peter.
>
> Furthermore, the "old parts" still do get changed, and someone who no
> longer actively contributes to the project is more likely to be unaware
> of how the code actually works today, even if they are familiar with
> components that change infrequently.
>
> > When you've big sh*t hitting the fan like inflation bugs or level DB
> > 2013 unexpected fork you
> > prefer have experts with a decade of experience to collaborate with, and
> > sharing the same cultural
> > and ethical norms of the active contributors evaluated by numbers on
> > commits on the last single-digit
> > years.
>
> Not being on the list does not preclude him from being consulted if the
> need arises.
>
> With the two examples you provide, I am not aware of Peter being
> actively involved in the resolution of both of those, whereas there are
> current members of the list who were.
>
>
> In general though, it is not clear to me how it was beneficial to have
> Peter on the security list, nor how not having him is directly harmful.
> In the 2 years that I have been on the security list, I was unaware that
> Peter was a recipient until shortly before he was removed. My
> understanding is that others who have been on the list longer than me
> were also unaware.
>
> Ava
>
> >
> > I'll repropose Peter admission on the security list mailing list in the
> > coming weeks by opening an
> > issue on the bitcoin-meta repository, once this current mailing list
> > thread has slowed down a bit,
> > or at least the technical analysis has been dissociated from the
> > proceedings which have all been
> > bundle in a big message. In my very personal opinion, I still trust more
> > Peter competence and experience
> > than some other people I know who are on the security mailing list.
> >
> > All that said I appreciate your answer and I'm satisfied from the
> > personal role you've have played
> > in the matter with, and be reassured I'll keep you among the recipient
> > of future security issues with
> > a potential impact on bitcoin core that I might find or be aware off.
> >
> > Best,
> > Antoine
> > ots hash:
> db441b51684ad3a6897f67d42c74ccfcb9a4ffed40d4bdbe30a2edd867ccdd54
> >
> > Le samedi 20 juillet 2024 à 01:50:25 UTC+1, Ava Chow a écrit :
> >
> > On 07/19/2024 07:58 PM, Antoine Riard wrote:
> > > As said in one my previous email, I'm still curious about achow101
> > > explaining publicly
> > > why you have been kicked-out of the bitcoin-security mailing
> > list, when
> > > you were certainly
> > > more senior than achow101 in matters of base-layer security
> > issues or
> > > even hard technical
> > > issues like consensus interactions (e.g bip65). I'll re-iterate my
> > > respect towards achow101
> > > as a maintainer from years of collaboration, though this is a topic
> > > worthy of an answer.
> >
> > I am not the one that removed Peter from the mailing list, nor do I
> > even
> > have the login(s) to do so.
> >
> > There was a discussion amongst several members of the security list
> > about who was on the list, and who should be on the list. Given that
> > the
> > security list is the _Bitcoin Core_ security list, we determined that
> > the people who should be on the list are people who still actively
> > contribute to the project. As Peter Todd no longer actively contribute
> > code nor code review to the project, we decided that it didn't make
> > sense to continue to have him on the list.
> >
> > My recollection is that multiple other people were removed from the
> > list
> > for the same reason at the same time.
> >
> > Ava
> >
> > --
> > 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+...@googlegroups•com
> > <mailto:bitcoindev+...@googlegroups•com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
>
>
--
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/3f7d43bd-af9e-4af5-860a-223504bb4fcan%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 11764 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not
2024-07-20 6:41 ` David A. Harding
2024-07-20 15:03 ` Peter Todd
2024-07-21 2:10 ` Antoine Riard
@ 2024-07-22 11:45 ` Peter Todd
2024-07-22 16:43 ` David A. Harding
2024-07-22 17:13 ` [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd
3 siblings, 1 reply; 37+ messages in thread
From: Peter Todd @ 2024-07-22 11:45 UTC (permalink / raw)
To: David A. Harding; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 4191 bytes --]
On Fri, Jul 19, 2024 at 08:41:07PM -1000, David A. Harding wrote:
> 3. Limiting the worst-case free relay and excessive mempool eviction
> requires additional rules (e.g. one-shot RBFr) that are challenging
> to implement and analyze at present, as several devs have noted[3].
> Both implementation and analysis should become much easier if cluster
> mempool is deployed (also noted by devs), but the deployment of
> cluster mempool requires removal of CPFP carve-out, and removal of
> CPFP carve-out requires either the upgrade of thousands of LN nodes
> and channels or a drop-in solution (ideally one that can be analyzed
> independently from cluster mempool, like TRUC).
I'm going to answer this separately for the sake of easy citation in the
future. tl;dr: cluster RBFR makes the CPFP carve-out obsolete, fixing pinning
for existing implementations; TRUC meanwhile isn't even a drop-in solution, and
requires everyone to upgrade before cluster mempool is even possible.
To recap, the CPFP carve-out¹ is an exception to package size limits that
allows a single transaction to exceed those limits slighty, provided that the
transaction has only one unconfirmed ancestor. This is relevant to protocols
like Lightning, where your counterparty might try to pin a transaction by
spending one of the two anchor outputs with a large, low-fee, transaction such
that the total package size is just under the package limit. Notably, in this
scenario, there is *no* way for you to broadcast a CPFP without the CPFP
carve-out because regardless of fee-rate, your transaction will simply be
rejected due to it causing the package limit to be exceeded.
I won't comment on whether or not the cluster mempool is genuinely incompatible
with CPFP carveouts; I'm not convinced that's true. But that point is
irrelevant anyway. To understand why, let's look at package replacement.
Package replacement is the idea that we can do RBF with packages of
transactions. For situations where the CPFP carve-out is relevant, we can
instead evaluate the CPFP child transaction, and the parent transaction(s), as
a package and compare that package to the package consisting of the existing
child transaction(s), and the parent transaction. With RBF alone, that would
allow you to defeat a package size pin by paying more in fees than the
conflicting child transaction(s), reducing this scenario to a straightforward
BIP-125 Rule #3 total fees pin.
Actually implementing this type of package replacement is simple: if you
receive a single transaction with an unconfirmed parent, if the transaction is
rejected due to package limits, try again, treating it as a package
replacement.
Finally, with package (one-shot) RBFR, we defeat both the package size pin and
the Rule #3 pin: so long as your CPFP child transaction pays a higher fee-rate
than the conflicting large, low-fee-rate, child transaction(s) made by the
attacker, you can replace the conflict and get the parent transaction(s) mined.
The only thing protocols need to do is ensure that the combination of parent
transaction(s) and child CPFP doesn't itself exceed the package size limits,
which Lightning already does just fine.
This is a much better upgrade path than TRUC + cluster mempool. We don't have
to wait for existing Lightning users to upgrade and open new channels. Indeed,
we even fix existing pinning problems for existing Lightning implementations,
which RBFR is already² doing!. And we actually fix pinning in general, for all
use-cases, not just the narrow subset that can make use of TRUC.
# References
1) https://bitcoinops.org/en/topics/cpfp-carve-out/
2) https://groups.google.com/g/bitcoindev/c/n2GNmnz0btw
--
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/Zp5GW/yHzPB8wyjU%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-21 2:10 ` Antoine Riard
@ 2024-07-22 15:10 ` Peter Todd
2024-07-24 0:41 ` Antoine Riard
0 siblings, 1 reply; 37+ messages in thread
From: Peter Todd @ 2024-07-22 15:10 UTC (permalink / raw)
To: Antoine Riard; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 6384 bytes --]
On Sat, Jul 20, 2024 at 07:10:53PM -0700, Antoine Riard wrote:
>
> Hi Dave,
>
> Thanks for your thoughtful answer (even if its wasn't addressed to me
> primarly).
>
> > I cannot imagine what would make you think that protocol developers are
> > not concerned about attacks that could drive large numbers of relay
> > nodes off the network for a cost easily affordable to any well-funded
> > adversary.
>
> From my experience code reviewing the wallet / mempool re-broadcast of few
> years ago, free tx-relay / bandwidth waste attacks were far to be
> understood
> or plainly weighted by some contributors of a newer generations, including
> by
> the own champion of the proposal. The proposal was finally abandonned when a
> more senior dev came up with quantitative analysis of code changes [0].
>
> [0] https://github.com/bitcoin/bitcoin/pull/21061#issuecomment-851563105
An irony here is that rebroadcasting makes most "free" relay attacks *more*
expensive, not less. sdaftuar had some correct points, like avoiding bandwidth
spikes. But for any "free" relay attack based on broadcasting conflicting
transactions at different fee-rates, where the higher fee-rate transaction is
not mined, you get a better attack if the higher fee-rate transaction falls out
of node mempools, allowing the lower fee-rate conflict to be broadcast again.
If rebroadcasters ensure that nodes have the higher fee-rate tx, all you can do
to "reset" the attack is either get your UTXO(s) mined. Or use an even higher
fee-rate. Without rebroadcasting, you can wait for the expiry period to be
reached.
> > In this case, you've found a specific instance (full-RBF vs signaled
> > RBF) of a well-known general problem (optional policies leading to
> > mempool inconsistencies, allowing free relay) and appear to be arguing
> > that devs don't care about free relay because they refused to reverse a
> > previous decision (to not change the RBF configuration default) that has
> > been hotly debated multiple times.
>
> I think what is more interesting and noteworhty in the whole line of
> reaosning
> of Peter with the present disclosure is how much the adversial effect is
> favor
> by the supermajority of miners running `mempoolfullrbf` [1].
>
> [1] https://github.com/bitcoin/bitcoin/pull/28132#issue-1817178316
Not just miners: any node running with mempoolfullrbf=1 is going to waste less
bandwidth if someone actually does this attack.
> Under those conditions, where it took 9 years for the bitcoin core project
> to disclosre
> some vulnerabilitires, personally I'm more likely to understand that the
> bitcoin core project
> is under-staffed is competent experts to keep public disclosure in
> reasonable timeframe (-- at
> least equivalent to the kernel world), and as corollorary to fully evaluate
> technical proposal
> with all its strength and weaknesses.
>
> Saying an "already overdiscussed issues that gets nobody closer to
> fundamental solutions" is
> insulting for Peter, honestly.
Indeed. You'd think solid evidence, trivially verifiable by anyone, that almost
all miners had adopted full-rbf would be enough. Instead that evidence doesn't
even receive any acknowledgement.
> As an offchain protocol developers which has been involved in the majority
> of technical conversations,
> implementations and deployment of the "anchor output" upgrade, I believe on
> the long-term CPFP-style fee-bumping
> of contract protocol, including lighting, is not the most robust technical
> solutions. I think anyone can check
> in the bitcoin optech anchor output glossary the numerous vulnerabilities
> that have plagued this fee-bumping
> solutions over the past years.
RBF is way underused in protocols in general. And there have probably been
literally millions of dollars wasted on fees spent by inefficient CPFP
solutions when RBF (via pre-signed transactions) could have been used instead.
This financial figure will only get higher as Lightning gets more adoption. It
also limits Lightning in mass failure scenarios: every byte saved while force
closing a channel is room that could be used to force close another channel.
> I already reviewed some parts of cluster mempool. Fundamentally, economical
> mempool pinnings for second-layers (bip125 absolute
> fee) with pre-signed time-sensitive transactions arises from a world where
> there is (a) an asynchronicity of mempools and (b) one
> cannot guess feerates at block + 1 (-- let's say in a deterministic fashion
> as understood by traditional cryptographic litterature
> when doing cryptanalysis). Better RBF policies won't solve that, including
> RBFr.
I have to disagree here. The nature of protocols like Lightning is there is a
maximum amount that it's worth attempting to pay to get a transaction mined to
perform some action. There also a deadline to perform that action.
For example, an HTLC has a clear expiry time and value. *Even if* you have no
idea what fee-rates are needed to get a transaction mined, you can simply do
repeated RBF bumps at higher and higher fee-rates, ending at a fee-rate that
spends the entire value of the HTLC. As long as you do in fact have uncensored
access to miner mempools - as long as you haven't been sybil attacked - this
approach will do about as well as is possible, modulo pinning attacks. So our
job is now to simply fix the pinning attacks with better RBF policy.
IIUC, this RBF fee-bumping approach is exactly what the RBF sweeper introduced
in LND v0.18 does. Face with, eg, high blockspace demand the sum total of LND
RBF sweepers will result in the most valuable HTLCs and similar things being
mined, while less valuable transactions don't (ignoring pinning of course).
That's fine! That's the best we can do given a limited blockspace.
Traditional cryptography literature is not relevant here, as it's based on the
difficulty of mathematical problems, not economics; the security of L2
protocols is based on economics.
--
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/Zp52WDL4hV16CbKV%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not
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
0 siblings, 1 reply; 37+ messages in thread
From: David A. Harding @ 2024-07-22 16:43 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoindev
On 2024-07-22 01:45, Peter Todd wrote:
> TRUC meanwhile isn't even a drop-in solution, and requires everyone to
> upgrade before cluster mempool is even possible.
The proposed BIP for TRUC[1] is indeed entirely opt-in and would require
all users of CPFP-CO (e.g. LN anchors channels) to upgrade their
software and switch to a new commitment transactions format, which
currently requires closing and reopening all anchors channels. There's
work on improving upgrade mechanisms in LN, but it would still be a pain
and a major delay to cluster mempool to depend on every LN user
upgrading.
However, there has also been significant discussion and analysis[2] of
an
imbued-semantics form of TRUC that could be retroactively applied to
LN-style anchor outputs (which are the only users of CPFP-CO we know
about). In that case, nobody needs to upgrade before cluster mempool
becomes possible.
In my previous email, I assumed you were familiar with the imbued
semantics proposal; I'm sorry for the miscommunication.
-Dave
[1]
https://github.com/bitcoin/bips/blob/158acdbbbf8ef13f6b345b6281a96e88e20d2cf9/bip-truc.mediawiki#user-content-Specification
[2]
https://delvingbitcoin.org/t/analysis-of-attempting-to-imbue-ln-commitment-transaction-spends-with-v3-semantics/527
--
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/0eeb34c87b4cd7c9165983dc3a613550%40dtrt.org.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-20 6:41 ` David A. Harding
` (2 preceding siblings ...)
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 17:13 ` Peter Todd
3 siblings, 0 replies; 37+ messages in thread
From: Peter Todd @ 2024-07-22 17:13 UTC (permalink / raw)
To: David A. Harding; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 13924 bytes --]
On Fri, Jul 19, 2024 at 08:41:07PM -1000, David A. Harding wrote:
> > I believe the authors of [BIP431...] don't want to admit that they've
> > wasted a large amount of engineering time on a bad proposal.
>
> You've previously argued against designing contract protocols to depend
> CPFP-style fee bumping for their offchain transactions, however that is
> what is widely used by LN today and it appears to be what LN and other
> offchain protocol developers want to use in the future. If we accept
> that, at least for the purposes of argument, what can we do to improve
> CPFP fee bumping for LN?
To be clear, the reason why I came up with one-shot RBFR was _because_ I wanted
to find a pinning solution for CPFP (and SIGHASH_ANYONECANPAY) transactions. If
everything could use pure RBF, eg via pre-signed transcations, RBFR would be
much less useful.
> All we really need at this point is to enable package relay so that
> parent transactions are no longer subject to a dynamic mempool minimum
> when they're bundled with a high-feerate child. Preliminary support for
> that should be released in the next major version of Bitcoin Core, with
> improved support being worked on for later releases.
>
> Package relay is the only thing we need at this point because the
> existing LN protocol makes use of CPFP carve-out, which minimizes
> transaction pinning issues.
>
> However, another substantial Bitcoin Core improvement, cluster mempool,
> is incompatible with CPFP carve-out. TRUC is an alternative to CPFP
> carve-out that is easy to reason about, easy to use, more general in
> nature (good news for newer contract protocols), and which can possibly
> be automatically applied to existing LN onchain transactions, allowing
> cluster mempool to be deployed ASAP without requiring any significant
> changes to anyone else's software.
So as I explained in my stand-alone email, we can cleanly get rid of the CPFP
carve-out with RBFR *without* needing to change anyone else's software:
https://groups.google.com/g/bitcoindev/c/vfbF7QyVwPE/m/-ewtlB5-AQAJ
TRUC does _not_ allow cluster mempool to be deployed ASAP. It requires all
existing L2 protocols that need the CPFP carve-out to upgrade, and likely close
and reopen channels.
This is a massive downside to TRUC.
> As you've shown[2], the main downside of TRUC transactions (if we're
> going to depend on CPFP-style fee bumping anyway) is that users of TRUC
> transactions who have a malicious counterparty might need to pay a
> slightly higher onchain feerate than they would need to pay under the
> same situation with CPFP carve-out. However, the increase is small
> enough that most honest parties should be able to afford it, so there's
> no incentive for a counterparty to do it.
As I explained months ago, the oddly high 1000vB limit chosen in TRUC allows
attackers to make TRUC users pay significantly higher fee rates in many mempool
situations, including the situation we are in right now:
https://petertodd.org/2023/v3-txs-pinning-vulnerability
At the moment, a typical TRUC using LN transaction can, IIRC, be forced to pay
something like a 4x higher fee as the difference between "will confirm in the
next block" and "won't confirm for days, if ever", is less than 1sat/VB.
I suggested that limit be reduced to something closer to a typical CPFP
use-case, and my suggestion was rejected.
This gets even worse with keyless ephemeral outputs using TRUC, as *anyone* can
itercept one of those and create a pin. An attacker could, for example, run
compact block enabled nodes and simply wait for LN nodes using compact blocks
to broadcast keyless ephemeral output, CPFP-using transactions, detect those
transactions, and automatically pin them.
> The alternative to TRUC that you've proposed is replace-by-feerate
> (RBFr). This is also compatible with existing LN transactions and it's
> conceptually super simple (I assume the code is too), which is
> wonderful. However, it's downsides are:
>
> 1. It fundamentally enables a significant amount of free relay. I'll
> sketch a super basic attack at the end of this email that costs 0.55
> BTC per day ($67,000 USD) to 100x the amount of bandwidth used by
> relay nodes. I'm sure more efficient attacks are possible.
See my analysis at the end. You are analyzing the wrong thing, and missing the
fact that comparable attacks are already possible. Indeed, even attacks that
are probably much *worse*.
> An attacker who is able to consume an excessive amount of relay node
> bandwidth at relatively low cost may be able to create both
> short-term and long-term problems for all Bitcoin users. If the
> created problems result in a rapid increase in user feerates, then
> free relay attacks become cheaper due to low feerate transactions
> being automatically evicted from the bottom of the mempool.
Relay bandwidth and fee-rates don't have any direct connection in Bitcoin Core.
Fee-rates are set by users outbidding each other. Unless an attacker is willing
to outbid actual user transactions, paying money to do so, they can't make
fee-rates increase (modulo certain exploitable/broken fee-rate estimators
making bad assumptions about mempools, but that's not a new problem).
> 2. It may allow empting the mempool at relatively low cost. An attacker
> sending just 750 transactions at the top mempool feerate can
> guarantee eviction of every honest user's transactions. The attacker
> can then replace 300 MB of transactions with a single 43,179 vbyte
> transaction. Even if the replacement transaction pays 100
> sats/vbyte, when you compare that to the 1,000,000 vbytes of
> next-block transactions each miner lost, the miner is only earning an
> effective feerate of 4.3 sats/vbyte.
I covered that attack in my one-shot RBFR writeup:
https://petertodd.org/2024/one-shot-replace-by-fee-rate#fill-and-dump-attack
It's not a concern for a few reasons:
0. It's a class of attack that is already possible without RBFR: obviously, you
can fill and dump by simply double-spending your fill transactions. Eg, this
is obviously easy to do with full-rbf!
1. One-shot RBFR - my actual incentive-compatible proposal - is not vulnerable
to fill-and-dump attacks the way you described, as you can't "dump" the top
of the mempool with one-shot RBFR. The "dump" transactions won't be
accepted, as one-shot RBFR only allows you to replace transactions with a
low fee-rate that won't be mined in the near future.
2. Miners routinely run with much larger mempools than normal nodes. As I
mentioned elsewhere, in my discussions with miners, mempools of 1GB or more
were common.
3. Rebroadcasting is easy. Anyone can rebroadcast previously broadcast
transactions. If people actually tried fill-and-dump attacks, all they'd
succeed in doing is briefly kick out some transactions from typical
mempools, at the cost of creating a bunch of higher fee-rate transactions
that will most likely get mined at great expense to the attacker.
> Further, it's easy to imagine situations where evicting
> time-sensitive transactions from mempools might allow theft of funds
> in excess of a few thousand dollars (my immediate thoughts go to
> situations involving watchtowers).
Watchtowers are actually a uniquely *bad* example. Recall that watchtowers
merely broadcast pre-signed justice transactions in response to a revoked
commitment transaction being mind. AFAIK, all existing watchtower
implementations pre-sign the transactions with a fixed, high, fee-rate. What
they actually should do is provide the watchtower with multiple pre-signed
transactions at different fee-rates, up to the economic maximum. But I digress.
As explained above, rebroadcasting is trivial, and watchtowers are expected to
run 24/7 anyway. Secondly, one-shot RBFR prevents the replacement of any
transaction that is expected to be mined soon. So if the justice transaction
was signed with a high enough fee-rate to get mined, the only thing the
attacker can do is outbid it (and all transactions before it). Which is true
without RBFR anyway!
Finally, in general, while applications like Lightning are time-sensitive,
they're not *that* time sensitive. LND uses 144 blocks as its default CSV
delay, giving you an entire day to get a transaction mined. Doing fill-and-dump
attacks dozens of times in a row is not cheap.
> 3. Limiting the worst-case free relay and excessive mempool eviction
> requires additional rules (e.g. one-shot RBFr) that are challenging
> to implement and analyze at present, as several devs have noted[3].
> Both implementation and analysis should become much easier if cluster
> mempool is deployed (also noted by devs), but the deployment of
> cluster mempool requires removal of CPFP carve-out, and removal of
> CPFP carve-out requires either the upgrade of thousands of LN nodes
> and channels or a drop-in solution (ideally one that can be analyzed
> independently from cluster mempool, like TRUC).
As I explained separately, you are very incorrect in your description of the
CPFP carve-out. In fact, it's RBFR that is our only path to having a cluster
mempool without requiring existing applications to upgrade.
As for implementation, it is true that implementing one-shot RBFR is harder
without a cluster mempool. But fee estimation is something Bitcoin Core already
does. It would be fine to either 1) re-use the fee estimation machinery to get
a reasonable minimum one-shot fee-rate, 2) periodically generate a block and
use the minimum fee-rate of that block. Mempools aren't a consensus, so it
simply isn't necessary for every mempool to agree exactly on what the minimum
one-shot fee-rate is, for the same reason that it's not necessary for every
mempool to agree on the same minimum relay fee-rate.
> > this is quite an odd case of Core politics
>
> I began writing this reply to force me to examine your claims for
> myself. You have a long history of noticing things other people missed.
Thanks!
> A simple free relay attack using RBFr
>
> ## Constants
>
> 100,000 vbytes == ~400,000 bytes
> A 1-input, 1-output P2TR scriptpath spend with the maximum amount
> of witness data allowed by Bitcoin Core defaults
>
> 111 vbytes == 162 bytes
> A 1-input, 1-output P2TR keypath spend
>
> ## Attack
>
> - Attacker obtains 500,000 UTXOs
>
> - For each UTXO
>
> - At the dynamic mempool minimum, broadcasts a 100,000 vbyte (400,000
> byte) transacton.
>
> - Waits for it to propagate.
>
> - At 1.25x the dynamic mempool minimum, broadcasts a RBFr replacement
> that is 111 vbytes (162 bytes).
>
> ## Analysis
>
> - At 162 bytes each, 500,000 transactions is 81 MB. I think that will
> fit in a default-sized mempool.
>
> - The total amount of transaction data relayed is 500_000 * (400_000 +
> 162), or about 200 GB.
>
> - The typical daily bandwidth requirement of a blocks-only node is
> roughly 2.5 MB * 144, or about 0.36 GB per day. Ideally a relaying
> node is about the same due to compact blocks, but realistically, it's
> a small multiple of that. Call it 2 GB per day.
>
> - This implies the attack push each RBFr relay node to use 100x a
> non-RBFr relay node.
>
> - At 111 vbytes each, 500,000 transactions is 55.5 million vbytes. At
> my nodes current mempoolminfee (1 sat/vb), that's 55.5 million sats,
> or 0.55 BTC (about $37,000 USD).
>
> - This analysis ignores the cost of obtaining the UTXOs and possibly
> later consolidating them, but it also ignores some easy optimizations
> such as batching the replacements.
G
First of all, subtlety of the class of attack you are describing is it matters
a lot whether or not you expect the double-spend transactions to be mined in
the near future.
With one-shot RBFR - my actual proposal for Bitcoin Core - the fee-rate of the
double-spend is required to be sufficiently high to be likely to be mined in
the near future. With pure RBFR, which is implemented in Libre Relay as an
_experiment_, the double-spend merely needs to be a higher fee-rate. This
difference is one reason why I'm not proposing that Core actually implement
pure RBFR!
So the relevant question is, can you pull off this class of attack with Bitcoin
Core's current relay rules? The answer is absolutely yes. The only significant
difference is you'll be invalidating the big, "fill", transactions with
transations paying economic fee-rates, either in a block, or likely to soon be
in a block. Thus one-shot RBFR makes no difference: the same class of attacks
are possible whether or not it exists.
Secondly, your attack requires $37,000. That amount of money would pay for
2700TB of bandwidth at 0.01 USD/GB, the (expensive!) cost of bandwidth on
Digital Ocean. There's about 20,000 publicly accessible nodes. So for that
amount of money, you could just DoS attack all 20,000 nodes simultanously with
about 185GB of data each. Digital Ocean is a very expensive way to get DoS
attack bandwidth, so realistically an attacker would probably pay even less for
the attack.
Even worse, you could use that bandwidth to perform a conflicting transactions
attack. For each publicly accessible node, broadcast a different,
100,000vB/400,000B, transaction spending the same UTXO. Each node will waste
bandwidth telling it's ~100 peers (including non-public nodes) about that
transaction, reducing the attackers bandwidth cost by a factor of ~100.
--
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/Zp6TTAJ399CKbY5s%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not
2024-07-22 16:43 ` David A. Harding
@ 2024-07-22 20:06 ` Peter Todd
2024-07-22 22:08 ` David A. Harding
0 siblings, 1 reply; 37+ messages in thread
From: Peter Todd @ 2024-07-22 20:06 UTC (permalink / raw)
To: David A. Harding; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]
On Mon, Jul 22, 2024 at 06:43:14AM -1000, David A. Harding wrote:
> On 2024-07-22 01:45, Peter Todd wrote:
> > TRUC meanwhile isn't even a drop-in solution, and requires everyone to
> > upgrade before cluster mempool is even possible.
>
> The proposed BIP for TRUC[1] is indeed entirely opt-in and would require
> all users of CPFP-CO (e.g. LN anchors channels) to upgrade their
> software and switch to a new commitment transactions format, which
> currently requires closing and reopening all anchors channels. There's
> work on improving upgrade mechanisms in LN, but it would still be a pain
> and a major delay to cluster mempool to depend on every LN user
> upgrading.
>
> However, there has also been significant discussion and analysis[2] of an
> imbued-semantics form of TRUC that could be retroactively applied to
> LN-style anchor outputs (which are the only users of CPFP-CO we know
> about). In that case, nobody needs to upgrade before cluster mempool
> becomes possible.
>
> In my previous email, I assumed you were familiar with the imbued
> semantics proposal; I'm sorry for the miscommunication.
I am aware of that proposal. It is not a proposal with "significant discussion
and analysis", your link, [2], has three posts in total, with discussion ending
in Febuary, with only the OP having any significant content. Both replies to
the idea noted potential incompatibilites with existing implementations. I'm
not aware of any running code nor any significant discussion amongst LN
implementations and other stakeholders. The idea hasn't even been posted to
this mailing list.
That's why I never brought it up: the idea seems to have died out.
Frankly, unless you can point to actual "significant discussion and analysis"
of the idea, it's dishonest and toxic of you to portray it as such as you
should know better. RBFR has had more "significant discussion and analysis"
than this idea in this very thread.
Personally, I think it might not be an unreasonable hack before something
better like RBFR gets implemented. But it's only a hack. And if anything, it
strongly suggests that actually permanently specifying TRUC/V3 is an
unnecessary complication.
> -Dave
>
> [1] https://github.com/bitcoin/bips/blob/158acdbbbf8ef13f6b345b6281a96e88e20d2cf9/bip-truc.mediawiki#user-content-Specification
> [2] https://delvingbitcoin.org/t/analysis-of-attempting-to-imbue-ln-commitment-transaction-spends-with-v3-semantics/527
--
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/Zp674YtMTaUX3imH%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not
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
0 siblings, 2 replies; 37+ messages in thread
From: David A. Harding @ 2024-07-22 22:08 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoindev
On 2024-07-22 10:06, Peter Todd wrote:
> can [you] point to actual "significant discussion and analysis"
> of the idea
The idea for imbued TRUC was developed in part during a live
discussion with LN maintainers:
https://btctranscripts.com/lightning-specification/lightning-2024-01-15-specification-call/
I'm aware of three discussions about it on the Delving Bitcoin Forum:
-
https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418/2
-
https://delvingbitcoin.org/t/sibling-eviction-for-v3-transactions/472#benefits-1
- (as previously linked)
https://delvingbitcoin.org/t/analysis-of-attempting-to-imbue-ln-commitment-transaction-spends-with-v3-semantics/527
Each of those discussions was summarized by a Bitcoin Optech Newsletter,
a publication read by many Bitcoin and LN protocol developers
(disclosure: I co-author the newsletter):
"Adding this policy and automatically applying it to current LN
anchors
will allow the CPFP carve-out rule to be removed, which is necessary
for
cluster mempool to be implemented, which should allow making
replacements of all kinds more incentive-compatible in the future."
https://bitcoinops.org/en/newsletters/2024/01/31/#kindred-replace-by-fee
"Imbued v3 logic: In response to concerns voiced in the LN spec
meeting
that it may take a long time for LN to design, implement, and deploy
these changes, Gregory Sanders proposed an intermediate stage with
temporary special treatment of transactions that look like current
anchors-style LN commitment transactions, allowing Bitcoin Core to
deploy cluster mempool without being blocked by LN development."
https://bitcoinops.org/en/newsletters/2024/01/24/#imbued-v3-logic
"[...] research into the idea of automatically applying v3 transaction
relay policy to anchors-style LN commitment and fee-bumping
transactions
(see Newsletter #286 for the underlying imbued v3 proposal)."
https://bitcoinops.org/en/newsletters/2024/02/14/#what-would-have-happened-if-v3-semantics-had-been-applied-to-anchor-outputs-a-year-ago
The word "imbue" is mentioned in 7 separate posts by 4 separate authors
in a Bitcoin Core discussion issue that includes comments from three
different LN implementation maintainers plus @petertodd, who I assumed
was you: https://github.com/bitcoin/bitcoin/issues/29319
That thread also links to a draft implementation of imbued v3, which was
used for the Analysis forum post:
https://github.com/bitcoin/bitcoin/pull/29427
As discussed in the "sibling eviction" thread (summarized in the
2024-01-31 newsletter), one of the necessary parts for imbued TRUC to be
effective at replacing CPFP-CO is sibling eviction. A version of that
(currently only for opt-in TRUC) was merged into Bitcoin Core several
months
ago: https://github.com/bitcoin/bitcoin/pull/29306
I note that none of the above was hidden or hard to find. All three of
the discussion summaries quoted above are linked on the Bitcoin Optech
topic page about v3 relay/TRUC, and two of them are also linked on the
topic pages about CPFP-CO and anchor outputs. Most of the other stuff I
found by searching the bitcoin/bitcoin repository for the word "imbue":
- https://bitcoinops.org/en/topics/version-3-transaction-relay/
- https://bitcoinops.org/en/topics/cpfp-carve-out/
- https://bitcoinops.org/en/topics/anchor-outputs/
> Frankly, unless you can point to actual "significant discussion and
> analysis"
> of the idea, it's dishonest and toxic of you to portray it as such as
> you
> should know better.
I'm sorry you've been unable to keep up with protocol development and
are confusing that for me being dishonest and toxic. May I suggest you
subscribe to the weekly Optech newsletter? It's free.
-Dave
--
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/6c222c758e10e8061ccdcc180b1826a3%40dtrt.org.
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not
2024-07-22 22:08 ` David A. Harding
@ 2024-07-23 11:29 ` Peter Todd
2024-07-24 0:42 ` Antoine Riard
1 sibling, 0 replies; 37+ messages in thread
From: Peter Todd @ 2024-07-23 11:29 UTC (permalink / raw)
To: David A. Harding; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]
On Mon, Jul 22, 2024 at 12:08:28PM -1000, David A. Harding wrote:
> > Frankly, unless you can point to actual "significant discussion and
> > analysis"
> > of the idea, it's dishonest and toxic of you to portray it as such as
> > you
> > should know better.
>
> I'm sorry you've been unable to keep up with protocol development and
> are confusing that for me being dishonest and toxic. May I suggest you
> subscribe to the weekly Optech newsletter? It's free.
Ironically, while toxicly and dishonestly accusing me of being "unable to keep
up with protocol developments", you proved I was in fact quite aware of imbued
TRUC around the same time it got it's mention in Optech, and was even involved
in the short discussion of it.
Anyway, I'll stand by my earlier comment: the fact is the imbued TRUC proposals
are currently dead, and never received significant discussion and analysis. I
did forget about the fact that a draft pull-req was made. But that pull-req was
a mere draft and the author has abandoned it without responding to critique,
and only a few weeks after authoring it, even said on Feb 28 that "I would also
prefer to not merge the imbued v3 patch.":
https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1969122250
...and one of the LN maintainers queried explicitly argued against it, saying,
among other things, "I'm not a fan of merging hacky, temporary code into
bitcoin core to be honest.":
https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1968709925
Notice how that's an issue where I commented something like a half dozen times,
including after the author of imbued TRUC gave up on it.
--
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/Zp%2BUAAtYDBqcgzEd%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
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:35 ` Antoine Riard
1 sibling, 0 replies; 37+ messages in thread
From: Antoine Riard @ 2024-07-24 0:35 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 14217 bytes --]
Hi Ava,
Thanks for the additional thoughts.
> Peter was not the only "senior" person on the security list. Obviously I
> will not disclose non-public information, but certainly there are people
> on the security list who are just as, if not more, senior than Peter.
Apart of sipa (who is arelady public on the security.md), I think they are
2 more people with whom I had experience of interacting on the list that I
think are as much "senior" than Peter, both of them from public notoriety
and on their own declaration they are less active in bitcoin protocol
development
(while they keep my reasonable trust if I have to report security
information).
Apart of those 3 people, I don't see who is most senior than Peter in
bitcoin
protocol development, and who an equivalent track records in matters of
adversarial
exploitation, consensus changes and use-cases protocol design (as one needs
a bit
of understanding of the "userspace" when you're handling issues).
I won't be a jerk to disclose in public people who I think are actually on
the list,
and that you might think off in saying "just as", and here I have practical
experiences
with a lot of people in the space who have been there since satoshi time or
after.
> Furthermore, the "old parts" still do get changed, and someone who no
> longer actively contributes to the project is more likely to be unaware
> of how the code actually works today, even if they are familiar with
> components that change infrequently.
This is not incorrect to say that "old parts" get changed, though the
frequency
is far from being exceptional and the substantial changes are pretty rare.
If you
take few iconic files and you run stats (all no merges):
- net_processing.cpp, initial file creation 2016, number of commits 926, in
average 115 changes yearly
- validation.cpp, initial file creation 2016, number of commits 1075, in
average 134 changes yearly
- scheduler.cpp, initial file creation 2015, number of commits 47, in
average 5 changes yearly
- interpreter.cpp, initial file creation 2014, number of commits 145, in
average 14 changes yearly
One can certainly run more line code stats diff changes at each year point
to get a
granularity how much substantial changes they are and if they are any trend
like
subsystem being more stable than other.
Validation and net processing are obviously beefy files ongoing regular
changes (as there has never
been a patchset landing successs of the many attempts from many authors to
break them further like
#13413, #16175 and #18963). And what of substantial abstraction have been
introduced in the past years
in validation ? Package support and a lot of block-relay mitigations and
cleanup, not something like crazy.
Consensus and its interfaces has by far has a rythm of upgrades more slow,
for an ecosystem impact
de-multiplied in case of issues (and it's harder to evaluate they might
have "horizontal" effect on
use-cases like timelocks). Like I was saying evaluating who is active on
single-digit years timelines
(and more probably 2 than 9) is short-sighted, and this does not match
practical experiences in other
top open-source codebases like linux kernel.
There is not only a necessity to be aware of how the code actually works
today, though also the
undocumented or unforseen scope of things like past attacks vectors or
plausible past misinteractions.
I think this something that Peter full disclosure illustrates well as more
"junior" security list recipients,
whatever their competency and goodwill, have failed to point out a type of
class of attack that have come
again and again in discussions about mempool rebroadcast years ago (see the
PR link I was pointing out in
one my Dave answer above).
> Not being on the list does not preclude him from being consulted if the
> need arises.
"If the need arises" supposes a lot, as first it assumes the report
timeframes give you leeway to come as more
or less group decision to share the sensitive information to someone like
Peter, being a default recipient
it's always faster (one might have to deal with situations where the
security flaw is already half-mentioned
in public and it's better to act fast).
Secondly, "if the need arises" is a technical judgement in itself. One
worst-case scenario could be for all
the default recipients reading a no-spam report, though missing an angle of
exposure or that actually it's
a serious attack vector. It did happen to me on the lightning side in the
past as I pointed out the general
vulnerability and someone cc after comes up with novel observations that
were worsening the issues, or any
hardening fix of it.
> With the two examples you provide, I am not aware of Peter being
> actively involved in the resolution of both of those, whereas there are
> current members of the list who were.
They were given as examples of situations where you prefer to have too much
competent and responsible
security list recipient that far too less, as both have temporal
contengencies far beyond the scope of
bitcoin core list to deal with them (the first as the DB-switch provoked
fork was already happenin, the
second as the report was from a bitcoin core fork coin).
On the list of people being actively involved in the resolution of them, or
who got privileged access
to information before disclosure, from my experience they're some names
that I must say can be a bit
sloppy in terms of reactiveness and implications in security issues
resolution (whatever the independent
fact they're very skilled bitcoin engineers and pretty good reviewers).
> In general though, it is not clear to me how it was beneficial to have
> Peter on the security list, nor how not having him is directly harmful.
> In the 2 years that I have been on the security list, I was unaware that
> Peter was a recipient until shortly before he was removed. My
> understanding is that others who have been on the list longer than me
> were also unaware.
Personally, I think Peter has still one of the most furnished track records
in bugs findings around the mempool
(the segwit malleability PR #8312) and understanding of all timelocks
issues with the authorship of bip65, which
is critical for contract protocols. That one disagrees with another
security list member on its public technical
opinions for newer changes, I think it's something one has to abstract when
all security issues handlers are coming
together to bring a mitigation to the issue.
That one can be too much "cowboy" in matters of timelines full disclosure,
which I think have been a bit about the
last 3 "free relay" disclosure, the best you can do is say so either
publicly, or privately in all courtesy. No way
to make progress on responsible disclosure standards, if no one never
speaks up.
I was aware that Peter was on the list from conversations years ago with
him on a reported issue, far before
all the present topics about V3 / TRUC / RBFR have been raised. In my
understanding, the fact that you were unaware
that Peter was on the list can only reinforce impression had a very slow
pace in terms of security issues fixing,
especially when it's coupled with the disclosure of all issues of past
months with which you have been involved.
My number one recommendation would be to make the list of default security
list recipient public, as it would
create more personal accountability (both internally among the list
recipient and externally towards the security
issues reporters / the wider community) and you can have a key fingerprint
for each one which is good in terms of process.
I certainly don't wish to pour the blame on anyone specifically, as I think
the current "so-so" state of security
issues handling by bitcoin core has been more a background result of all
the ups and downs of blocksize wars time,
where contributors didn't focus on it sufficiently. Yet, I think it's very
beneficial to think more about this process,
before we see either more funds at stake with contract protocols and other
applications (as it was well pointed out by one
of the optech newsletter and sadly too known by lightning protocol devs,
what can be a medium severity on the base layer
like transaction-relay censorship vector is very likely a high severity on
upper layer).
Best,
Antoine
ots hash: b8b4ce2cbed73ef7036bc7d7ebe67c325ff0b0f9336ac480c49d9036c2e40736
Le dimanche 21 juillet 2024 à 21:49:10 UTC+1, Ava Chow a écrit :
> On 07/20/2024 10:06 PM, Antoine Riard wrote:
> > "Naive", as saying this is the _Bitcoin Core_ project list only can only
> > provoke blind
> > spot among the list members if the security issues are either affecting
> > old part of
> > the codebases that younger members have less experiences with (some
> > parts like consensus
> > or block-relay are modified only every 5 years) or novel factors from
> > upstream or downstream
> > (e.g the internet networking stack or implications on deployed contract
> > protocols like
> > lightning). On both the former and latter criterias, I think Peter
> > overly meets the bar.
>
> Peter was not the only "senior" person on the security list. Obviously I
> will not disclose non-public information, but certainly there are people
> on the security list who are just as, if not more, senior than Peter.
>
> Furthermore, the "old parts" still do get changed, and someone who no
> longer actively contributes to the project is more likely to be unaware
> of how the code actually works today, even if they are familiar with
> components that change infrequently.
>
> > When you've big sh*t hitting the fan like inflation bugs or level DB
> > 2013 unexpected fork you
> > prefer have experts with a decade of experience to collaborate with, and
> > sharing the same cultural
> > and ethical norms of the active contributors evaluated by numbers on
> > commits on the last single-digit
> > years.
>
> Not being on the list does not preclude him from being consulted if the
> need arises.
>
> With the two examples you provide, I am not aware of Peter being
> actively involved in the resolution of both of those, whereas there are
> current members of the list who were.
>
>
> In general though, it is not clear to me how it was beneficial to have
> Peter on the security list, nor how not having him is directly harmful.
> In the 2 years that I have been on the security list, I was unaware that
> Peter was a recipient until shortly before he was removed. My
> understanding is that others who have been on the list longer than me
> were also unaware.
>
> Ava
>
> >
> > I'll repropose Peter admission on the security list mailing list in the
> > coming weeks by opening an
> > issue on the bitcoin-meta repository, once this current mailing list
> > thread has slowed down a bit,
> > or at least the technical analysis has been dissociated from the
> > proceedings which have all been
> > bundle in a big message. In my very personal opinion, I still trust more
> > Peter competence and experience
> > than some other people I know who are on the security mailing list.
> >
> > All that said I appreciate your answer and I'm satisfied from the
> > personal role you've have played
> > in the matter with, and be reassured I'll keep you among the recipient
> > of future security issues with
> > a potential impact on bitcoin core that I might find or be aware off.
> >
> > Best,
> > Antoine
> > ots hash:
> db441b51684ad3a6897f67d42c74ccfcb9a4ffed40d4bdbe30a2edd867ccdd54
> >
> > Le samedi 20 juillet 2024 à 01:50:25 UTC+1, Ava Chow a écrit :
> >
> > On 07/19/2024 07:58 PM, Antoine Riard wrote:
> > > As said in one my previous email, I'm still curious about achow101
> > > explaining publicly
> > > why you have been kicked-out of the bitcoin-security mailing
> > list, when
> > > you were certainly
> > > more senior than achow101 in matters of base-layer security
> > issues or
> > > even hard technical
> > > issues like consensus interactions (e.g bip65). I'll re-iterate my
> > > respect towards achow101
> > > as a maintainer from years of collaboration, though this is a topic
> > > worthy of an answer.
> >
> > I am not the one that removed Peter from the mailing list, nor do I
> > even
> > have the login(s) to do so.
> >
> > There was a discussion amongst several members of the security list
> > about who was on the list, and who should be on the list. Given that
> > the
> > security list is the _Bitcoin Core_ security list, we determined that
> > the people who should be on the list are people who still actively
> > contribute to the project. As Peter Todd no longer actively contribute
> > code nor code review to the project, we decided that it didn't make
> > sense to continue to have him on the list.
> >
> > My recollection is that multiple other people were removed from the
> > list
> > for the same reason at the same time.
> >
> > Ava
> >
> > --
> > 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+...@googlegroups•com
> > <mailto:bitcoindev+...@googlegroups•com>.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com
> <
> https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
>
>
--
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/f9d17558-4b74-401b-bb64-fed34bd46619n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 16769 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-21 15:35 ` David A. Harding
2024-07-21 20:25 ` Peter Todd
@ 2024-07-24 0:38 ` Antoine Riard
1 sibling, 0 replies; 37+ messages in thread
From: Antoine Riard @ 2024-07-24 0:38 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 6935 bytes --]
Hi Dave,
> Weak blocks also provide a decentralized DoS-resistant mechanism for
> voluntarily communicating all sorts of information from miners to other
> miners and relay nodes. That makes them an excellent tool for resolving
> any attack that depends on miners and relay nodes having a divergent set
> of transactions.
I think the mechanism you're describing is plagued by the following
vulnerability:
- an attacker mempool-partition all miners by exploiting transaction-relay
asymmetries (e.g same feerate, same weight, diff txid)
- an attacker broadcast an appealing transaction entering the top of mempool
- a weak block up to 4MB is generated for each such miner partitioned and
relayed to the rest of the network
- the whole block-relay network is wasting 4 MB of block-relay bandwidth
multiplied by N, the number of miners affected
- the mempool-partitition transaction vector might have paid a sub-minimal
feerate just to enter in mempool
Bonus point: the attacker has hashrate capabilities to mine the block
including the mempool-partition transaction vector
rendering a null gain for the DoSed miners whatever the weak block reward
mechanism for the "weak block" proposal (unless
the reward is exogeneous to the bitcoin blockchain, a type of in-protocol
reward one might skeptical relatively to bitcoin
security model).
I don't think the "weak block" proposal as you're presenting it makes
sense, at the very least quantitative evaluations
would be necessary to be sure you're not worsening the denial-of-service
aspect. In the present layout of the "weak block"
proposal, I really think you saying it's a decentralized DoS-resistant
mechanism is deeply misleading and inaccurate for
the rest of the community.
Zooming out, I believe it's an intesresting problem wishing to improve
rewarding of miners income if we wish to encourage
solo miners, and improve on the initial financial liquidity incentives that
are driving miners to gather themselves in pool
since the early days of bitcon, though I don't see how "weak block" can be
a viable solution.
Best,
Antoine
ots hash: 85636ac4e91bc781bbcdc8c0a24a17ad1c90039c6cabbb4d3ddd334c2c29fc02
Le dimanche 21 juillet 2024 à 19:04:29 UTC+1, David A. Harding a écrit :
> On 2024-07-20 05:03, Peter Todd wrote:
> > What other "free" relay attacks can you think of that were fixed?
>
> The two you mention were the two I had in mind.
>
> > Did you actually read my One-Shot RBFR proposal?
>
> Yes. It didn't provide any examples of RBFr free relay and I wanted to
> see whether a basic RBFr free relay attack would use significantly more,
> significantly less, or about the same amount of bandwidth per dollar
> spent as other free relay attacks. My conclusion is that it's about the
> same.
>
> > Weak blocks are not a solution to any of the "free" relay attacks I've
> > disclosed and your source does not claim that they are a "free" relay
> > solution.
>
> It does not explicitly say that, but it does say: "bonus use-cases:
> “Forcible insertion” of transactions that are incentive-compatible but
> violate anti-DoS rules".
>
> For example, in some of the scenarios you describe, the attacker sends
> an appealing transaction to miners and then sends less appealing
> versions of that transaction to relay nodes. If the appealing
> transaction enters the top mempool and gets included in a weak block,
> relay nodes will stop relaying less appealing variations minutes to
> hours before they otherwise would.
>
> Weak blocks also provide a decentralized DoS-resistant mechanism for
> voluntarily communicating all sorts of information from miners to other
> miners and relay nodes. That makes them an excellent tool for resolving
> any attack that depends on miners and relay nodes having a divergent set
> of transactions.
>
> > 1) Have you've read my One Shot RBFR proposal? In particular, my
> > analysis of DoS attacks *including* existing DoS attacks like
> > simultaneous broadcast.
> >
> > 2) Do you agree or disagree with me that these existing DoS attacks
> > are real?
>
> Yes, I've read your proposal, and I agree those attacks are plausible.
> In my mind, the major difference between those free relay attacks
> and RBFR free relay attacks is how solvable they are.
>
> I think it's easy to sketch a significant mitigation to all free relay
> attacks (including RBFR):
>
> - Reduce the maximum size of both relayable transactions and in-mempool
> packages, e.g. from 100,000 vbytes to 1,000 vbytes.
>
> - Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB.
>
> - Increase the default mempool feerate floor, e.g. from e.g. from 1
> sat/vb to 100 sat/vb.
>
> That would break relay of many existing presigned transactions,
> potentially leading to money loss, and would break other existing
> usecases, not to mention introduce other problems. However, I think
> it's sufficient to prove that a mitigation to free relay is possible
> without rendering the network unusable.
>
> Of course, an ideal solution wouldn't require placing any additional
> constraints on mempool policy. For the case of free relay due to
> divergent mempool policies, maybe it's something that could be done with
> transaction set reconciliation (~erlay), functions for allowing
> independent nodes to come to consistent conclusions about the best
> revenue set of transactions (~cluster mempool), P2P relay of non-obvious
> cluster linearizations[1], and miners voluntarily committing to their
> mempool contents in candidate blocks and P2P relaying those commitments
> in weak blocks.
>
> Innovations like that don't work for RBFR. If mempool policy is kept
> the same, free relay attacks with RBFR remain equally effective no
> matter what mechanisms we implement to improve preconsensus consistency.
>
> If pure RBFR is added and clever protocol developers find ways to
> largely fix other free relay attacks, then devs will either need to
> significantly restrict mempool policy anyway or will need to restrict or
> remove RBFR to make Bitcoin Core safe. Given that, it seems to me like
> a very reasonable decision not to add pure RBFR and to wait until better
> tools like cluster mempool become available before evaluating
> significant changes to RBF policy (like one-shot RBFR).
>
> Thanks,
>
> -Dave
>
> [1]
>
> https://github.com/bitcoinops/bitcoinops.github.io/pull/1421#discussion_r1415834695
>
--
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/1d64b24e-9ae4-4eac-b93a-c35fdcd26d6en%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8201 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-22 15:10 ` Peter Todd
@ 2024-07-24 0:41 ` Antoine Riard
0 siblings, 0 replies; 37+ messages in thread
From: Antoine Riard @ 2024-07-24 0:41 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 13034 bytes --]
Hi Peter,
> An irony here is that rebroadcasting makes most "free" relay attacks
*more*
> expensive, not less. sdaftuar had some correct points, like avoiding
bandwidth
> spikes. But for any "free" relay attack based on broadcasting conflicting
> transactions at different fee-rates, where the higher fee-rate
transaction is
> not mined, you get a better attack if the higher fee-rate transaction
falls out
> of node mempools, allowing the lower fee-rate conflict to be broadcast
again.
>
> If rebroadcasters ensure that nodes have the higher fee-rate tx, all you
can do
> to "reset" the attack is either get your UTXO(s) mined. Or use an even
higher
> fee-rate. Without rebroadcasting, you can wait for the expiry period to be
> reached.
I read again my review comments on that PR, and what I noticed at the time
is
how automatic rebroadcasting might provoke "free" relay attacks among a set
of mempools with different sizes. If you have mempool A at 100 MB and
mempool
B at 400 MB, assuming the top 100 MB of feerate is of same quality, the
full diff
of 300 MB of transaction-relay bandwidth is wasted between peers A and B. An
attacker can still have to chain transactions to bypass bip133 fee filters.
So yes, I think rebroadcasting can be a benefice in face of some "free"
relay
attacks, though far from most and it might worsen if you consider mempool
sizes
asymmetries.
> Not just miners: any node running with mempoolfullrbf=1 is going to waste
less
> bandwidth if someone actually does this attack.
If a majority of miners wouldn't run `mempoolfullrbf=1`, I think it would
have
been a good empirical point that it doesn't increase average block income
(and
apart of any DoS vector for contracting protocols / multi-party
applications).
In such world where a majority of miners are running with
`mempoolfullrbf=1`,
yes the attack is a bandwidth waste at any `mempoolfullrbf=1` /
`mempoolfullrbf=0`
transaction-relay partitions.
> RBF is way underused in protocols in general. And there have probably been
> literally millions of dollars wasted on fees spent by inefficient CPFP
> solutions when RBF (via pre-signed transactions) could have been used
instead.
> This financial figure will only get higher as Lightning gets more
adoption. It
> also limits Lightning in mass failure scenarios: every byte saved while
force
> closing a channel is room that could be used to force close another
channel.
This is correct that with each CPFP we have block chain space weight wasted.
I'm not going to say that RBF is a perfect solution for lightning and other
off-chain
use-cases, as you have some other limitations (never took time to do a full
public
write-up here). Though yes it improves significantly lightning in mass
failure
scenarios to have the most compact fee-bumping for commitment in a world
where
block size is limited.
> I have to disagree here. The nature of protocols like Lightning is there
is a
> maximum amount that it's worth attempting to pay to get a transaction
mined to
> perform some action. There also a deadline to perform that action.
>
> For example, an HTLC has a clear expiry time and value. *Even if* you
have no
> idea what fee-rates are needed to get a transaction mined, you can simply
do
> repeated RBF bumps at higher and higher fee-rates, ending at a fee-rate
that
> spends the entire value of the HTLC. As long as you do in fact have
uncensored
> access to miner mempools - as long as you haven't been sybil attacked -
this
> approach will do about as well as is possible, modulo pinning attacks. So
our
> job is now to simply fix the pinning attacks with better RBF policy.
"As long as you do in fact have uncensored access to miner mempools". This
is
the caveat to highlight as an attacker can batch pinning effect by targeting
unrelated channels and occupying the same place in common mempools.
Unrelated
channels have a limited fee-bumping budget to dedicate to fixed-amount
HTLCs.
Such observation was spotted a while back in an old email post of mine on
advanced
pinning vectors (dubbed "network-aware pinning") [0]
[0]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018011.html
This is correct that one can always have access to miner mempools, while
completely
disregarding the public transaction-relay network, though here we're
talking about
a different security model for lightning. We considered on the
lightning-side that
approach to solve pinnings in the past here [1].
[1] https://github.com/lightning/bolts/issues/783
> IIUC, this RBF fee-bumping approach is exactly what the RBF sweeper
introduced
> in LND v0.18 does. Face with, eg, high blockspace demand the sum total of
LND
> RBF sweepers will result in the most valuable HTLCs and similar things
being
> mined, while less valuable transactions don't (ignoring pinning of
course).
> That's fine! That's the best we can do given a limited blockspace.
Doesn't work if you consider more advanced pinning vectors like "network
aware pinnings".
> Traditional cryptography literature is not relevant here, as it's based
on the
> difficulty of mathematical problems, not economics; the security of L2
> protocols is based on economics.
Traditional cryptography litterature not only based on the difficulty of
mathematical
problems, though also on computational hardness assumptions e.g "assume no
one can
efficiently find a preimage collison for 80-bits hash".
That L2 protocol security is based on economics (and physics) doesn't waiwe
to do the
analytical work on the ressources assumptions beared on attacker to
pragmatically
determine if an attack is realistic or not (though I don't think deep
methodological
considerations alter the crux of the conversation about "free relay"
attacks here).
Best,
Antoine
ots hash: 79f97742d76e6f349f2a881d8acc6afc8623d897472533272390ed9183baa5c5
Le lundi 22 juillet 2024 à 16:15:12 UTC+1, Peter Todd a écrit :
> On Sat, Jul 20, 2024 at 07:10:53PM -0700, Antoine Riard wrote:
> >
> > Hi Dave,
> >
> > Thanks for your thoughtful answer (even if its wasn't addressed to me
> > primarly).
> >
> > > I cannot imagine what would make you think that protocol developers are
> > > not concerned about attacks that could drive large numbers of relay
> > > nodes off the network for a cost easily affordable to any well-funded
> > > adversary.
> >
> > From my experience code reviewing the wallet / mempool re-broadcast of
> few
> > years ago, free tx-relay / bandwidth waste attacks were far to be
> > understood
> > or plainly weighted by some contributors of a newer generations,
> including
> > by
> > the own champion of the proposal. The proposal was finally abandonned
> when a
> > more senior dev came up with quantitative analysis of code changes [0].
> >
> > [0] https://github.com/bitcoin/bitcoin/pull/21061#issuecomment-851563105
>
> An irony here is that rebroadcasting makes most "free" relay attacks *more*
> expensive, not less. sdaftuar had some correct points, like avoiding
> bandwidth
> spikes. But for any "free" relay attack based on broadcasting conflicting
> transactions at different fee-rates, where the higher fee-rate transaction
> is
> not mined, you get a better attack if the higher fee-rate transaction
> falls out
> of node mempools, allowing the lower fee-rate conflict to be broadcast
> again.
>
> If rebroadcasters ensure that nodes have the higher fee-rate tx, all you
> can do
> to "reset" the attack is either get your UTXO(s) mined. Or use an even
> higher
> fee-rate. Without rebroadcasting, you can wait for the expiry period to be
> reached.
>
> > > In this case, you've found a specific instance (full-RBF vs signaled
> > > RBF) of a well-known general problem (optional policies leading to
> > > mempool inconsistencies, allowing free relay) and appear to be arguing
> > > that devs don't care about free relay because they refused to reverse a
> > > previous decision (to not change the RBF configuration default) that
> has
> > > been hotly debated multiple times.
> >
> > I think what is more interesting and noteworhty in the whole line of
> > reaosning
> > of Peter with the present disclosure is how much the adversial effect is
> > favor
> > by the supermajority of miners running `mempoolfullrbf` [1].
> >
> > [1] https://github.com/bitcoin/bitcoin/pull/28132#issue-1817178316
>
> Not just miners: any node running with mempoolfullrbf=1 is going to waste
> less
> bandwidth if someone actually does this attack.
>
> > Under those conditions, where it took 9 years for the bitcoin core
> project
> > to disclosre
> > some vulnerabilitires, personally I'm more likely to understand that the
> > bitcoin core project
> > is under-staffed is competent experts to keep public disclosure in
> > reasonable timeframe (-- at
> > least equivalent to the kernel world), and as corollorary to fully
> evaluate
> > technical proposal
> > with all its strength and weaknesses.
> >
> > Saying an "already overdiscussed issues that gets nobody closer to
> > fundamental solutions" is
> > insulting for Peter, honestly.
>
> Indeed. You'd think solid evidence, trivially verifiable by anyone, that
> almost
> all miners had adopted full-rbf would be enough. Instead that evidence
> doesn't
> even receive any acknowledgement.
>
> > As an offchain protocol developers which has been involved in the
> majority
> > of technical conversations,
> > implementations and deployment of the "anchor output" upgrade, I believe
> on
> > the long-term CPFP-style fee-bumping
> > of contract protocol, including lighting, is not the most robust
> technical
> > solutions. I think anyone can check
> > in the bitcoin optech anchor output glossary the numerous
> vulnerabilities
> > that have plagued this fee-bumping
> > solutions over the past years.
>
> RBF is way underused in protocols in general. And there have probably been
> literally millions of dollars wasted on fees spent by inefficient CPFP
> solutions when RBF (via pre-signed transactions) could have been used
> instead.
> This financial figure will only get higher as Lightning gets more
> adoption. It
> also limits Lightning in mass failure scenarios: every byte saved while
> force
> closing a channel is room that could be used to force close another
> channel.
>
> > I already reviewed some parts of cluster mempool. Fundamentally,
> economical
> > mempool pinnings for second-layers (bip125 absolute
> > fee) with pre-signed time-sensitive transactions arises from a world
> where
> > there is (a) an asynchronicity of mempools and (b) one
> > cannot guess feerates at block + 1 (-- let's say in a deterministic
> fashion
> > as understood by traditional cryptographic litterature
> > when doing cryptanalysis). Better RBF policies won't solve that,
> including
> > RBFr.
>
> I have to disagree here. The nature of protocols like Lightning is there
> is a
> maximum amount that it's worth attempting to pay to get a transaction
> mined to
> perform some action. There also a deadline to perform that action.
>
> For example, an HTLC has a clear expiry time and value. *Even if* you have
> no
> idea what fee-rates are needed to get a transaction mined, you can simply
> do
> repeated RBF bumps at higher and higher fee-rates, ending at a fee-rate
> that
> spends the entire value of the HTLC. As long as you do in fact have
> uncensored
> access to miner mempools - as long as you haven't been sybil attacked -
> this
> approach will do about as well as is possible, modulo pinning attacks. So
> our
> job is now to simply fix the pinning attacks with better RBF policy.
>
> IIUC, this RBF fee-bumping approach is exactly what the RBF sweeper
> introduced
> in LND v0.18 does. Face with, eg, high blockspace demand the sum total of
> LND
> RBF sweepers will result in the most valuable HTLCs and similar things
> being
> mined, while less valuable transactions don't (ignoring pinning of course).
> That's fine! That's the best we can do given a limited blockspace.
>
> Traditional cryptography literature is not relevant here, as it's based on
> the
> difficulty of mathematical problems, not economics; the security of L2
> protocols is based on economics.
>
> --
> 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/db52123b-c5ec-4d6e-94c5-5a36bce186b7n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 15454 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not
2024-07-22 22:08 ` David A. Harding
2024-07-23 11:29 ` Peter Todd
@ 2024-07-24 0:42 ` Antoine Riard
1 sibling, 0 replies; 37+ messages in thread
From: Antoine Riard @ 2024-07-24 0:42 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 5413 bytes --]
Hi Dave,
> I'm sorry you've been unable to keep up with protocol development and
> are confusing that for me being dishonest and toxic. May I suggest you
> subscribe to the weekly Optech newsletter? It's free.
See my review comments on the imbuance mechanism PR on bitcoin core, I
think it's broken in the sense that you can escapce the imbuanche mechanism
by playing on commitment output scriptpubkye / amount collision.
Bitcoin core is a public project so you're free to access the 5 months old
comments now and make your own opinion. For now, I think there is no bitcoin
core code available for a robust imbuanche mechanism, so this whole roadmap
thing you're presenting in your post or in the bitcoin optech newsletter I
don't
know if it's technically sound, and not a bit misleading for the bitcoin
industry
players periodically reading it.
Best,
Antoine
ots hash: a75c98ab5166c541ecba5e579639f359e82ff315df89b04264b29f8dfaa87502
Le lundi 22 juillet 2024 à 23:10:33 UTC+1, David A. Harding a écrit :
> On 2024-07-22 10:06, Peter Todd wrote:
> > can [you] point to actual "significant discussion and analysis"
> > of the idea
>
> The idea for imbued TRUC was developed in part during a live
> discussion with LN maintainers:
>
> https://btctranscripts.com/lightning-specification/lightning-2024-01-15-specification-call/
>
> I'm aware of three discussions about it on the Delving Bitcoin Forum:
>
> -
>
> https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418/2
> -
>
> https://delvingbitcoin.org/t/sibling-eviction-for-v3-transactions/472#benefits-1
> - (as previously linked)
>
> https://delvingbitcoin.org/t/analysis-of-attempting-to-imbue-ln-commitment-transaction-spends-with-v3-semantics/527
>
> Each of those discussions was summarized by a Bitcoin Optech Newsletter,
> a publication read by many Bitcoin and LN protocol developers
> (disclosure: I co-author the newsletter):
>
> "Adding this policy and automatically applying it to current LN
> anchors
> will allow the CPFP carve-out rule to be removed, which is necessary
> for
> cluster mempool to be implemented, which should allow making
> replacements of all kinds more incentive-compatible in the future."
>
>
> https://bitcoinops.org/en/newsletters/2024/01/31/#kindred-replace-by-fee
>
> "Imbued v3 logic: In response to concerns voiced in the LN spec
> meeting
> that it may take a long time for LN to design, implement, and deploy
> these changes, Gregory Sanders proposed an intermediate stage with
> temporary special treatment of transactions that look like current
> anchors-style LN commitment transactions, allowing Bitcoin Core to
> deploy cluster mempool without being blocked by LN development."
>
> https://bitcoinops.org/en/newsletters/2024/01/24/#imbued-v3-logic
>
> "[...] research into the idea of automatically applying v3 transaction
> relay policy to anchors-style LN commitment and fee-bumping
> transactions
> (see Newsletter #286 for the underlying imbued v3 proposal)."
>
>
>
> https://bitcoinops.org/en/newsletters/2024/02/14/#what-would-have-happened-if-v3-semantics-had-been-applied-to-anchor-outputs-a-year-ago
>
> The word "imbue" is mentioned in 7 separate posts by 4 separate authors
> in a Bitcoin Core discussion issue that includes comments from three
> different LN implementation maintainers plus @petertodd, who I assumed
> was you: https://github.com/bitcoin/bitcoin/issues/29319
>
> That thread also links to a draft implementation of imbued v3, which was
> used for the Analysis forum post:
> https://github.com/bitcoin/bitcoin/pull/29427
>
> As discussed in the "sibling eviction" thread (summarized in the
> 2024-01-31 newsletter), one of the necessary parts for imbued TRUC to be
> effective at replacing CPFP-CO is sibling eviction. A version of that
> (currently only for opt-in TRUC) was merged into Bitcoin Core several
> months
> ago: https://github.com/bitcoin/bitcoin/pull/29306
>
> I note that none of the above was hidden or hard to find. All three of
> the discussion summaries quoted above are linked on the Bitcoin Optech
> topic page about v3 relay/TRUC, and two of them are also linked on the
> topic pages about CPFP-CO and anchor outputs. Most of the other stuff I
> found by searching the bitcoin/bitcoin repository for the word "imbue":
>
> - https://bitcoinops.org/en/topics/version-3-transaction-relay/
> - https://bitcoinops.org/en/topics/cpfp-carve-out/
> - https://bitcoinops.org/en/topics/anchor-outputs/
>
> > Frankly, unless you can point to actual "significant discussion and
> > analysis"
> > of the idea, it's dishonest and toxic of you to portray it as such as
> > you
> > should know better.
>
> I'm sorry you've been unable to keep up with protocol development and
> are confusing that for me being dishonest and toxic. May I suggest you
> subscribe to the weekly Optech newsletter? It's free.
>
> -Dave
>
--
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/1d532e88-d40a-4417-bdac-6c4bbf90c26en%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 10651 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core
2024-07-22 1:59 ` 'Anonymous User' via Bitcoin Development Mailing List
@ 2024-07-24 0:44 ` Antoine Riard
0 siblings, 0 replies; 37+ messages in thread
From: Antoine Riard @ 2024-07-24 0:44 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 8801 bytes --]
Hi Anonymous,
Let's add more characterization by zooming out on a 15 years timeline on
the situation for an external observer less versed in usual bitcoin core
development.
Historically, the project has been cared of by veteran of open-source
projects,
old cypherpunks and other contributors used to security system engineering.
While
qualms on technical proposals have always been heated even in the early
days (e.g
the infamous OP_EVAL or bloom-filters bip37), at the very least
protagonists in
the conversation were taking technical arguments at their sound value and
killing
weak ideas when a majority of contributors have came to the same conclusion.
The resistant to the arguments, if they did not have the intellectual
honesty to
fully appreciate arguments, were slowly moving out of contributing to
bitcoin or
projects around to go work on fork-coins or something else. From my
experience,
historically bitcoin had some of the most scientifically grounded and
software
skilled contributors sweating hard and ready to risk their professional
careeers
to make the bitcoin core codebase advance. There is a bit of subjectivity
involved
here though I worked on code changes and review with some people since the
early
days and if you take the "old guard" the level is here.
With time, especially after the block size war which have been intense
whatever
the camp you have followed, some more "senior" core contributors have take
a more
or less step back, without necessarily taking the time to fully transmit
the same
level of technical and ethical standard to newcomers making their dents on
the project.
This trend has only been worsen with the Faketoshi lawsuits, where even
more "senior"
contributors have take a step back.
All those "senior" folks, of which Peter is a good specimen, where very
okay when you
yelled at them that code was broken or a significant low-level proposal was
weak and
it was better to fix them before to move forward. Without always
necessarily caring
about following the utmost courtesy and politeness.
At the very same time of the end of the block size war and when faketoshi
lawsuits where
taking the most of their toll among the contributors, there has been more
the growth
of a culture of "professionalizing" the bitcoin core space. That have
translated in a
number of dimensions, e.g we have started to seen a myriad of
"money-helicopter" open-source
grants (most of the times attributed to hard working folks, sometimes
giving the impression
that attribution has been done on more external "social" factors). In
parallel, there
has been an emphasis in the core developnment process to ship complex code
in low-level
subsystems, whatever the thoroughness of the design and code review, as
landing complex
code not only make good story to tell on podcasts and twitter but it has
also become a
self-sustaining argument to grap more open-source grants for some less
regarding contributors.
(I don't know if a lot of folks are familiar with the school of public
choice in economics
and the concept of rent-seeking capture, one can wonder if it's not a
phenomena affecting
bitcoin open-source stage too. This is not saying that it's great to have
folks on open-source
grants to handle releases, refactor the old parts of the codebase or write
more tests,
I think just to be more far conservative when it comes to implementation of
new mechanism and
minimizing the impact of incentives nurturing complacency).
With that accumulation of uncoordinated cultural changes, and open-source
grants becoming
the norm as a mode of compensation among the majority of bitcoin core
contributors (rather
than exercising their skills on the market or being good with their btc
stack), in my
impression there has been more and more a wind of spontanous
self-censorship arising among
the current generation of contributors. After all, what one would take the
risk of being
far too negative or adverserial in the review of one's co-contributors
patchset, when that
very co-contributor might judge for your grant re-attribution at the end of
the year ?
Better to not take the risk, and if it's coupled with having a small btc
stack even if there
is a major security failure X years from now, you wouldn't personally pay
the cost as your
fiat-denominated grant will be still dump on you. All you have to do in
case of security failure
is run away from any responsibility and engage in a heavy public
relationship effort saying
everything is all right, bragging about the fact that you're a maintainer
or that you've seen
worst in the past (were indeed you were not the ones doing the hard work at
the time).
It might be a very personal opinion, though I think there have been a
serious downgrade in
bitcoin core culture about technical proposals, where it was estimated that
the code was broken
to a more current culture of first not making wawe and to be always
"constructive" (even if no
ones knows exactly what does it mean to be constructive when a technical
proposal has been analyzed
to be broken and when it's reasonably wiser to abandon months of
engineering effort rather to
jeopardize end users funds safety) [0].
[0] https://github.com/bitcoin-core/meta/blob/main/MODERATION-GUIDELINES.md
Quote: "One can just have a look on the newer moderation rules, where it is
explicitly said "on the
understanding that it is easier to rephrase deleted comments to be
constructive and respectful
than to replace long term contributors who are burnt out from a discussion
culture that is
unnecessarily contentious and overbearing" [0].
I think here some astute minds could observe that progress in the domain of
scientific ideas if one
complete history on few centuries are driven a lot by controversy,
overbearing experiments done again
and again and argumentation layout repeated multiple times in front of many
audiences, as some brilliant
ideas might be counter-intuitive at first.
With all said and joining on your suggestion to fork core or have in-place
multiple security
mailing lists. On the former this does not abstract from gathering enough
dedicated experts
behind the same codebase, though more importantly maintaining a culture of
collaboration among
the different full-node implementation. If it's go back to the situation of
Bitcoin XT fork
and Bitcoin Segwit2X, where experts are fighting each other to "dictate"
the consensus rules
this is not worth it. New civil war in bitcoin is a situation where
everyone will be at loss.
On the latter suggestion, multiple security list is more or less already
the current dynamics
as historically you had coordination among lightning implementations or
with the mining ecosystem.
Whatever the reality of a single endpoint, at the end of the day it's more
a "peer-to-peer" dynamic,
after a while you know you can personally trust and who is very skilled in
area X or area Y or bitcoin.
Degree and goodwill of collaboration is more important that the
communication channel itself, as some
bitcoin core contributors reveals publicly recently what was more or less
known in internal circles about
the project management of security issues [1]:
[1] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w
Quote: "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."
I hope certainly there will be some cultural electro shocks, of which
Peter's present disclosure email
can consistute an opportunity for a lot of people to medidate on, that we
improve the security of the bitcoin
ecosystem at large by adopting good security issues handling process. And
that before we're seeing massively
contract protocols and second layers being p0wned by North Korea sponsored
hacking groups -- if the evidences
gathered by the wider cybersecurity community is correct on this front.
Reader beware - All those historical considerations on the evolution of
bitcoin core culture only represents
my own opinion, this is necessarily the reflect of my subjective experience
as a contributor and there is no need
to trust me.
Best,
Antoine
ots hash: a58adf148ac756bf5e0cb5cb44fdf6baf8874e71cc64df70a76d46a9472c6891
--
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/1f6d6917-01f1-496d-9c97-8513fce24149n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 9584 bytes --]
^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2024-07-24 0:46 UTC | newest]
Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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-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
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-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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox