* [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
@ 2024-03-18 13:21 Peter Todd
2024-03-19 12:37 ` Nagaev Boris
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Peter Todd @ 2024-03-18 13:21 UTC (permalink / raw)
To: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 5513 bytes --]
RBF Rule #6 requires that a replacement transaction have a fee-rate higher than
the fee-rate of all conflicting transactions. This rule aligns economic
incentives, as in most circumstances miners earn more money by mining a higher
fee-rate transaction than a lower fee-rate transaction, even if the absolute
fee paid by the replacement is more.
While RBF Rule #6 was implemented as part of my original Full-RBF opt-in
pull-req¹, it was mistakenly left out of BIP-125, which was written later by
Harding. Thus it's often forgotten in analysis of RBF.
Rule #6 creates a path dependency: the order in which replacement transactions
are received determines which transactions are ultimately accepted. This
creates an opportunity for free-relay, as follows:
1. Create two transactions, A and B, where A is a large, low fee-rate, high
absolute fee, transaction, and B is a small, high fee-rate, low absolute fee
transaction.
2. Broadcast A and B to different nodes simultaneously.
3. Nodes that receive A first will not replace A with B, because B pays a lower
fee, violating RBF Rule #3. Notes that receive B first, will not replace B with
A, because A has a lower fee-rate, violating RBF Rule #6.
4. Create A_1, a transaction with the same (large) size as A, but paying a
slightly higher fee (and thus fee-rate). Nodes that received A first will
replace A with A_1, consuming bandwidth. These nodes will also broadcast A_1 to
peers who have B, consuming their bandwidth even though they reject A_1.
5. Repeat until A_n has a fee-rate high enough to have a non-trivial risk of
being mined. Or B is mined, invalidating all A_n.
The marginal cost to an attacker who was planning on broadcasting B anyway is
fairly small, as provided that sufficiently small fee-rates are chosen for A_n,
the probability of A_n being mined is low. The attack does of course require
capital, as the attacker needs to have UTXO's of sufficient size for A_n.
The attack is most effective in cases where fee-rates have a significant slope
to them, with the minimum relay fee being small compared to the competitive fee
to get into the next block. The larger the mempool size limit, the more
effective the attack tends to be. Similarly, the attack is more effective with
a larger size difference between A and B. Finally, the attack is more effective
with a smaller minimum incremental relay fee, as more individual versions of
the transaction can be broadcast for a given fee-delta range.
Of course, this attack can be parallelized, with many non-conflicting A_n
chains at once. Depending on P2P topology, maximum bandwidth may be consumable
by broadcasting multiple _conflicting_ A's to different nodes at once², a
fairly obvious attack that I (and probably others) have already disclosed.
# Mitigations
Replace-by-Fee-Rate mitigates the attack, by limiting the possible range of
fee-rate delta. For example, in Libre Relay, which does replace-by-fee-rate at
a fee-rate ratio of >= 2x, if A starts at 3sat/VB, the attacker can only do 2
cycles of the attack as a B >= 6sat/VB will simply replace A.
The attack itself is arguably an economic exploit: *because* Bitcoin Core
doesn't yet implement replace-by-fee-rate, nodes who accepted A first, are
wasting their bandwidth relaying variations on A that are clearly less
desirable to miners than B. An economically rational miner would just mine B
right now, and the fact that _other_ economically rational miners would mine B
just strengthens the case for mining B now. Indeed, real-world measurements of
replace-by-fee-rate have found that (most likely) due to mempool
inconsistencies, roughly half or more³ of RBFR replacements are mined already.
Requiring replacements to increase the fee-rate by a certain ratio would also
mitigate the attack. However doing so would break a lot of wallet software that
bumps fees by values equal or close to the minimum relay fee.
# Related Attacks
Rule #6 is just one of many ways to achieve the same effect: getting a miner to
invalidate a set of large transactions, wasting bandwidth. For example, miners
who accept payment for guaranteeing that a specific transaction gets mined also
make this kind of attack possible.
# Discussion
Ironically, the existence of this attack is an argument in favor of
replace-by-fee-rate. While RBFR introduces a degree of free-relay, the fact
that Bitcoin Core's existing rules *also* allow for free-relay in this form
makes the difference inconsequential.
# Disclosure
This issue was disclosed to bitcoin-security first. I received no objections to
making it public. All free-relay attacks are mitigated by the requirement to at
least have sufficient funds available to allocate to fees, even if the funds
might not actually be spent.
# References
1) https://github.com/bitcoin/bitcoin/pull/6871
2) https://petertodd.org/2024/one-shot-replace-by-fee-rate#the-status-quo
3) https://petertodd.org/2024/replace-by-fee-rate-success-rate
--
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/Zfg/6IZyA/iInyMx%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6 2024-03-18 13:21 [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6 Peter Todd @ 2024-03-19 12:37 ` Nagaev Boris 2024-03-19 13:46 ` Peter Todd 2024-03-22 23:18 ` [bitcoindev] " Antoine Riard 2024-03-26 18:36 ` [bitcoindev] " David A. Harding 2 siblings, 1 reply; 15+ messages in thread From: Nagaev Boris @ 2024-03-19 12:37 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoindev Hi Peter, On Mon, Mar 18, 2024 at 10:24 AM Peter Todd <pete@petertodd•org> wrote: > Rule #6 creates a path dependency: the order in which replacement transactions > are received determines which transactions are ultimately accepted. I'd like to share my thoughts regarding RBFR rules and propose something. The proposed RBFR rule is also path-dependent. Two transactions can conflict with each other, but their fee rates can be too close for one of them to eliminate the other from nodes' mempools. The first transaction a node sees is kept in its mempool. Is it possible to have a rule that is completely path-independent? The eviction rules are path-independent iff, for each pair of conflicting transactions A and B, it is always known which of them should be preferred over the other, and this relation is transitive. Having such a property would be very beneficial in preventing any attacks on the mempool. This property of the mempool can also be seen as the eventual consistency of all the mempools of the nodes. A good property, isn't it? How can we design such a rule system? 1. It must align with miners' incentives; otherwise, it simply won't work. 2. And it must not open the door for DoS attacks on the mempool. The naive approach satisfying the first requirement is a simple rule saying "the higher the fee rate, the more preferential is the transaction." However it does not specify what to do with two transactions of the same fee rate and also doesn't prevent DoS attacks. The former is easy to fix, e.g. preferring the transaction with lower txid. (Must be formally proven though.) Let's discuss the latter, which is a stumbling stone here. Traditionally, the way of preventing DoS was to reject some transactions and to stop their broadcasting at this node. What about deprioritizing them instead? Make two priority queues of transactions in the node: (1) to process incoming transactions and (2) to broadcast. When a transaction is double-spent, it is deprioritized in both queues. If an attacker sends many double-spending transactions to DoS the mempool, not all of them are broadcast further because by the time a transaction is ready to be broadcast, its newer version has already evicted it; the first one is not yet broadcasted. So a node broadcasts fewer transactions than it receives, which reduces the DoS effect. And still, the whole system is eventually consistent; just spammers get their transactions spread slower. What are your thoughts on this scheme? -- Best regards, Boris Nagaev -- 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/CAFC_Vt7BE866DJGQ9EqA%2BDroEkDH%2B4U_72-RpCUfyrLHmtnZ1Q%40mail.gmail.com. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6 2024-03-19 12:37 ` Nagaev Boris @ 2024-03-19 13:46 ` Peter Todd 2024-03-23 0:29 ` Nagaev Boris 0 siblings, 1 reply; 15+ messages in thread From: Peter Todd @ 2024-03-19 13:46 UTC (permalink / raw) To: Nagaev Boris; +Cc: bitcoindev [-- Attachment #1: Type: text/plain, Size: 5313 bytes --] On Tue, Mar 19, 2024 at 09:37:59AM -0300, Nagaev Boris wrote: > Hi Peter, > > On Mon, Mar 18, 2024 at 10:24 AM Peter Todd <pete@petertodd•org> wrote: > > Rule #6 creates a path dependency: the order in which replacement transactions > > are received determines which transactions are ultimately accepted. > > I'd like to share my thoughts regarding RBFR rules and propose something. > > The proposed RBFR rule is also path-dependent. Two transactions can > conflict with each other, but their fee rates can be too close for one > of them to eliminate the other from nodes' mempools. The first > transaction a node sees is kept in its mempool. It's not really fair to say that "the proposed RBFR rule is also path-dependent". What you're describing is a property of Bitcoin Core's mempool in general, for all transaction acceptance rules. We've *always* had the property that two essentially identical transactions, differing only in a trivial way, will be accepted on a first seen basis. Achieving consensus requires bandwidth, and since you can generate an essentially infinite number of almost identical transactions, you'll always be able to find cases with path dependency. > Is it possible to have a rule that is completely path-independent? The > eviction rules are path-independent iff, for each pair of conflicting > transactions A and B, it is always known which of them should be > preferred over the other, and this relation is transitive. Having such > a property would be very beneficial in preventing any attacks on the > mempool. This property of the mempool can also be seen as the eventual > consistency of all the mempools of the nodes. A good property, isn't > it? I'd suggest that you should argue concretely *why* this is a good property. The RBF Rule #6 issue isn't strong evidence, as it's only related to a specific type of meaningful path dependency, where fees/size differ meaningfully. You're talking about all forms of path dependency, including trivial differences where fees/size are the same and only a txid differs due to a trivial change. > How can we design such a rule system? > > 1. It must align with miners' incentives; otherwise, it simply won't work. > 2. And it must not open the door for DoS attacks on the mempool. > > The naive approach satisfying the first requirement is a simple rule > saying "the higher the fee rate, the more preferential is the > transaction." However it does not specify what to do with two > transactions of the same fee rate and also doesn't prevent DoS > attacks. The former is easy to fix, e.g. preferring the transaction > with lower txid. (Must be formally proven though.) Let's discuss the > latter, which is a stumbling stone here. > > Traditionally, the way of preventing DoS was to reject some > transactions and to stop their broadcasting at this node. What about > deprioritizing them instead? Make two priority queues of transactions > in the node: (1) to process incoming transactions and (2) to > broadcast. When a transaction is double-spent, it is deprioritized in > both queues. If an attacker sends many double-spending transactions to > DoS the mempool, not all of them are broadcast further because by the > time a transaction is ready to be broadcast, its newer version has > already evicted it; the first one is not yet broadcasted. So a node > broadcasts fewer transactions than it receives, which reduces the DoS > effect. And still, the whole system is eventually consistent; just > spammers get their transactions spread slower. > > What are your thoughts on this scheme? So first of all, I'll point out that because you can brute force txid variations, if the rule is lowest txid wins, it wouldn't be hard to do a bit of brute forcing to get, say, 2^32 = 4 billion different variations. For practical purposes, that's basically infinite bandwidth. OTOH, suppose the rule is that the txid with the most leading zeros wins. This fixes the infinite bandwidth problem, as it's a clear PoW with something like 48 possible total replacements at most (assuming a reasonable amount of total PoW). But the mempool consensus problem remains unfixed, as there's essentially infinite variations possible with the same number of leading zeros. Bitcoin doesn't have this issue because it has a minimum PoW, set by the difficulty algorithm. But we can't ask that of transactions in general. So I think either way we've failed to actually achieve consensus over trivial variations. More broadly, I like the idea of using a bandwidth constrained channel for doing replacements where there are meaningful, but small, differences in the size and/or fees paid. But I think we should persue the idea on the basis that it makes economic sense. Not that it'll prevent mempools from being out of consensus. -- 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/ZfmXNiscjatFOOCX%40petertodd.org. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6 2024-03-19 13:46 ` Peter Todd @ 2024-03-23 0:29 ` Nagaev Boris 0 siblings, 0 replies; 15+ messages in thread From: Nagaev Boris @ 2024-03-23 0:29 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoindev On Tue, Mar 19, 2024 at 10:46 AM Peter Todd <pete@petertodd•org> wrote: > > On Tue, Mar 19, 2024 at 09:37:59AM -0300, Nagaev Boris wrote: > > Hi Peter, > > > > On Mon, Mar 18, 2024 at 10:24 AM Peter Todd <pete@petertodd•org> wrote: > > > Rule #6 creates a path dependency: the order in which replacement transactions > > > are received determines which transactions are ultimately accepted. > > > > I'd like to share my thoughts regarding RBFR rules and propose something. > > > > The proposed RBFR rule is also path-dependent. Two transactions can > > conflict with each other, but their fee rates can be too close for one > > of them to eliminate the other from nodes' mempools. The first > > transaction a node sees is kept in its mempool. > > It's not really fair to say that "the proposed RBFR rule is also > path-dependent". What you're describing is a property of Bitcoin Core's mempool > in general, for all transaction acceptance rules. We've *always* had the > property that two essentially identical transactions, differing only in a > trivial way, will be accepted on a first seen basis. Achieving consensus > requires bandwidth, and since you can generate an essentially infinite number > of almost identical transactions, you'll always be able to find cases with path > dependency. > > > Is it possible to have a rule that is completely path-independent? The > > eviction rules are path-independent iff, for each pair of conflicting > > transactions A and B, it is always known which of them should be > > preferred over the other, and this relation is transitive. Having such > > a property would be very beneficial in preventing any attacks on the > > mempool. This property of the mempool can also be seen as the eventual > > consistency of all the mempools of the nodes. A good property, isn't > > it? > > I'd suggest that you should argue concretely *why* this is a good property. The > RBF Rule #6 issue isn't strong evidence, as it's only related to a specific > type of meaningful path dependency, where fees/size differ meaningfully. You're > talking about all forms of path dependency, including trivial differences where > fees/size are the same and only a txid differs due to a trivial change. I rethought it and I think I'm wrong. The proposed solution of delaying and skipping won't fix the replacement attack, because the preimage could be a skipped transaction, so the attacked node could miss it. For my proposal to work it should be changed to guarantee that any transaction is spread to all the nodes eventually, i.e. no skipping. This means broadcasting all transactions eventually. But this is impossible to implement without creating DoS vectors either in bandwidth or in memory (the later - in case transactions to be broadcasted are accumulated in a buffer by a node). -- Best regards, Boris Nagaev -- 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/CAFC_Vt5kHtRj%2BypoxGKZUD1-NdSnbC9m%3DzwWnjVSTcROp7aLow%40mail.gmail.com. ^ permalink raw reply [flat|nested] 15+ messages in thread
* [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6 2024-03-18 13:21 [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6 Peter Todd 2024-03-19 12:37 ` Nagaev Boris @ 2024-03-22 23:18 ` Antoine Riard 2024-03-27 13:04 ` Peter Todd 2024-03-26 18:36 ` [bitcoindev] " David A. Harding 2 siblings, 1 reply; 15+ messages in thread From: Antoine Riard @ 2024-03-22 23:18 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 9991 bytes --] Hi Peter, > The marginal cost to an attacker who was planning on broadcasting B anyway is > fairly small, as provided that sufficiently small fee-rates are chosen for A_n, > the probability of A_n being mined is low. The attack does of course require > capital, as the attacker needs to have UTXO's of sufficient size for A_n. I think an attacker does not necessarily need to have a UTXO's of sufficient size for A_n. One could reuse feerate ascending old LN states, where the balance on latest states is in favor of your counterparty. So it might be a lower assumption on attacker ressources, you only needs to have been _allocate_ a shared-UTXO in the past. > The larger the mempool size limit, the more > effective the attack tends to be. Similarly, the attack is more effective with > a larger size difference between A and B. Finally, the attack is more effective > with a smaller minimum incremental relay fee, as more individual versions of > the transaction can be broadcast for a given fee-delta range. I think the observation on larger the mempool size, more effective the attack tends to come as a novel insight to me. Naively, in a world where the future blockspace demand is uncertain, miners have an incentive to scale up their mempool size limit. As such, holding a cache of non-mined low-feerates transactions. The type of bandwidth, denial-of-service described sounds effectively to affect more full-nodes with large mempools. Fair point, it's expected they have more bandwidth ressources available too. > Of course, this attack can be parallelized, with many non-conflicting A_n > chains at once. Depending on P2P topology, maximum bandwidth may be consumable > by broadcasting multiple _conflicting_ A's to different nodes at once², a > fairly obvious attack that I (and probably others) have already disclosed. Yes, if I remember correctly bandwidth wasting attacks by exploiting RBF propagation asymmetries were considered in 2021 when an automatic mempool rebroadcasting implementation was proposed in Bitcoin Core. And alternatively, I echoed mempool partitioning concerns during the tx-relay workshops on IRC in the same year of 2021, notably how you can use to increase pinning attacks odds of success (assuming time-sensitive nodes e.g LN have a single local mempool). Commenting on this, do we have a free-relay attack variant where an attacker with reasonable visibility on the transaction-relay network could exploit propagation asymmetries due to *_INVENTORY_BROADCAST_INTERVAL and re-inject A_n traffic in a targeted fashion ? I don't think it's worst than the parallelization you're describing, it's just another approach. > Requiring replacements to increase the fee-rate by a certain ratio would also > mitigate the attack. However doing so would break a lot of wallet software that > bumps fees by values equal or close to the minimum relay fee. I think there is still the open questions of the economic relevance of replace-by-fee if the local mempool is completely empty. Here a miner is optimizing to maximize absolute fee as a transaction replaced by a higher-feerate, lower fee is less interesting if you have less than 1 MB virtual bytes / 4 MB WU. > Ironically, the existence of this attack is an argument in favor of > replace-by-fee-rate. While RBFR introduces a degree of free-relay, the fact > that Bitcoin Core's existing rules *also* allow for free-relay in this form > makes the difference inconsequential. Back on the point where an attacker ability to provoke bandwidth DoS in considerations of the UTXO-amount available, a minimal absolute fee as a proof of owning some UTXO amount could be still maintained (or maybe after a _bounded_ number of replacement under a given block period). We studied proof-of-UTXO ownership as a p2p DoS mitigation approach in the past with Gleb: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html Best, Antoine Le lundi 18 mars 2024 à 13:24:12 UTC, Peter Todd a écrit : > RBF Rule #6 requires that a replacement transaction have a fee-rate higher > than > the fee-rate of all conflicting transactions. This rule aligns economic > incentives, as in most circumstances miners earn more money by mining a > higher > fee-rate transaction than a lower fee-rate transaction, even if the > absolute > fee paid by the replacement is more. > > While RBF Rule #6 was implemented as part of my original Full-RBF opt-in > pull-req¹, it was mistakenly left out of BIP-125, which was written later > by > Harding. Thus it's often forgotten in analysis of RBF. > > Rule #6 creates a path dependency: the order in which replacement > transactions > are received determines which transactions are ultimately accepted. This > creates an opportunity for free-relay, as follows: > > 1. Create two transactions, A and B, where A is a large, low fee-rate, high > absolute fee, transaction, and B is a small, high fee-rate, low absolute > fee > transaction. > > 2. Broadcast A and B to different nodes simultaneously. > > 3. Nodes that receive A first will not replace A with B, because B pays a > lower > fee, violating RBF Rule #3. Notes that receive B first, will not replace B > with > A, because A has a lower fee-rate, violating RBF Rule #6. > > 4. Create A_1, a transaction with the same (large) size as A, but paying a > slightly higher fee (and thus fee-rate). Nodes that received A first will > replace A with A_1, consuming bandwidth. These nodes will also broadcast > A_1 to > peers who have B, consuming their bandwidth even though they reject A_1. > > 5. Repeat until A_n has a fee-rate high enough to have a non-trivial risk > of > being mined. Or B is mined, invalidating all A_n. > > The marginal cost to an attacker who was planning on broadcasting B anyway > is > fairly small, as provided that sufficiently small fee-rates are chosen for > A_n, > the probability of A_n being mined is low. The attack does of course > require > capital, as the attacker needs to have UTXO's of sufficient size for A_n. > > The attack is most effective in cases where fee-rates have a significant > slope > to them, with the minimum relay fee being small compared to the > competitive fee > to get into the next block. The larger the mempool size limit, the more > effective the attack tends to be. Similarly, the attack is more effective > with > a larger size difference between A and B. Finally, the attack is more > effective > with a smaller minimum incremental relay fee, as more individual versions > of > the transaction can be broadcast for a given fee-delta range. > > Of course, this attack can be parallelized, with many non-conflicting A_n > chains at once. Depending on P2P topology, maximum bandwidth may be > consumable > by broadcasting multiple _conflicting_ A's to different nodes at once², a > fairly obvious attack that I (and probably others) have already disclosed. > > > # Mitigations > > Replace-by-Fee-Rate mitigates the attack, by limiting the possible range of > fee-rate delta. For example, in Libre Relay, which does > replace-by-fee-rate at > a fee-rate ratio of >= 2x, if A starts at 3sat/VB, the attacker can only > do 2 > cycles of the attack as a B >= 6sat/VB will simply replace A. > > The attack itself is arguably an economic exploit: *because* Bitcoin Core > doesn't yet implement replace-by-fee-rate, nodes who accepted A first, are > wasting their bandwidth relaying variations on A that are clearly less > desirable to miners than B. An economically rational miner would just mine > B > right now, and the fact that _other_ economically rational miners would > mine B > just strengthens the case for mining B now. Indeed, real-world > measurements of > replace-by-fee-rate have found that (most likely) due to mempool > inconsistencies, roughly half or more³ of RBFR replacements are mined > already. > > Requiring replacements to increase the fee-rate by a certain ratio would > also > mitigate the attack. However doing so would break a lot of wallet software > that > bumps fees by values equal or close to the minimum relay fee. > > > # Related Attacks > > Rule #6 is just one of many ways to achieve the same effect: getting a > miner to > invalidate a set of large transactions, wasting bandwidth. For example, > miners > who accept payment for guaranteeing that a specific transaction gets mined > also > make this kind of attack possible. > > > # Discussion > > Ironically, the existence of this attack is an argument in favor of > replace-by-fee-rate. While RBFR introduces a degree of free-relay, the fact > that Bitcoin Core's existing rules *also* allow for free-relay in this form > makes the difference inconsequential. > > > # Disclosure > > This issue was disclosed to bitcoin-security first. I received no > objections to > making it public. All free-relay attacks are mitigated by the requirement > to at > least have sufficient funds available to allocate to fees, even if the > funds > might not actually be spent. > > > # References > > 1) https://github.com/bitcoin/bitcoin/pull/6871 > 2) https://petertodd.org/2024/one-shot-replace-by-fee-rate#the-status-quo > 3) https://petertodd.org/2024/replace-by-fee-rate-success-rate > > -- > 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/0a377ddb-b001-41ba-9208-27b3fa059bb5n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 12617 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6 2024-03-22 23:18 ` [bitcoindev] " Antoine Riard @ 2024-03-27 13:04 ` Peter Todd 2024-03-27 19:17 ` Antoine Riard 0 siblings, 1 reply; 15+ messages in thread From: Peter Todd @ 2024-03-27 13:04 UTC (permalink / raw) To: Antoine Riard; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 4652 bytes --] On Fri, Mar 22, 2024 at 04:18:18PM -0700, Antoine Riard wrote: > Hi Peter, > > > The marginal cost to an attacker who was planning on broadcasting B > anyway is > > fairly small, as provided that sufficiently small fee-rates are chosen > for A_n, > > the probability of A_n being mined is low. The attack does of course > require > > capital, as the attacker needs to have UTXO's of sufficient size for A_n. > > I think an attacker does not necessarily need to have a UTXO's of > sufficient size for A_n. > One could reuse feerate ascending old LN states, where the balance on > latest states is > in favor of your counterparty. So it might be a lower assumption on > attacker ressources, > you only needs to have been _allocate_ a shared-UTXO in the past. Can you explain in more detail how exactly you'd pull that off? Are you aware of LN implementations that actually create feerate ascending LN states? > > The larger the mempool size limit, the more > > effective the attack tends to be. Similarly, the attack is more effective > with > > a larger size difference between A and B. Finally, the attack is more > effective > > with a smaller minimum incremental relay fee, as more individual versions > of > > the transaction can be broadcast for a given fee-delta range. > > I think the observation on larger the mempool size, more effective the > attack tends > to come as a novel insight to me. Naively, in a world where the future > blockspace > demand is uncertain, miners have an incentive to scale up their mempool > size limit. > As such, holding a cache of non-mined low-feerates transactions. The type > of bandwidth, > denial-of-service described sounds effectively to affect more full-nodes > with large > mempools. Fair point, it's expected they have more bandwidth ressources > available too. Imagine if the mempool size was 1TB, an amount larger than the entire BTC blocksize to date. I think that example helps make it obvious that with such an enormous mempool, there *must* be free relay attacks, because it's simply impossible for all broadcast transactions to even get mined. > Commenting on this, do we have a free-relay attack variant where an > attacker with reasonable > visibility on the transaction-relay network could exploit propagation > asymmetries due to > *_INVENTORY_BROADCAST_INTERVAL and re-inject A_n traffic in a targeted > fashion ? > I don't think it's worst than the parallelization you're describing, it's > just another approach. Well, whether or not that is an attack depends on how exactly the transcation could be rebroadcast. > > Requiring replacements to increase the fee-rate by a certain ratio would > also > > mitigate the attack. However doing so would break a lot of wallet > software that > > bumps fees by values equal or close to the minimum relay fee. > > I think there is still the open questions of the economic relevance of > replace-by-fee if > the local mempool is completely empty. Here a miner is optimizing to > maximize absolute > fee as a transaction replaced by a higher-feerate, lower fee is less > interesting if you have > less than 1 MB virtual bytes / 4 MB WU. Obviously. That's why I proposed one-shot replace-by-fee-rate. Not pure replace-by-fee-rate. > > Ironically, the existence of this attack is an argument in favor of > > replace-by-fee-rate. While RBFR introduces a degree of free-relay, the > fact > > that Bitcoin Core's existing rules *also* allow for free-relay in this > form > > makes the difference inconsequential. > > Back on the point where an attacker ability to provoke bandwidth DoS in > considerations > of the UTXO-amount available, a minimal absolute fee as a proof of owning > some UTXO > amount could be still maintained (or maybe after a _bounded_ number of > replacement under > a given block period). > > We studied proof-of-UTXO ownership as a p2p DoS mitigation approach in the > past with Gleb: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html All the existing replacement mechanisms _are_ basically a proof-of-UTXO ownership, because they're transactions spending UTXOs. The only question is the details of how that proof works. -- 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/ZgQZUOCc/dSjKMoL%40petertodd.org. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6 2024-03-27 13:04 ` Peter Todd @ 2024-03-27 19:17 ` Antoine Riard 2024-03-28 14:27 ` Peter Todd 0 siblings, 1 reply; 15+ messages in thread From: Antoine Riard @ 2024-03-27 19:17 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 7869 bytes --] Hi Peter, Answering the latest 2 emails. > Since this attack is just a relatively minor extension of existing, publicly > disclosed, attacks, I don't think there was any need for formal disclosure > timelines. It's interesting that the attack exists; it does not substantially > change the status quo. Of course, it's always a matter of appreciation when an attack should get a formal disclosure process and when it can be publicized with minimal process effort. Given this class of attacks was already known from some experts, I don't think it requires a formal process either. Attaching a timeline to a disclosure email doesn't hurt. > I don't believe the other attacks in this attack class are even possible to fix. We just have to live with the fact that a degree of free relay is always going to be possible. See comments under proof-of-UTXO ownership as plausible mitigations. In anway, I think this is not the type of fixes we can land in a covert fashion given the order of magnitude of engineering effort and potential tx-relay network impact. > Can you explain in more detail how exactly you'd pull that off? Are you aware of LN implementations that actually create feerate ascending LN states? I think you can create feerates ascending LN states with today's LN implementations by playing with BOLT2's `dust_limit_satoshis`. State 1 has 1 dust HTLC trimmed, state 2 has 2 dust HTLCs trimmed, ... State N has N dust HTLCs trimmed. > Imagine if the mempool size was 1TB, an amount larger than the entire BTC > blocksize to date. I think that example helps make it obvious that with such an > enormous mempool, there *must* be free relay attacks, because it's simply > impossible for all broadcast transactions to even get mined. I think there is an interesting distinction that can be made between mempool size ressources dedicated to increase block template efficiency and minimum mempool size to just ensure you have good BIP152 compact block validation time. Obviously if you're aiming for the first, you're incentivized to offer "free-relay" bandwidth to your peers and increase your view of the ongoing transaction traffic. > All the existing replacement mechanisms _are_ basically a proof-of-UTXO > ownership, because they're transactions spending UTXOs. The only question is > the details of how that proof works. Yeah somehow it's correct that any replacement mechanisms encompass a proof-of-UTXO ownership mechanism. Yet in a world you can partition mempool like you show with your for example, it's easy to make this proof-of-UTXO economically unpaid by the attacker. Asking aged UTXOs attached to a replacement candidate could be make such proof more robust, in my understanding. Best, Antoine Le mer. 27 mars 2024 à 13:04, Peter Todd <pete@petertodd•org> a écrit : > On Fri, Mar 22, 2024 at 04:18:18PM -0700, Antoine Riard wrote: > > Hi Peter, > > > > > The marginal cost to an attacker who was planning on broadcasting B > > anyway is > > > fairly small, as provided that sufficiently small fee-rates are chosen > > for A_n, > > > the probability of A_n being mined is low. The attack does of course > > require > > > capital, as the attacker needs to have UTXO's of sufficient size for > A_n. > > > > I think an attacker does not necessarily need to have a UTXO's of > > sufficient size for A_n. > > One could reuse feerate ascending old LN states, where the balance on > > latest states is > > in favor of your counterparty. So it might be a lower assumption on > > attacker ressources, > > you only needs to have been _allocate_ a shared-UTXO in the past. > > Can you explain in more detail how exactly you'd pull that off? Are you > aware > of LN implementations that actually create feerate ascending LN states? > > > > The larger the mempool size limit, the more > > > effective the attack tends to be. Similarly, the attack is more > effective > > with > > > a larger size difference between A and B. Finally, the attack is more > > effective > > > with a smaller minimum incremental relay fee, as more individual > versions > > of > > > the transaction can be broadcast for a given fee-delta range. > > > > I think the observation on larger the mempool size, more effective the > > attack tends > > to come as a novel insight to me. Naively, in a world where the future > > blockspace > > demand is uncertain, miners have an incentive to scale up their mempool > > size limit. > > As such, holding a cache of non-mined low-feerates transactions. The > type > > of bandwidth, > > denial-of-service described sounds effectively to affect more full-nodes > > with large > > mempools. Fair point, it's expected they have more bandwidth ressources > > available too. > > Imagine if the mempool size was 1TB, an amount larger than the entire BTC > blocksize to date. I think that example helps make it obvious that with > such an > enormous mempool, there *must* be free relay attacks, because it's simply > impossible for all broadcast transactions to even get mined. > > > Commenting on this, do we have a free-relay attack variant where an > > attacker with reasonable > > visibility on the transaction-relay network could exploit propagation > > asymmetries due to > > *_INVENTORY_BROADCAST_INTERVAL and re-inject A_n traffic in a targeted > > fashion ? > > I don't think it's worst than the parallelization you're describing, > it's > > just another approach. > > Well, whether or not that is an attack depends on how exactly the > transcation > could be rebroadcast. > > > > Requiring replacements to increase the fee-rate by a certain ratio > would > > also > > > mitigate the attack. However doing so would break a lot of wallet > > software that > > > bumps fees by values equal or close to the minimum relay fee. > > > > I think there is still the open questions of the economic relevance of > > replace-by-fee if > > the local mempool is completely empty. Here a miner is optimizing to > > maximize absolute > > fee as a transaction replaced by a higher-feerate, lower fee is less > > interesting if you have > > less than 1 MB virtual bytes / 4 MB WU. > > Obviously. That's why I proposed one-shot replace-by-fee-rate. Not pure > replace-by-fee-rate. > > > > Ironically, the existence of this attack is an argument in favor of > > > replace-by-fee-rate. While RBFR introduces a degree of free-relay, the > > fact > > > that Bitcoin Core's existing rules *also* allow for free-relay in this > > form > > > makes the difference inconsequential. > > > > Back on the point where an attacker ability to provoke bandwidth DoS in > > considerations > > of the UTXO-amount available, a minimal absolute fee as a proof of > owning > > some UTXO > > amount could be still maintained (or maybe after a _bounded_ number of > > replacement under > > a given block period). > > > > We studied proof-of-UTXO ownership as a p2p DoS mitigation approach in > the > > past with Gleb: > > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-November/002884.html > > All the existing replacement mechanisms _are_ basically a proof-of-UTXO > ownership, because they're transactions spending UTXOs. The only question > is > the details of how that proof works. > > -- > 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%2BGOCiwYdK4vfkODrT0Sx6HxCAuvhVqa1c5o3Xjy03OiAQ%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 9825 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6 2024-03-27 19:17 ` Antoine Riard @ 2024-03-28 14:27 ` Peter Todd 2024-03-28 15:20 ` Peter Todd 2024-03-28 19:13 ` Antoine Riard 0 siblings, 2 replies; 15+ messages in thread From: Peter Todd @ 2024-03-28 14:27 UTC (permalink / raw) To: Antoine Riard; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 4567 bytes --] On Wed, Mar 27, 2024 at 07:17:24PM +0000, Antoine Riard wrote: > > I don't believe the other attacks in this attack class are even possible > to > fix. We just have to live with the fact that a degree of free relay is > always > going to be possible. > > See comments under proof-of-UTXO ownership as plausible mitigations. > > In anway, I think this is not the type of fixes we can land in a covert > fashion given the > order of magnitude of engineering effort and potential tx-relay network > impact. Indeed, at this point I strongly suspect had I instead lobbied for a fix privately, given that one obvious mitigation is replace-by-fee-rate, I'd instead just get accused of nefarious behavior for not doing so openly. > > Can you explain in more detail how exactly you'd pull that off? Are you > aware > of LN implementations that actually create feerate ascending LN states? > > I think you can create feerates ascending LN states with today's LN > implementations by playing with BOLT2's `dust_limit_satoshis`. > State 1 has 1 dust HTLC trimmed, state 2 has 2 dust HTLCs trimmed, ... > State N has N dust HTLCs trimmed. Correct me if I'm wrong. But I don't believe that the `dust_limit_satoshis` value can be changed on an existing channel. It *should* be possible to change on an existing channel, as the economic dust limit is fee-rate dependent. But the protocol does not support that yet IIUC. > > Imagine if the mempool size was 1TB, an amount larger than the entire BTC > > blocksize to date. I think that example helps make it obvious that with > such an > > enormous mempool, there *must* be free relay attacks, because it's simply > > impossible for all broadcast transactions to even get mined. > > I think there is an interesting distinction that can be made between > mempool size > ressources dedicated to increase block template efficiency and minimum > mempool size > to just ensure you have good BIP152 compact block validation time. > Obviously if you're > aiming for the first, you're incentivized to offer "free-relay" bandwidth > to your peers and > increase your view of the ongoing transaction traffic. There's also a convenience aspect to this: large mempools are convenient for transaction senders, as it allows them to go off line after sending transactions that aren't going to be mined in the near future. If we had a world of purely always-online transaction senders, mempools could be smaller. > > All the existing replacement mechanisms _are_ basically a proof-of-UTXO > > ownership, because they're transactions spending UTXOs. The only question > is > > the details of how that proof works. > > Yeah somehow it's correct that any replacement mechanisms encompass a > proof-of-UTXO > ownership mechanism. Yet in a world you can partition mempool like you show > with your > for example, it's easy to make this proof-of-UTXO economically unpaid by > the attacker. Asking > aged UTXOs attached to a replacement candidate could be make such proof > more robust, in > my understanding. I think you're missing a third aspect to this: # of peers. Modulo economic irrationalities with differently sized txs like the Rule #6 attack, the proof-of-UTXO is almost economically paid even when mempools are partitioned because the bandwidth used by a given form of a transaction is limited to the % of peers that relay it. Eg if I broadcast TxA to 50% of nodes, and TxB to the other 50%, both spending the same txout, the total cost/KB used in total would exactly the same... except that nodes have more than one peer. This acts as an amplification fator to attacks depending on the exact topology as bandwidth is wasted in proportion to the # of peers txs need to be broadcast too. Basically, a fan-out factor. If the # of peers is reduced, the impact of this type of attack is also reduced. Of course, a balance has to be maintained. I call the Rule #6 attack an economic irrationality because the higher fee-rate transaction should have replaced the low fee-rate transactions: it's the one that got mined, so bandwidth spend on the low fee-rate txs was clearly wasted, and miners lost out on some fees. -- 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/ZgV%2BRk0m4azlbRZP%40petertodd.org. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6 2024-03-28 14:27 ` Peter Todd @ 2024-03-28 15:20 ` Peter Todd 2024-03-28 19:13 ` Antoine Riard 1 sibling, 0 replies; 15+ messages in thread From: Peter Todd @ 2024-03-28 15:20 UTC (permalink / raw) To: Antoine Riard; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 1706 bytes --] On Thu, Mar 28, 2024 at 02:27:18PM +0000, Peter Todd wrote: > > > Can you explain in more detail how exactly you'd pull that off? Are you > > aware > > of LN implementations that actually create feerate ascending LN states? > > > > I think you can create feerates ascending LN states with today's LN > > implementations by playing with BOLT2's `dust_limit_satoshis`. > > State 1 has 1 dust HTLC trimmed, state 2 has 2 dust HTLCs trimmed, ... > > State N has N dust HTLCs trimmed. > > Correct me if I'm wrong. But I don't believe that the `dust_limit_satoshis` > value can be changed on an existing channel. > > It *should* be possible to change on an existing channel, as the economic dust > limit is fee-rate dependent. But the protocol does not support that yet IIUC. Oh, and to expand on this discussion a bit... Assuming that LN implementations did enable this type of attack, I'll point out that it's essentially based on having incoming liquidity, which is not free. Either you paid for it by paying someone to open channels to you. Or you operated a lightning node that provided sufficiently attractive survice that people chose to open channels to you. Either way getting that incoming capacity cost you money, probably at similar if not worse rates than just borrowing BTC. -- 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/ZgWKqIftBCHBppQV%40petertodd.org. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6 2024-03-28 14:27 ` Peter Todd 2024-03-28 15:20 ` Peter Todd @ 2024-03-28 19:13 ` Antoine Riard 2024-03-28 19:47 ` Peter Todd 1 sibling, 1 reply; 15+ messages in thread From: Antoine Riard @ 2024-03-28 19:13 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 9582 bytes --] Hi Peter, Answering the latest 2 emails. > Indeed, at this point I strongly suspect had I instead lobbied for a fix > privately, given that one obvious mitigation is replace-by-fee-rate, I'd > instead just get accused of nefarious behavior for not doing so openly. I'll confirm publicly again that transaction-relay bandwidth DoS risks have been known or suspected by some senior developers for a while, including sometimes mentioned half-way on the Bitcoin Core GH repository years ago. > Correct me if I'm wrong. But I don't believe that the `dust_limit_satoshis` > value can be changed on an existing channel. > It *should* be possible to change on an existing channel, as the economic dust > limit is fee-rate dependent. But the protocol does not support that yet IIUC. This is correct, it cannot be changed once it has been negotiated at opening flow. Per-BOLT3 "Commitment Transaction Construction", the dust HTLCs are trimmed and the amount added to the commitment transaction absolute fee. This ability can let you generate an ascending feerate range of commitment transactions: - state_1, size 1000 kb, 1 trimmed HTLC ~500 sats absolute fee - state_2, size 900 kb, 2 trimmed HTLC ~1000 sats absolute fee - state_3, size 800 kb, 3 trimmed HTLC ~1500 sats absolute fee - etc Non-dust HTLC fully materializing on the commitment transaction can be added at wish to adjust commitment transaction size if you're using a public channel used for routing, without the "honest interactivity" of your counterparty. > There's also a convenience aspect to this: large mempools are convenient for > transaction senders, as it allows them to go off line after sending > transactions that aren't going to be mined in the near future. If we had a > world of purely always-online transaction senders, mempools could be smaller. Yes. This is a good question if a world of common size mempool for hobbyist full-nodes can still be the network standard in the evolving world of today where re-broadcasting and pricing the next few blocks become more done by transaction issuers, evicting transactions without high odds to be mined in the near future. Said differently, Bitcoin clients with high-timevalue preferences for their use-cases are out-pricing Bitcoin clients with low-timevalue preferences from network mempools. > Modulo economic irrationalities with differently sized txs like the Rule #6 > attack, the proof-of-UTXO is almost economically paid even when mempools are > partitioned because the bandwidth used by a given form of a transaction is > limited to the % of peers that relay it. Eg if I broadcast TxA to 50% of nodes, > and TxB to the other 50%, both spending the same txout, the total cost/KB used > in total would exactly the same... except that nodes have more than one peer. > This acts as an amplification fator to attacks depending on the exact topology > as bandwidth is wasted in proportion to the # of peers txs need to be broadcast > too. Basically, a fan-out factor. > If the # of peers is reduced, the impact of this type of attack is also > reduced. Of course, a balance has to be maintained. Sure, proof-of-UTXO is imperfectly economically charged, however I think you can re-use the same proof-of-UTXO for each subset of Sybilled transaction-relay peers. And for sure, # peers and network topology can be leveraged as amplification factors for this class of "free-relay" attacks. Balance would have to be find compared to worthiness of carried-on transaction-relay traffic. > Oh, and to expand on this discussion a bit... Assuming that LN implementations > did enable this type of attack, I'll point out that it's essentially based on > having incoming liquidity, which is not free. Either you paid for it by paying > someone to open channels to you. Or you operated a lightning node that provided > sufficiently attractive survice that people chose to open channels to you. > Either way getting that incoming capacity cost you money, probably at similar > if not worse rates than just borrowing BTC. Yes, note I used the term "allocated" in one of my previous emails, which I concede is not well-defined and it's indeed dependent on Lightning channel network dynamics. I'll leave as an exercise to the reader to find common liquidity management asymmetries in today's LN implementation to be leveraged as a discount vector for "free-relay" bandwidth attacks at the transaction-relay network-level. Best, Antoine Le jeu. 28 mars 2024 à 14:27, Peter Todd <pete@petertodd•org> a écrit : > On Wed, Mar 27, 2024 at 07:17:24PM +0000, Antoine Riard wrote: > > > I don't believe the other attacks in this attack class are even > possible > > to > > fix. We just have to live with the fact that a degree of free relay is > > always > > going to be possible. > > > > See comments under proof-of-UTXO ownership as plausible mitigations. > > > > In anway, I think this is not the type of fixes we can land in a covert > > fashion given the > > order of magnitude of engineering effort and potential tx-relay network > > impact. > > Indeed, at this point I strongly suspect had I instead lobbied for a fix > privately, given that one obvious mitigation is replace-by-fee-rate, I'd > instead just get accused of nefarious behavior for not doing so openly. > > > > Can you explain in more detail how exactly you'd pull that off? Are you > > aware > > of LN implementations that actually create feerate ascending LN states? > > > > I think you can create feerates ascending LN states with today's LN > > implementations by playing with BOLT2's `dust_limit_satoshis`. > > State 1 has 1 dust HTLC trimmed, state 2 has 2 dust HTLCs trimmed, ... > > State N has N dust HTLCs trimmed. > > Correct me if I'm wrong. But I don't believe that the `dust_limit_satoshis` > value can be changed on an existing channel. > > It *should* be possible to change on an existing channel, as the economic > dust > limit is fee-rate dependent. But the protocol does not support that yet > IIUC. > > > > Imagine if the mempool size was 1TB, an amount larger than the entire > BTC > > > blocksize to date. I think that example helps make it obvious that with > > such an > > > enormous mempool, there *must* be free relay attacks, because it's > simply > > > impossible for all broadcast transactions to even get mined. > > > > I think there is an interesting distinction that can be made between > > mempool size > > ressources dedicated to increase block template efficiency and minimum > > mempool size > > to just ensure you have good BIP152 compact block validation time. > > Obviously if you're > > aiming for the first, you're incentivized to offer "free-relay" bandwidth > > to your peers and > > increase your view of the ongoing transaction traffic. > > There's also a convenience aspect to this: large mempools are convenient > for > transaction senders, as it allows them to go off line after sending > transactions that aren't going to be mined in the near future. If we had a > world of purely always-online transaction senders, mempools could be > smaller. > > > > All the existing replacement mechanisms _are_ basically a proof-of-UTXO > > > ownership, because they're transactions spending UTXOs. The only > question > > is > > > the details of how that proof works. > > > > Yeah somehow it's correct that any replacement mechanisms encompass a > > proof-of-UTXO > > ownership mechanism. Yet in a world you can partition mempool like you > show > > with your > > for example, it's easy to make this proof-of-UTXO economically unpaid by > > the attacker. Asking > > aged UTXOs attached to a replacement candidate could be make such proof > > more robust, in > > my understanding. > > I think you're missing a third aspect to this: # of peers. > > Modulo economic irrationalities with differently sized txs like the Rule #6 > attack, the proof-of-UTXO is almost economically paid even when mempools > are > partitioned because the bandwidth used by a given form of a transaction is > limited to the % of peers that relay it. Eg if I broadcast TxA to 50% of > nodes, > and TxB to the other 50%, both spending the same txout, the total cost/KB > used > in total would exactly the same... except that nodes have more than one > peer. > This acts as an amplification fator to attacks depending on the exact > topology > as bandwidth is wasted in proportion to the # of peers txs need to be > broadcast > too. Basically, a fan-out factor. > > If the # of peers is reduced, the impact of this type of attack is also > reduced. Of course, a balance has to be maintained. > > I call the Rule #6 attack an economic irrationality because the higher > fee-rate > transaction should have replaced the low fee-rate transactions: it's the > one > that got mined, so bandwidth spend on the low fee-rate txs was clearly > wasted, > and miners lost out on some fees. > > -- > 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%2BH2B1pSbqNa9phxZMxHX%2B30AiDqX7TgiRjH4rtirLwb9g%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 11550 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6 2024-03-28 19:13 ` Antoine Riard @ 2024-03-28 19:47 ` Peter Todd 2024-03-29 20:48 ` Antoine Riard 0 siblings, 1 reply; 15+ messages in thread From: Peter Todd @ 2024-03-28 19:47 UTC (permalink / raw) To: Antoine Riard; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 2254 bytes --] On Thu, Mar 28, 2024 at 07:13:38PM +0000, Antoine Riard wrote: > > Modulo economic irrationalities with differently sized txs like the Rule > #6 > > attack, the proof-of-UTXO is almost economically paid even when mempools > are > > partitioned because the bandwidth used by a given form of a transaction is > > limited to the % of peers that relay it. Eg if I broadcast TxA to 50% of > nodes, > > and TxB to the other 50%, both spending the same txout, the total cost/KB > used > > in total would exactly the same... except that nodes have more than one > peer. > > This acts as an amplification fator to attacks depending on the exact > topology > > as bandwidth is wasted in proportion to the # of peers txs need to be > broadcast > > too. Basically, a fan-out factor. > > > If the # of peers is reduced, the impact of this type of attack is also > > reduced. Of course, a balance has to be maintained. > > Sure, proof-of-UTXO is imperfectly economically charged, however I think > you can > re-use the same proof-of-UTXO for each subset of Sybilled transaction-relay > peers. Of course you can. That's the whole point of my scenario above: you can re-use the proof-of-UTXO. But since nodes' mempools enforce anti-doublespending, the tradeoff is less total nodes seeing each individual conflicting uses. If, for example, all Bitcoin nodes were somehow peered in a perfect ring, with each node having exactly two peers, the sum total bandwidth of using 2 conflicting proof-of-UTXOs (aka spending the UTXO), would be almost identical to the sum total bandwidth of just using 1. The only additional bandwidth would be the three to four nodes at the "edges" of the ring who saw the two different conflicting versions. With higher #'s of peers, the total maximum extra bandwidth used broadcasting conflicts increases proportionally. -- 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/ZgXJOxBsePn9VAKh%40petertodd.org. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoindev] Re: A Free-Relay Attack Exploiting RBF Rule #6 2024-03-28 19:47 ` Peter Todd @ 2024-03-29 20:48 ` Antoine Riard 0 siblings, 0 replies; 15+ messages in thread From: Antoine Riard @ 2024-03-29 20:48 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 7637 bytes --] Hi Peter, Answering your latest 2 emails. > I do not consider CVE-2017-12842 to be serious. Indeed, I'm skeptical that we > should even fix it with a fork. SPV validation is very sketchy, and the amount > of work and money required to trigger CVE-2017-12842 is probably as or more > expensive than simply creating fake blocks. > Sergio's RSK Bridge contract being vulnerable to it just indicates it was a > reckless design. I don't think we shall disregard SPV validation yet in a world where we have not really solved the scaling of Bitcoin payments for large range of user segments running on low-cost android mobile with limited validation ressources. On the cost of the attack, yes I think it's probably in the order of creating fake blocks at current difficulty adjustment. On appreciating if a design is reckless or not, it's always good to do it with a full- fledged cost-based threat model in a comparative analysis w.r.t other alternative design in my experience. > To be clear, in this particular case I had specific, insider, knowledge that > the relevant people had in fact seen my report and had already decided to > dismiss it. This isn't a typical case where you're emailing some random company > and don't have any contacts. I personally knew prior to publication that the > relevant people had been given a fair chance to comment, had chosen not to, and > I would likely receive no response at all. Sure thing, it's not a disclosure configuration where the reporter has no out-of-band redundant communication channels available with the software group of maintainers. I can only suggest that Bitcoin Core's `SECURITY.md` to be modified in the sense to give an acknowledgement of reception to finding reports with technical proofs under ~72 hours. I'll let external observers from the community make their own appreciation on what this disclosure episode can say on the state of Bitcoin security problem handling. > I'm not going to say anything further on how I knew this, because I'm not about > to put up people who have been co-operating with me to the risk of harassment > from people like Harding and others; I'm not very popular right now with many > of the Bitcoin Core people working on the mempool code. I think it's up to the maintainers or vendors of any piece of software to justify why they're disregarding sound technical reports coming from a security researcher with a credible and proven track record, especially when it's apparently for hidden social reasons. There is also the option to disclose under pseudonym which I personally already done sometimes in the past. I can understand ones does not wish to do so far for professional reputation reasons. > Anyway, I think the lesson learned here is it's probably not worth bothering > with a disclosure process at all for this type of issue. It just created a > bunch of distracting political drama when simply publishing this exploit > variation immediately probably would not have. I've checked my own archive, on the Lightning-side and from my memory, I can remember two far more serious issues than free-relay attacks which were quickly disclosed without a formal process over the past years: - time-dilation attacks by myself [0] - RBF-pinning on second-stage HTLC by the TheBlueMatt [1] Both were conducted on a less than 7-days timeframe between private report to select developers parties and public full-disclosure. With more experience on handling security issues since TDA initial report in 2019, I still think it's good to give 2-weeks to any vendors if they wish to engage in a mitigation process (unless special or emergency considerations). In matters of ethical infosec and responsible disclosure, the process and timeframe actually followed should matter far more than the "who" of the reporter, and her / his "popularity" score on the social graph be completely disregarded - imho. > If, for example, all Bitcoin nodes were somehow peered in a perfect ring, with > each node having exactly two peers, the sum total bandwidth of using 2 > conflicting proof-of-UTXOs (aka spending the UTXO), would be almost identical > to the sum total bandwidth of just using 1. The only additional bandwidth would > be the three to four nodes at the "edges" of the ring who saw the two different > conflicting versions. > With higher #'s of peers, the total maximum extra bandwidth used broadcasting > conflicts increases proportionally. Yes, higher #'s of peers, higher the total maximum extra outgoing bandwidth used for broadcasting conflicts increase proportionally. I think you can dissociate among transaction-announcement bandwidth (e.g INV(wtxid)) and transaction-fetching bandwidth (e.g GETDATA(wtxid)), you can re-fine the adversarial scenario to have highest DoS impact for each unique proof-of-UTXO. Like what is bandwidth-cost carried on by announcer and bandwidth-cost encumbered by the receiver. Best, Antoine Le jeudi 28 mars 2024 à 20:19:19 UTC, Peter Todd a écrit : > On Thu, Mar 28, 2024 at 07:13:38PM +0000, Antoine Riard wrote: > > > Modulo economic irrationalities with differently sized txs like the > Rule > > #6 > > > attack, the proof-of-UTXO is almost economically paid even when > mempools > > are > > > partitioned because the bandwidth used by a given form of a > transaction is > > > limited to the % of peers that relay it. Eg if I broadcast TxA to 50% > of > > nodes, > > > and TxB to the other 50%, both spending the same txout, the total > cost/KB > > used > > > in total would exactly the same... except that nodes have more than one > > peer. > > > This acts as an amplification fator to attacks depending on the exact > > topology > > > as bandwidth is wasted in proportion to the # of peers txs need to be > > broadcast > > > too. Basically, a fan-out factor. > > > > > If the # of peers is reduced, the impact of this type of attack is also > > > reduced. Of course, a balance has to be maintained. > > > > Sure, proof-of-UTXO is imperfectly economically charged, however I think > > you can > > re-use the same proof-of-UTXO for each subset of Sybilled > transaction-relay > > peers. > > Of course you can. That's the whole point of my scenario above: you can > re-use > the proof-of-UTXO. But since nodes' mempools enforce anti-doublespending, > the > tradeoff is less total nodes seeing each individual conflicting uses. > > If, for example, all Bitcoin nodes were somehow peered in a perfect ring, > with > each node having exactly two peers, the sum total bandwidth of using 2 > conflicting proof-of-UTXOs (aka spending the UTXO), would be almost > identical > to the sum total bandwidth of just using 1. The only additional bandwidth > would > be the three to four nodes at the "edges" of the ring who saw the two > different > conflicting versions. > > With higher #'s of peers, the total maximum extra bandwidth used > broadcasting > conflicts increases proportionally. > > -- > 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/f1868012-8ad2-44ba-b83c-b53d5892b8e6n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 9548 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6 2024-03-18 13:21 [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6 Peter Todd 2024-03-19 12:37 ` Nagaev Boris 2024-03-22 23:18 ` [bitcoindev] " Antoine Riard @ 2024-03-26 18:36 ` David A. Harding 2024-03-27 6:27 ` Antoine Riard 2 siblings, 1 reply; 15+ messages in thread From: David A. Harding @ 2024-03-26 18:36 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoindev On 2024-03-18 03:21, Peter Todd wrote: > [...] the existence of this attack is an argument in favor of > replace-by-fee-rate. While RBFR introduces a degree of free-relay, the > fact > that Bitcoin Core's existing rules *also* allow for free-relay in this > form > makes the difference inconsequential. > > # Disclosure > > This issue was disclosed to bitcoin-security first. I received no > objections to > making it public. All free-relay attacks are mitigated by the > requirement to at > least have sufficient funds available to allocate to fees, even if the > funds > might not actually be spent. Could you tell us more about the disclosure process you followed? I'm surprised to see it disclosed without any apparent attempt at patching. I'm especially concerned given your past history of publicly revealing vulnerabilities before they could be quietly patched[1] and the conflict of interest of you using this disclosure to advocate for a policy change you are championing. -Dave [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016100.html -- 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/012f89763cc336cd91eec13dccefc921%40dtrt.org. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6 2024-03-26 18:36 ` [bitcoindev] " David A. Harding @ 2024-03-27 6:27 ` Antoine Riard 2024-03-27 12:54 ` Peter Todd 0 siblings, 1 reply; 15+ messages in thread From: Antoine Riard @ 2024-03-27 6:27 UTC (permalink / raw) To: David A. Harding; +Cc: Peter Todd, bitcoindev [-- Attachment #1: Type: text/plain, Size: 4387 bytes --] Hi Dave, > Could you tell us more about the disclosure process you followed? I'm > surprised to see it disclosed without any apparent attempt at patching. > I'm especially concerned given your past history of publicly revealing > vulnerabilities before they could be quietly patched[1] and the conflict > of interest of you using this disclosure to advocate for a policy change > you are championing. In defense of Peter, I don't think there is a low-hanging fruit that could have been landed easily in Bitcoin Core. The most obvious ones could have been a) to reduce `MAX_STANDARD_TX_WEIGHT` or b) a new rule `max_replacement_bandwidth` or c) a new absolute-fee based penalty on bandwidth replacement cost. All hard to integrate in a covert fashion without attracting some attention from the community, which would certainly ask why we're changing the marginal bandwidth cost. Potentially, impacting unfavorably some use-cases. Certainly, Peter's report could have integrated a disclosure timeline at the example of CVE-2018-17144 [0], which I can recommend to anyone to follow doing security research or servicing as a security point of contact in our field. I don't see the conflict of interest in the present disclosure ? It is public information that Peter is championing RBFR [1]. I'm not aware of any private interest unfavorably influencing Peter's behavior in the conduct of this security issue disclosure. One of the established principles in infosec, it's up to software vendors to explain why their softwares is broken or why they are "lazy" fixing issues. Assuming sufficient technical proof has been initially communicated by the reporter. If you're dissatisfied by Peter's conduct in the handling of this disclosure, you're welcome to author vulnerability reports or assume the role of coordinating patching responses yourself more often. Assuming you can be reasonably trusted here. Finally, in matters of ethics, talking as an external observer can be cheap sometimes and it is best to "lead-by-example", imho. Best, Antoine [0] https://bitcoincore.org/en/2018/09/20/notice/ [1] https://petertodd.org/2024/one-shot-replace-by-fee-rate Le mar. 26 mars 2024 à 18:38, David A. Harding <dave@dtrt•org> a écrit : > On 2024-03-18 03:21, Peter Todd wrote: > > [...] the existence of this attack is an argument in favor of > > replace-by-fee-rate. While RBFR introduces a degree of free-relay, the > > fact > > that Bitcoin Core's existing rules *also* allow for free-relay in this > > form > > makes the difference inconsequential. > > > > # Disclosure > > > > This issue was disclosed to bitcoin-security first. I received no > > objections to > > making it public. All free-relay attacks are mitigated by the > > requirement to at > > least have sufficient funds available to allocate to fees, even if the > > funds > > might not actually be spent. > > Could you tell us more about the disclosure process you followed? I'm > surprised to see it disclosed without any apparent attempt at patching. > I'm especially concerned given your past history of publicly revealing > vulnerabilities before they could be quietly patched[1] and the conflict > of interest of you using this disclosure to advocate for a policy change > you are championing. > > -Dave > > [1] > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016100.html > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/bitcoindev/EJYoeNTPVhg/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > bitcoindev+unsubscribe@googlegroups•com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/bitcoindev/012f89763cc336cd91eec13dccefc921%40dtrt.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%2BHNiwie1RNJOi9WJs-F2%3DYSvFdwCDfdNDuTdUuSf_kTBg%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 6425 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6 2024-03-27 6:27 ` Antoine Riard @ 2024-03-27 12:54 ` Peter Todd 0 siblings, 0 replies; 15+ messages in thread From: Peter Todd @ 2024-03-27 12:54 UTC (permalink / raw) To: Antoine Riard; +Cc: David A. Harding, bitcoindev [-- Attachment #1: Type: text/plain, Size: 2798 bytes --] On Wed, Mar 27, 2024 at 06:27:47AM +0000, Antoine Riard wrote: > Hi Dave, > > > Could you tell us more about the disclosure process you followed? I'm > > surprised to see it disclosed without any apparent attempt at patching. > > I'm especially concerned given your past history of publicly revealing > > vulnerabilities before they could be quietly patched[1] and the conflict > > of interest of you using this disclosure to advocate for a policy change > > you are championing. > > In defense of Peter, I don't think there is a low-hanging fruit that could > have > been landed easily in Bitcoin Core. The most obvious ones could have been > a) to reduce `MAX_STANDARD_TX_WEIGHT` or b) a new rule > `max_replacement_bandwidth` > or c) a new absolute-fee based penalty on bandwidth replacement cost. To be clear, I _did_ disclose the issue on bitcoin-security and no-one had any objections to disclosing it publicly. > All hard to integrate in a covert fashion without attracting some attention > from the > community, which would certainly ask why we're changing the marginal > bandwidth cost. > Potentially, impacting unfavorably some use-cases. > > Certainly, Peter's report could have integrated a disclosure timeline at the > example of CVE-2018-17144 [0], which I can recommend to anyone to follow > doing > security research or servicing as a security point of contact in our field. Since this attack is just a relatively minor extension of existing, publicly disclosed, attacks, I don't think there was any need for formal disclosure timelines. It's interesting that the attack exists; it does not substantially change the status quo. I don't believe the other attacks in this attack class are even possible to fix. We just have to live with the fact that a degree of free relay is always going to be possible. > I don't see the conflict of interest in the present disclosure ? It is > public information > that Peter is championing RBFR [1]. I'm not aware of any private interest > unfavorably > influencing Peter's behavior in the conduct of this security issue > disclosure. Well, there is a conflict of interest in trying to keep this issue under wraps: Replace-By-Fee-Rate benefits from public discussion of the fact that many different free-relay attacks are possible. The arguments against RBFR mainly hinge on the idea that free-relay is preventable. -- 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/ZgQXHpraCWeEyDKe%40petertodd.org. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-03-29 21:14 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-03-18 13:21 [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6 Peter Todd 2024-03-19 12:37 ` Nagaev Boris 2024-03-19 13:46 ` Peter Todd 2024-03-23 0:29 ` Nagaev Boris 2024-03-22 23:18 ` [bitcoindev] " Antoine Riard 2024-03-27 13:04 ` Peter Todd 2024-03-27 19:17 ` Antoine Riard 2024-03-28 14:27 ` Peter Todd 2024-03-28 15:20 ` Peter Todd 2024-03-28 19:13 ` Antoine Riard 2024-03-28 19:47 ` Peter Todd 2024-03-29 20:48 ` Antoine Riard 2024-03-26 18:36 ` [bitcoindev] " David A. Harding 2024-03-27 6:27 ` Antoine Riard 2024-03-27 12:54 ` Peter Todd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox