* [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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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-08-01 5:57 ` Garlo Nicon 2024-07-24 0:35 ` Antoine Riard 1 sibling, 2 replies; 42+ 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] 42+ 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 2024-08-01 5:57 ` Garlo Nicon 1 sibling, 0 replies; 42+ 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] 42+ 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 @ 2024-08-01 5:57 ` Garlo Nicon 1 sibling, 0 replies; 42+ messages in thread From: Garlo Nicon @ 2024-08-01 5:57 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 10415 bytes --] > Here is a last resort solution by launching this attack in production. I hope you will pick some testnet, for example testnet3 or testnet4, or even signet, instead of launching it on mainnet. Also because test networks are better suited for file sharing scenarios, because if coins are worthless, and there are no real transactions, then pushing data is the only purpose of such network. Probably, doing it on testnet4 is the easiest target, because of 50 tBTC reward (which means: 5 GB spamming ability per block, if you use 1 sat/vB). poniedziałek, 22 lipca 2024 o 14:07:41 UTC+2 Anonymous User napisał(a): > 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/24cd7816-1912-41f9-a6ef-f740801245e2n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 12552 bytes --] ^ permalink raw reply [flat|nested] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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-30 4:57 ` David A. Harding 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, 2 replies; 42+ 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] 42+ 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 2024-07-30 4:57 ` David A. Harding 1 sibling, 1 reply; 42+ 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] 42+ 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; 42+ 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] 42+ 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-30 4:57 ` David A. Harding 2024-07-30 19:38 ` Peter Todd 2024-08-16 4:20 ` Antoine Riard 1 sibling, 2 replies; 42+ messages in thread From: David A. Harding @ 2024-07-30 4:57 UTC (permalink / raw) To: Antoine Riard; +Cc: Bitcoin Development Mailing List On 2024-07-20 16:10, Antoine Riard wrote: > If you or anoyone think TRUC as an alternative to the CPFP as a > transaction pinning mitigation as argued in its merged BIP is easy to > reason on [...] Before I address your full point, I think there are two separate things we want to reason about when considering a proposal like TRUC: - How does it affect operators of full nodes, including miners and volunteer relay node operators? - How does it affect existing and future protocol users? By "easy to reason about", I'm mainly referring to how TRUC will affect operators of full nodes. IMO, it's critical to get that part right. In comparing TRUC to RBFR, it seems to me that it's much easier to reason about TRUC's effect on relay behavior and mining profitability. When it comes to reasoning about pinning attacks against LN, this is almost fundamentally difficult owing to the difficulty of reasoning about any complex state protocol, especially one that interacts with multiple layers of multiple other protocol (e.g., TCP/IP, Bitcoin P2P, Bitcoin consensus). Whether we're talking about CPFP, CPFP-CO, opt-in RBF, full-RBF, pure-RBFR, one-shot RBFR, APO, CTV, CAT, TRUC, or anything else, reasoning about the full implications of a change for LN users will be difficult. IMO, when Bitcoin Core developers ship an opt-in feature like BIP431 TRUC, it is not their responsibility to ensure that it is perfectly safe for downstream projects. That onus falls on the downstream developers (e.g., LN devs). Of course, Bitcoin Core devs want to produce useful tools and that incentivizes them to produce actual safety improvements; however, it's unreasonable IMO to expect Bitcoin Core devs to understand a downstream protocol as well as the devs who work directly on that protocol. For something like imbued TRUC, it probably shouldn't be used to replace an existing mechanism that downstream devs depend on (see subsequent arguments) unless the downstream devs agree (or there's another very compelling reason). Again, the onus falls on the downstream developers to audit the mechanism's safety because they're the ones with theoretical and operational experience using the downstream protocol. Now on to your full point: > 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. How would that work? AFAIK, there's no LN software using TRUC, very few relay nodes are using it (since it isn't yet enabled by default in a release version), and no miners are using it (again, since it hasn't been released). I'm willing to put money at stake to settle a disagreement that can't be settled with words, but I want to at least learn something from the process. My guess is that you're referring to the type of pinning attack you've called "loophole pinning"[1], which I don't entirely understand, so I'll do my best to describe it below and hopefully you can correct me on any errors: - Mallory guesses that, for the next 144 blocks, transactions in the mempool with a feerate of _x_ sats/vb will neither be confirmed nor evicted. If Mallory guesses wrong, the attack will fail. - Mallory controls a confirmed UTXO that she will spend in 10 different fee bumping transactions, making all of those transactions conflict. - Mallory has 10 channels. It doesn't matter whether these are all with the same counterparty, different counterparties, or a mix of counterparties. - In each channel: - Mallory causes the channel to contain the maximum number of in-flight HTLCs the counterparty will allow, creating state _A_. Each in-flight HTLC inflates the size of the commitment transaction about ~40 vbytes. The specification maximum for in-flight HTLCs is 2*483, but many implementations default to a lower value due to risks from other known attacks. - Mallory causes all of the in-flight HTLCs to be settled honestly, revoking state _A_ that contained them. - Mallory causes a single HTLC to be sent through the channel. Its satoshi value is chosen to be roughly equal to: x * (vbytes(A) + 1000), where _x_ is Mallory non-confirming-non-expiring feerate, vsize(A) is the size of the revoked commitment transaction, and 1,000 is the maximum size of a TRUC fee-bumping child. For example, if _x_ is 20 sat/vbyte and vbytes(A) is 2,000, the HTLC value is 60,000 sat. - Although Mallory knows the preimage necessary to resolve the HTLC, she doesn't send it to her counterparty offchain. This will eventually force the counterparty to go onchain. - Mallory goes onchain first by broadcasting a package that consists of the revoked state _A_ and a CPFP fee bump 1,000 vbytes in size that pays a total fee equal to the pending HTLC value (e.g. 60,000 sat). - Notably, Mallory is doing this in 10 channels simultaneously with the fee bump for each spending the same UTXO, so all of those fee bumps conflict with each other. If Mallory broadcasts each package of revoked commitment transaction and fee bump to different nodes across the network, each particular package will only exist in the mempools of about 10% of nodes. - In some cases, Mallory's channel counterparty will receive the revoked commitment transaction via their own mempool monitoring code. - If they realize the feerate is below the amount necessary to get the transaction confirmed within the next 144 blocks, they will be able to CPFP fee bump the transaction themselves---but they will need to pay more than the 60,000 sat in fees that Mallory is offering. However, the pending HTLC is only worth 60,000 sat to them, so it may not make sense for them to fee bump. - In other cases, Mallory's channel counterparty will receive one of the conflicting packages. They will not know that a revoked commitment transaction has been broadcast. - When Mallory hasn't settled the HTLC fast enough, they will broadcast a package of their own commitment transaction and their own CPFP fee bump child. This will pay a higher feerate than Mallory paid (which is possible to do under the 60,000 sat budget because they're using much smaller transactions). - Their high feerate package will propagate until it encounters relay nodes that have their channel's revoked commitment transaction. Although the counterparty's transaction pays a higher feerate, it pays less absolute fees than Mallory's transaction and will be rejected by that relay node. - In any cases where the pinning prevents confirmation within 144 blocks, the HTLC's upstream node can claim a refund and Mallory can then use her preimage to steal the HTLC value from her counterparty, completing the attack successfully. - To settle the HTLC with its preimage, Mallory needs to pay more absolute fees to remove her pin, but because she pinned 10 channels with a single UTXO, paying to remove the pin from one channel and getting that spend confirmed will automatically remove the pin from all other channels. In other words, her cost per channel is roughly 10% what her honest counterparties would've had to pay to remove the pin. - However, once Mallory's pin is removed, all the counterparties should still broadcast spends of the HTLC-Failure transaction paying the HTLC's full value to fees in order to deprive Mallory of any profit. Given the first point and the last point, I'm not sure how viable the attack is (but, as I said, I'm not sure I understand it). Estimating or manipulating feerates correctly for over 144 blocks in a row sounds difficult. Counterparties being able to deprive Mallory of profit seems like a major weakness. Looking at other proposed improvements: one-shot RBFR with its requirement that fee bumps enter the top portion of the mempool may avoid this type of pinning; ideas for expanded versions of TRUC that also require entering the top portion of the mempool may also avoid this type of pinning, e.g. "TRUC v3.0.5".[2] > About replace-by-feerate, I think it's a solution that have downside > on its own, especially for second-layers like lightning. If it looked like RBFR was going to be widely deployed, I think its effect on LN would definitely warrant more research. > 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 > [...] > So unless someone argued to the contrary, saying TRUC was needed to > then deploy cluster mempool is an intellectual fallacy You described several attacks against anchor outputs using CPFP-CO, some of which sound quite plausible to me, but none of them is certain to succeed in any particular instance. By comparison, disabling CPFP-CO would leave all users of anchor outputs immediately vulnerable to the original pinning attack that has an expected ~100% success rate and barely any cost if executed against multiple channels simultaneously. Given that, it makes no sense to disable CPFP-CO until a successor is available. > 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 [...]) Thank you for your opinion. I too think TRUC is a good solution until we find something better, and any significant improvements may indeed require consensus changes. -Dave [1] https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1888377830 [2] https://delvingbitcoin.org/t/v3-and-some-possible-futures/523 -- 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/4e959cdbe70b1a3b9f1adb37fe3b986e%40dtrt.org. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core 2024-07-30 4:57 ` David A. Harding @ 2024-07-30 19:38 ` Peter Todd 2024-08-16 4:45 ` Antoine Riard 2024-08-16 4:20 ` Antoine Riard 1 sibling, 1 reply; 42+ messages in thread From: Peter Todd @ 2024-07-30 19:38 UTC (permalink / raw) To: David A. Harding; +Cc: Antoine Riard, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 2356 bytes --] On Mon, Jul 29, 2024 at 06:57:17PM -1000, David A. Harding wrote: > Given the first point and the last point, I'm not sure how viable the > attack is (but, as I said, I'm not sure I understand it). Estimating or > manipulating feerates correctly for over 144 blocks in a row sounds > difficult. Counterparties being able to deprive Mallory of profit seems > like a major weakness. It is not. I've actually *accidentally* exploited this type of pinning vector a few times in Lighting channels by simply force closing them at times when fee-rates were high. I've even twice managed to delay the force close of a channel by testing out justice transactions by broadcasting a low fee-rate, revoked commitment, which the counterparty node did not notice. Instead, the channel just stayed in limbo for a few days until the node finally got in a normal force-close using the non-revoked state after fees reduced. In both cases, both endpoints were LND using compact block filters (I was running both nodes in these tests). IIUC the LND compat block filter implementation does not track mempool transactions, so it only notices revoked commitment transactions when they appear in blocks (notice how this means that the lack of package relay will render LND's fee-bumping code potentially useless if the conflicting commitment transaction is equal or greater fee/fee-rate). I haven't tried fully exploiting this particular scenario by maximizing the number of HTLCs in flight; I was just trying out stuff manually. Someone should. It should be relatively easy to automate this class type of attack by simply picking opportunities for it based on fee rates. It's quite common for fee spikes to cause conditions where you can easily predict that fees won't go below certain levels for many blocks in the future, multiple days even. Your claim that "estimating feerates correctly for over 144 blocks in a row sounds difficult" is very wrong. -- 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/ZqlBKVXBKKIurBPk%40petertodd.org. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core 2024-07-30 19:38 ` Peter Todd @ 2024-08-16 4:45 ` Antoine Riard 0 siblings, 0 replies; 42+ messages in thread From: Antoine Riard @ 2024-08-16 4:45 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 5602 bytes --] Hi Peter, > It is not. > > I've actually *accidentally* exploited this type of pinning vector a few times > in Lighting channels by simply force closing them at times when fee-rates were > high. I've even twice managed to delay the force close of a channel by testing > out justice transactions by broadcasting a low fee-rate, revoked commitment, > which the counterparty node did not notice. Instead, the channel just stayed > in limbo for a few days until the node finally got in a normal force-close > using the non-revoked state after fees reduced. In both cases, both endpoints > were LND using compact block filters (I was running both nodes in these tests). > IIUC the LND compat block filter implementation does not track mempool > transactions, so it only notices revoked commitment transactions when they > appear in blocks (notice how this means that the lack of package relay will > render LND's fee-bumping code potentially useless if the conflicting commitment > transaction is equal or greater fee/fee-rate). > > I haven't tried fully exploiting this particular scenario by maximizing the > number of HTLCs in flight; I was just trying out stuff manually. Someone > should. > > It should be relatively easy to automate this class type of attack by simply > picking opportunities for it based on fee rates. It's quite common for fee > spikes to cause conditions where you can easily predict that fees won't go > below certain levels for many blocks in the future, multiple days even. Your > claim that "estimating feerates correctly for over 144 blocks in a row sounds > difficult" is very wrong. After reading Dave description of the "loophole pinning" attack, which is a re-formalization of my gitub comment on one of the TRUC PR, I'm not entirely sure, we're describing the same exploitation scenario. Finely evaluating the viability of an attack, before the attack scheme and attacker capabilities are fleshed out is a bit premature... Especially, when you're saying few more lines after that you have tried to fully exploit this scenario with HTLCs in flights, and all other attempts were more accidental and without being sure the LND software correctly implements RBF, including the rule 5 penalty computation at all time (you're observing yourself the limitations of LND's fee-bumping code). If there is a lightning node on mainnet of yours that your formally authorize me to test some pinning attacks, I could try a demo. Alternatively, I can setup a LN node + full-node on some long-running infrastructure, if you wish to try the scenario on your side. Though, as observed by Dave there is no lightning code written yet to opt-in into TRUC transactions. On the last observation, I agree with you that is a class type of attack that one could automate by leveraging fee-estimation algorithms. Best, Antoine ots hash: a958c5bf1a5af3f3fd2b3788b201b95707621cfecc9b1478075a0da4d8c5c0a5 Le mardi 30 juillet 2024 à 20:58:08 UTC+1, Peter Todd a écrit : > On Mon, Jul 29, 2024 at 06:57:17PM -1000, David A. Harding wrote: > > Given the first point and the last point, I'm not sure how viable the > > attack is (but, as I said, I'm not sure I understand it). Estimating or > > manipulating feerates correctly for over 144 blocks in a row sounds > > difficult. Counterparties being able to deprive Mallory of profit seems > > like a major weakness. > > It is not. > > I've actually *accidentally* exploited this type of pinning vector a few > times > in Lighting channels by simply force closing them at times when fee-rates > were > high. I've even twice managed to delay the force close of a channel by > testing > out justice transactions by broadcasting a low fee-rate, revoked > commitment, > which the counterparty node did not notice. Instead, the channel just > stayed > in limbo for a few days until the node finally got in a normal force-close > using the non-revoked state after fees reduced. In both cases, both > endpoints > were LND using compact block filters (I was running both nodes in these > tests). > IIUC the LND compat block filter implementation does not track mempool > transactions, so it only notices revoked commitment transactions when they > appear in blocks (notice how this means that the lack of package relay will > render LND's fee-bumping code potentially useless if the conflicting > commitment > transaction is equal or greater fee/fee-rate). > > I haven't tried fully exploiting this particular scenario by maximizing the > number of HTLCs in flight; I was just trying out stuff manually. Someone > should. > > It should be relatively easy to automate this class type of attack by > simply > picking opportunities for it based on fee rates. It's quite common for fee > spikes to cause conditions where you can easily predict that fees won't go > below certain levels for many blocks in the future, multiple days even. > Your > claim that "estimating feerates correctly for over 144 blocks in a row > sounds > difficult" is very wrong. > > -- > 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/04a22956-b722-4f6c-b8d5-0f8905359721n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 6889 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core 2024-07-30 4:57 ` David A. Harding 2024-07-30 19:38 ` Peter Todd @ 2024-08-16 4:20 ` Antoine Riard 1 sibling, 0 replies; 42+ messages in thread From: Antoine Riard @ 2024-08-16 4:20 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 30910 bytes --] Hi Dave, Apologies for the late answer, I was hiking in nature over the past few days. > Before I address your full point, I think there are two separate things > we want to reason about when considering a proposal like TRUC: > > - How does it affect operators of full nodes, including miners and > volunteer relay node operators? > > - How does it affect existing and future protocol users? > > By "easy to reason about", I'm mainly referring to how TRUC will affect > operators of full nodes. IMO, it's critical to get that part right. In > comparing TRUC to RBFR, it seems to me that it's much easier to reason > about TRUC's effect on relay behavior and mining profitability. I think it's a correct categorization, with the observation that it can be more interesting to dissociate miners from volunteer relay node operators in the analysis of a proposal like TRUC. Miners have the ability to discretely mine non-standard transactions in their block template, contrary of relay nodes. This observation matters practically e.g w.r.t dust HTLC exposure where miners have an edge to launch that type of attacks. > When it comes to reasoning about pinning attacks against LN, this is > almost fundamentally difficult owing to the difficulty of reasoning > about any complex state protocol, especially one that interacts with > multiple layers of multiple other protocol (e.g., TCP/IP, Bitcoin P2P, > Bitcoin consensus). Whether we're talking about CPFP, CPFP-CO, opt-in > RBF, full-RBF, pure-RBFR, one-shot RBFR, APO, CTV, CAT, TRUC, or > anything else, reasoning about the full implications of a change for LN > users will be difficult. I don't deny it, with the addition that you have to reason on how the LN game-theory incentives can play out, in a system where all the balances are denominated in satoshis, a scarce ressource under the max money consensus limit. And I'll keep the conversation simple, as there is always the risk when you're designing second-layers protocol extensions to have backfire coupling effects on the base-layer (-- one of the main technical reason we never actually rolled out forward the proof-of-UTXO ownership designed with naumenkogs as a channel jamming mitigation is the base-layer spam risks introduced to bypass it). > IMO, when Bitcoin Core developers ship an opt-in feature like BIP431 > TRUC, it is not their responsibility to ensure that it is perfectly safe > for downstream projects. That onus falls on the downstream developers > (e.g., LN devs). Of course, Bitcoin Core devs want to produce useful > tools and that incentivizes them to produce actual safety improvements; > however, it's unreasonable IMO to expect Bitcoin Core devs to understand > a downstream protocol as well as the devs who work directly on that > protocol. This is where we have a strong divergence, with all my appreciation of your viewpoint. In my opinion this shall be the responsibility of the Bitcoin Core developers to ensure there is a reasonable safety of the design and implemented mechanism for downstream projects. Experience of the last years, most notably the half of dozen of security weakness loss of funds found in the design or implementation of anchor outputs (the lack of carve out support at first, the revocation escape, the new pinning vector due to legacy merging of second-stage transactions, the parsing error of core lightning / lnd...) can only point out to seasoned technical observers that weakness arises because of the poor understanding of protocols operational inter-dependency. That practical bitcoin experience is matching some observations documented by the IETF in decades of design and development of the TCP / IP stack (RFC 3439) [0]. Under the coupling principle, that as things gets larger, they often exhibit increased inter-dependence between components, and with unforseen feature interaction. In the bitcoin space a good incarnation is all the bip125 rule 3 based economical pinnings, that I don't believe were clearly expected by their bip authors. [0] https://www.rfc-editor.org/rfc/rfc3439 Obviously, there is a sense of proportion to guard and that all Bitcoin Core devs shall understand downstream protocols as well as the devs who work directly on that protocol does not appear realistic, given the wider variety of other subsystems such as builds, graphic interface or p2p block-relay protocol. _However_, I strongly believe that Bitcoin Core devs working in the subsystem interfacing with downstream protocols such as the mempool or the transaction-relay protocol should have an understood as good as the downstream devs of said protocol inner workings. Otherwise, by designing, implementing and deploying weak proposals such as TRUC in its earlier versions they might cause more harms than good, on the _long term_. One cannot said there was technical consensus with the merge of TRUC, in the sense of lack of standing grounded objections, be it by the RBFR author, or myself directly on the PR / issues implementing this design in Bitcoin Core. > For something like imbued TRUC, it probably shouldn't be used to replace > an existing mechanism that downstream devs depend on (see subsequent > arguments) unless the downstream devs agree (or there's another very > compelling reason). Again, the onus falls on the downstream developers > to audit the mechanism's safety because they're the ones with > theoretical and operational experience using the downstream protocol. One should not forget that downstream protocol devs and contributors e.g for lightning are mostly working for commercial companies, with for some on short business timelines. This is very likely to induce them to pick up an expedient mechanism, without fully auditing it, more than jeopardizing the end-users funds safety (and the crypto space at large does not miss spectacular vulnerabilities exploitation). Sadly, one cannot expect that Bitcoin Core devs contributors to be immune of short-term external factors in the design of better mempool mechanism as in 2020 while I was advocating to build a better understanding of cross-layers security among contributors [1]. Yet, at the very same time the current author of TRUC and bip331 was doing a round of the medias to "sell" the idea and correspondingly attract open-source funding before there was even the lineaments of a technical consensus among contributors to the Bitcoin Core project, or what you call the downstream devs like lightning [2]. [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002856.html [2] https://bitcoinmagazine.com/technical/gloria-zhao-and-brink-are-set-to-give-bitcoin-mempools-an-upgrade (It's not like there has been a precedent in bitcoin development with the extension block bip idea from joseph poon...which was proposed in 2017 in a fashion less than usual w.r.t traditional communication channels...) So yes, I think there should be a cultural change in terms of design and deployment of p2p or mempool policy mechanisms supporting downstream protocols. In my opinion, which is backed by my first code review of the imbuance mechanism, current development process is still on the same pace, heading us in nurturing more cross-layer vectors of attacks like pinning due to complex misinterfacing or mempoolfullrbf default-like difficult campaigns of deprecation. > 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. > How would that work? AFAIK, there's no LN software using TRUC, very few > relay nodes are using it (since it isn't yet enabled by default in a > release version), and no miners are using it (again, since it hasn't > been released). I'm willing to put money at stake to settle a > disagreement that can't be settled with words, but I want to at least > learn something from the process. Thank you for the offer of setting up a demo infrastructure for pinning attacks experiment. I'll describe more what is the minimal setup needed in another public email thread or on delving bitcoin. Less than the funds in the channel, it's interesting to have a full vanilla configuration on mainnet to avoid running in the myriad of cases with policy standardss and the mempool congestion roallcoaster on whatever is the testnet / signet of the day. I can even put the satosis for funding the channnels if it's really needed. It's correct that TRUC is not implemented in LN in where commitments transactions are nVersion field updated to be pre-signed with TRUC semantics... I can always write a patch in C or rust to have test code ? Though here I would play both the attacker and defender role in the experiment. At least, I think it would be worthwile on its own to test current bip125 rule 3-based economic pinnings, without TRUC usage. > My guess is that you're referring to the type of pinning attack you've > called "loophole pinning"[1], which I don't entirely understand, so I'll > do my best to describe it below and hopefully you can correct me on any > errors: > > - Mallory guesses that, for the next 144 blocks, transactions in the > mempool with a feerate of _x_ sats/vb will neither be confirmed nor > evicted. If Mallory guesses wrong, the attack will fail. > > - Mallory controls a confirmed UTXO that she will spend in 10 different > fee bumping transactions, making all of those transactions conflict. > > - Mallory has 10 channels. It doesn't matter whether these are all with > the same counterparty, different counterparties, or a mix of > counterparties. > > - In each channel: > > - Mallory causes the channel to contain the maximum number of > in-flight HTLCs the counterparty will allow, creating state _A_. > Each in-flight HTLC inflates the size of the commitment transaction > about ~40 vbytes. > > The specification maximum for in-flight HTLCs is 2*483, but many > implementations default to a lower value due to risks from other > known attacks. > > - Mallory causes all of the in-flight HTLCs to be settled honestly, > revoking state _A_ that contained them. > > - Mallory causes a single HTLC to be sent through the channel. Its > satoshi value is chosen to be roughly equal to: x * (vbytes(A) + > 1000), where _x_ is Mallory non-confirming-non-expiring feerate, > vsize(A) is the size of the revoked commitment transaction, and > 1,000 is the maximum size of a TRUC fee-bumping child. > > For example, if _x_ is 20 sat/vbyte and vbytes(A) is 2,000, the HTLC > value is 60,000 sat. > > - Although Mallory knows the preimage necessary to resolve the HTLC, > she doesn't send it to her counterparty offchain. This will > eventually force the counterparty to go onchain. > > - Mallory goes onchain first by broadcasting a package that consists > of the revoked state _A_ and a CPFP fee bump 1,000 vbytes in size > that pays a total fee equal to the pending HTLC value (e.g. 60,000 > sat). > > - Notably, Mallory is doing this in 10 channels simultaneously with the > fee bump for each spending the same UTXO, so all of those fee bumps > conflict with each other. If Mallory broadcasts each package of > revoked commitment transaction and fee bump to different nodes across > the network, each particular package will only exist in the mempools > of about 10% of nodes. > > - In some cases, Mallory's channel counterparty will receive the > revoked > commitment transaction via their own mempool monitoring code. > > - If they realize the feerate is below the amount necessary to get > the > transaction confirmed within the next 144 blocks, they will be > able > to CPFP fee bump the transaction themselves---but they will need > to pay more than the 60,000 sat in fees that Mallory is offering. > However, the pending HTLC is only worth 60,000 sat to them, so it > may not make sense for them to fee bump. > > - In other cases, Mallory's channel counterparty will receive one of > the > conflicting packages. They will not know that a revoked commitment > transaction has been broadcast. > > - When Mallory hasn't settled the HTLC fast enough, they will > broadcast a package of their own commitment transaction and their > own CPFP fee bump child. This will pay a higher feerate than > Mallory paid (which is possible to do under the 60,000 sat budget > because they're using much smaller transactions). > > - Their high feerate package will propagate until it encounters > relay > nodes that have their channel's revoked commitment transaction. > Although the counterparty's transaction pays a higher feerate, it > pays less absolute fees than Mallory's transaction and will be > rejected by that relay node. > - In any cases where the pinning prevents confirmation within 144 > blocks, the HTLC's upstream node can claim a refund and Mallory can > then use her preimage to steal the HTLC value from her counterparty, > completing the attack successfully. > > - To settle the HTLC with its preimage, Mallory needs to pay more > absolute fees to remove her pin, but because she pinned 10 channels > with a single UTXO, paying to remove the pin from one channel and > getting that spend confirmed will automatically remove the pin from > all other channels. In other words, her cost per channel is roughly > 10% what her honest counterparties would've had to pay to remove the > pin. > > - However, once Mallory's pin is removed, all the counterparties > should still broadcast spends of the HTLC-Failure transaction > paying the HTLC's full value to fees in order to deprive Mallory > of any profit. The assumption is correct that Mallory makes a prediction on a level of mempool congestion for a target feerate group, and this is a factor or success or not of the attack. It should be noted, there is no need to revoke the state or not in this pinning, one can use the non-revoked consensus valid transaction, I think this is the main difference with my scenario where non-revoked transactions are used to do the "staggering" package (i.e the one at 60,000 sat in your example), before to be "unstagged" by the same absolute fee, higher feerate, penalty-paying package. The parallelization can allow the attacker to not pay the cost, there is no necessity that it is happening on parallel channels, as one can double-spend from the CPFP of a "batching transaction, whatever else it is doing. > Given the first point and the last point, I'm not sure how viable the > attack is (but, as I said, I'm not sure I understand it). Estimating or > manipulating feerates correctly for over 144 blocks in a row sounds > difficult. Counterparties being able to deprive Mallory of profit seems > like a major weakness. On the first point, if I'm understanding correctly it's about predicting mempool congestion as a factor of success of the attack. It's not a perfect art though it's quite practical for an attacker as it is what mempool fee estimation algorithms are all about. On the last point, i.e the HTLC-Failure transaction paying the full value to the fees, this HTLC-Failure confirmation should happen only after the double-spend of the inbound HTLC by a puppet of Mallory. Until this on-chain confirmation of the malicious inbound HTLC-failure, the Alice's outbound HTLC-failure is blocked by the pinning. Note, this is _not_ a replacement cycling attack, as it's all relying on the Mallory's package being on an absolute fee / feerate too high to be replaced by a Alice's package. I understand it's hard to understand, and it sounds your attack layout could benefit from adding lightning topology on the left / right side of Alice as the attack victim. Note, how mempool congestion could play as a pinning vector was slightly surveyed in the discussion of package relay design in 2020, though no more fleshed-out write-up or blog post has been made available since then until my comment on the Bitcoin Core PR, to the best of my knowledge [4]. [4] https://github.com/bitcoin/bitcoin/issues/14895#issuecomment-665907792 > Looking at other proposed improvements: one-shot RBFR with its > requirement that fee bumps enter the top portion of the mempool may > avoid this type of pinning; ideas for expanded versions of TRUC that > also require entering the top portion of the mempool may also avoid this > type of pinning, e.g. "TRUC v3.0.5".[2]. I have not yet analyzed one-shot RBFR in more detailed, though I believe a better long-term fix is actually _not_ to entangle the mempool states with transaction-relay propagation rules. A full-node mempoool is a stateful cache with public write allowed. > If it looked like RBFR was going to be widely deployed, I think its > effect on LN would definitely warrant more research. If mempool acceptance was more modular in Bitcoin Core, we could have more fine-grained transaction acceptance policy module embedded in the `AcceptToMemoryPool` flow and easier to experiment the effects of alternative policy like RBFR on LN. > You described several attacks against anchor outputs using CPFP-CO, some > of which sound quite plausible to me, but none of them is certain to > succeed in any particular instance. By comparison, disabling CPFP-CO > would leave all users of anchor outputs immediately vulnerable to the > original pinning attack that has an expected ~100% success rate and > barely any cost if executed against multiple channels simultaneously. > > Given that, it makes no sense to disable CPFP-CO until a successor is > available. In a world where revoked lightning transactions are still consensus-valid and where any of them can be used to blind the lightning node of the correct CPFP to proceed with, the carve-out is ineffective. I'll let you indicate me where in the bolt spec it is indicated how lightning software should implement correctly CPFP of the carve-out, as it is implemented and deployed in Bitcoin Core since circa 2019. I won't say the carve-out mechanism has been "fast" shipped in 2019 and that its authors might really not know how lightnning was working at the time. However, I believe there has never been a bip or other document informing how it should be used by downtream protocols. > Thank you for your opinion. I too think TRUC is a good solution until > we find something better, and any significant improvements may indeed > require consensus changes. Thank too for your opinion. I think TRUC is an acceptable temporary solution to minimize lightning pinning surface, however I'm still worried on the long-term it can have undesirable side-effect, in a world where miners are running "heretic" transaction acceptance policy. And it's making a false security guarantee for lightning nodes, as uniform policy is not a network reality, and an associated full-node could be paired with peers not respecting TRUC semantics -- I know I've advocated uniform policy w.r.t package relay to improve lightning safety in the past, though after finding vulnerability vectors arising from a policy rule like opt-in RBF and asymmetrically affecting use-cases (0conf vs LN), I'm far more skeptical in grounding downstream protocols safety on mechanism like TRUC. Best, Antoine ots hash: 42407994c5e58123bf2535ba420517f83b95977052b4bde4ff9e115b91e2b598 Le mardi 30 juillet 2024 à 06:48:19 UTC+1, David A. Harding a écrit : > On 2024-07-20 16:10, Antoine Riard wrote: > > If you or anoyone think TRUC as an alternative to the CPFP as a > > transaction pinning mitigation as argued in its merged BIP is easy to > > reason on [...] > > Before I address your full point, I think there are two separate things > we want to reason about when considering a proposal like TRUC: > > - How does it affect operators of full nodes, including miners and > volunteer relay node operators? > > - How does it affect existing and future protocol users? > > By "easy to reason about", I'm mainly referring to how TRUC will affect > operators of full nodes. IMO, it's critical to get that part right. In > comparing TRUC to RBFR, it seems to me that it's much easier to reason > about TRUC's effect on relay behavior and mining profitability. > > When it comes to reasoning about pinning attacks against LN, this is > almost fundamentally difficult owing to the difficulty of reasoning > about any complex state protocol, especially one that interacts with > multiple layers of multiple other protocol (e.g., TCP/IP, Bitcoin P2P, > Bitcoin consensus). Whether we're talking about CPFP, CPFP-CO, opt-in > RBF, full-RBF, pure-RBFR, one-shot RBFR, APO, CTV, CAT, TRUC, or > anything else, reasoning about the full implications of a change for LN > users will be difficult. > > IMO, when Bitcoin Core developers ship an opt-in feature like BIP431 > TRUC, it is not their responsibility to ensure that it is perfectly safe > for downstream projects. That onus falls on the downstream developers > (e.g., LN devs). Of course, Bitcoin Core devs want to produce useful > tools and that incentivizes them to produce actual safety improvements; > however, it's unreasonable IMO to expect Bitcoin Core devs to understand > a downstream protocol as well as the devs who work directly on that > protocol. > > For something like imbued TRUC, it probably shouldn't be used to replace > an existing mechanism that downstream devs depend on (see subsequent > arguments) unless the downstream devs agree (or there's another very > compelling reason). Again, the onus falls on the downstream developers > to audit the mechanism's safety because they're the ones with > theoretical and operational experience using the downstream protocol. > > Now on to your full point: > > > 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. > > How would that work? AFAIK, there's no LN software using TRUC, very few > relay nodes are using it (since it isn't yet enabled by default in a > release version), and no miners are using it (again, since it hasn't > been released). I'm willing to put money at stake to settle a > disagreement that can't be settled with words, but I want to at least > learn something from the process. > > My guess is that you're referring to the type of pinning attack you've > called "loophole pinning"[1], which I don't entirely understand, so I'll > do my best to describe it below and hopefully you can correct me on any > errors: > > - Mallory guesses that, for the next 144 blocks, transactions in the > mempool with a feerate of _x_ sats/vb will neither be confirmed nor > evicted. If Mallory guesses wrong, the attack will fail. > > - Mallory controls a confirmed UTXO that she will spend in 10 different > fee bumping transactions, making all of those transactions conflict. > > - Mallory has 10 channels. It doesn't matter whether these are all with > the same counterparty, different counterparties, or a mix of > counterparties. > > - In each channel: > > - Mallory causes the channel to contain the maximum number of > in-flight HTLCs the counterparty will allow, creating state _A_. > Each in-flight HTLC inflates the size of the commitment transaction > about ~40 vbytes. > > The specification maximum for in-flight HTLCs is 2*483, but many > implementations default to a lower value due to risks from other > known attacks. > > - Mallory causes all of the in-flight HTLCs to be settled honestly, > revoking state _A_ that contained them. > > - Mallory causes a single HTLC to be sent through the channel. Its > satoshi value is chosen to be roughly equal to: x * (vbytes(A) + > 1000), where _x_ is Mallory non-confirming-non-expiring feerate, > vsize(A) is the size of the revoked commitment transaction, and > 1,000 is the maximum size of a TRUC fee-bumping child. > > For example, if _x_ is 20 sat/vbyte and vbytes(A) is 2,000, the HTLC > value is 60,000 sat. > > - Although Mallory knows the preimage necessary to resolve the HTLC, > she doesn't send it to her counterparty offchain. This will > eventually force the counterparty to go onchain. > > - Mallory goes onchain first by broadcasting a package that consists > of the revoked state _A_ and a CPFP fee bump 1,000 vbytes in size > that pays a total fee equal to the pending HTLC value (e.g. 60,000 > sat). > > - Notably, Mallory is doing this in 10 channels simultaneously with the > fee bump for each spending the same UTXO, so all of those fee bumps > conflict with each other. If Mallory broadcasts each package of > revoked commitment transaction and fee bump to different nodes across > the network, each particular package will only exist in the mempools > of about 10% of nodes. > > - In some cases, Mallory's channel counterparty will receive the > revoked > commitment transaction via their own mempool monitoring code. > > - If they realize the feerate is below the amount necessary to get > the > transaction confirmed within the next 144 blocks, they will be > able > to CPFP fee bump the transaction themselves---but they will need > to pay more than the 60,000 sat in fees that Mallory is offering. > However, the pending HTLC is only worth 60,000 sat to them, so it > may not make sense for them to fee bump. > > - In other cases, Mallory's channel counterparty will receive one of > the > conflicting packages. They will not know that a revoked commitment > transaction has been broadcast. > > - When Mallory hasn't settled the HTLC fast enough, they will > broadcast a package of their own commitment transaction and their > own CPFP fee bump child. This will pay a higher feerate than > Mallory paid (which is possible to do under the 60,000 sat budget > because they're using much smaller transactions). > > - Their high feerate package will propagate until it encounters > relay > nodes that have their channel's revoked commitment transaction. > Although the counterparty's transaction pays a higher feerate, it > pays less absolute fees than Mallory's transaction and will be > rejected by that relay node. > > - In any cases where the pinning prevents confirmation within 144 > blocks, the HTLC's upstream node can claim a refund and Mallory can > then use her preimage to steal the HTLC value from her counterparty, > completing the attack successfully. > > - To settle the HTLC with its preimage, Mallory needs to pay more > absolute fees to remove her pin, but because she pinned 10 channels > with a single UTXO, paying to remove the pin from one channel and > getting that spend confirmed will automatically remove the pin from > all other channels. In other words, her cost per channel is roughly > 10% what her honest counterparties would've had to pay to remove the > pin. > > - However, once Mallory's pin is removed, all the counterparties > should still broadcast spends of the HTLC-Failure transaction > paying the HTLC's full value to fees in order to deprive Mallory > of any profit. > > Given the first point and the last point, I'm not sure how viable the > attack is (but, as I said, I'm not sure I understand it). Estimating or > manipulating feerates correctly for over 144 blocks in a row sounds > difficult. Counterparties being able to deprive Mallory of profit seems > like a major weakness. > > Looking at other proposed improvements: one-shot RBFR with its > requirement that fee bumps enter the top portion of the mempool may > avoid this type of pinning; ideas for expanded versions of TRUC that > also require entering the top portion of the mempool may also avoid this > type of pinning, e.g. "TRUC v3.0.5".[2] > > > About replace-by-feerate, I think it's a solution that have downside > > on its own, especially for second-layers like lightning. > > If it looked like RBFR was going to be widely deployed, I think its > effect on LN would definitely warrant more research. > > > 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 > > [...] > > So unless someone argued to the contrary, saying TRUC was needed to > > then deploy cluster mempool is an intellectual fallacy > > You described several attacks against anchor outputs using CPFP-CO, some > of which sound quite plausible to me, but none of them is certain to > succeed in any particular instance. By comparison, disabling CPFP-CO > would leave all users of anchor outputs immediately vulnerable to the > original pinning attack that has an expected ~100% success rate and > barely any cost if executed against multiple channels simultaneously. > > Given that, it makes no sense to disable CPFP-CO until a successor is > available. > > > 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 [...]) > > Thank you for your opinion. I too think TRUC is a good solution until > we find something better, and any significant improvements may indeed > require consensus changes. > > -Dave > > [1] > https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1888377830 > [2] https://delvingbitcoin.org/t/v3-and-some-possible-futures/523 > -- 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/11b7ba56-04f1-4ebe-a434-e8478b5efe70n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 34907 bytes --] ^ permalink raw reply [flat|nested] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ 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; 42+ 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] 42+ messages in thread
end of thread, other threads:[~2024-08-16 4:47 UTC | newest] Thread overview: 42+ 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-08-01 5:57 ` Garlo Nicon 2024-07-24 0:35 ` Antoine Riard 2024-07-19 12:41 ` /dev /fd0 2024-07-19 23:56 ` Antoine Riard 2024-07-20 5:57 ` /dev /fd0 2024-07-20 15:08 ` Peter Todd 2024-07-21 2:13 ` Antoine Riard 2024-07-21 6:16 ` /dev /fd0 2024-07-21 2:12 ` Antoine Riard 2024-07-19 18:26 ` [bitcoindev] " Murch 2024-07-20 14:10 ` Peter Todd 2024-07-20 6:41 ` David A. Harding 2024-07-20 15:03 ` Peter Todd 2024-07-20 15:30 ` Peter Todd 2024-07-21 15:35 ` David A. Harding 2024-07-21 20:25 ` Peter Todd 2024-07-24 0:38 ` Antoine Riard 2024-07-21 2:10 ` Antoine Riard 2024-07-22 15:10 ` Peter Todd 2024-07-24 0:41 ` Antoine Riard 2024-07-30 4:57 ` David A. Harding 2024-07-30 19:38 ` Peter Todd 2024-08-16 4:45 ` Antoine Riard 2024-08-16 4:20 ` Antoine Riard 2024-07-22 11:45 ` [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not Peter Todd 2024-07-22 16:43 ` David A. Harding 2024-07-22 20:06 ` Peter Todd 2024-07-22 22:08 ` David A. Harding 2024-07-23 11:29 ` Peter Todd 2024-07-24 0:42 ` Antoine Riard 2024-07-22 17:13 ` [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core Peter Todd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox