* [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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-28 18:34 ` Antoine Riard
@ 2024-03-28 19:16 ` Peter Todd
0 siblings, 0 replies; 22+ messages in thread
From: Peter Todd @ 2024-03-28 19:16 UTC (permalink / raw)
To: Antoine Riard; +Cc: Steve Lee, David A. Harding, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 3215 bytes --]
On Thu, Mar 28, 2024 at 06:34:42PM +0000, Antoine Riard wrote:
> Hi Steve,
>
> > He literally cites a reference to an example.
>
> About CVE-2017-12842, the report of Sergio Demian Lerner available here
> gives more information on the reporting process of the vulnerability:
> https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/
>
> I'll attract attention on the following words of Sergio himself:
>
> "and as I said in the first paragraph, the weakness was already known by
> some developers. But I still don't understand (1) why so many people knew
> about it but underestimated it badly, (2) why there was no attempt to fix
> it."
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 believe in the present "free-relay" bandwidth wasting, letting a minimal
> 2-weeks delay would have been more reasonable. Security list members might
> be in flight travels or at conferences, or under other operational
> constraints and domain experts in the area of transaction-relay might not
> be available to give full-fledged answers. Even if you have private
> contacts of someone, don't rush them to get an answer when it can be
> midnight in their time zones and they're recovering from jet lags.
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. Which is really annoying as I have
my own deadlines for (paid) things this research was relevant to: much more
useful to me to get the issue published publicly, so I can get actual comments
from people like yourself, and move forward with my work.
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.
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.
--
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/ZgXCBhL2E6UECXVJ%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-27 22:05 ` Steve Lee
@ 2024-03-28 18:34 ` Antoine Riard
2024-03-28 19:16 ` Peter Todd
0 siblings, 1 reply; 22+ messages in thread
From: Antoine Riard @ 2024-03-28 18:34 UTC (permalink / raw)
To: Steve Lee; +Cc: Peter Todd, David A. Harding, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 5336 bytes --]
Hi Steve,
> He literally cites a reference to an example.
About CVE-2017-12842, the report of Sergio Demian Lerner available here
gives more information on the reporting process of the vulnerability:
https://bitslog.com/2018/06/09/leaf-node-weakness-in-bitcoin-merkle-tree-design/
I'll attract attention on the following words of Sergio himself:
"and as I said in the first paragraph, the weakness was already known by
some developers. But I still don't understand (1) why so many people knew
about it but underestimated it badly, (2) why there was no attempt to fix
it."
Sadly, from my experience reporting weaknesses or reviewing security
patches in Bitcoin Core, senior developers in this field are still aware of
more vulnerabilities than they usually have time to fix them. Additionally,
sometimes "ambiguous" patches are deliberately done where a lightweight
weakness is fixed and argued in public as such, when in reality more severe
issues are hardened under the hood.
In the present case making non-standard 64 bytes transactions without
witness in Bitcoin Core 16.0 added a belt-and-suspender in face of
block-malleability validation issues that could split the network _and_ it
leveled up the bar for double-spending SPV clients. That latest
exploitation scenario was the one which was early disclosed by Peter in
June 2018.
Coming back to the present "free-relay" bandwidth wasting class of attack
disclosure, I effectively myself think a 4-days delay was a bit short for a
full disclosure.
Comparing to CVE-2021-31876 (core's lack of inheritance signaling), full
disclosure report is available here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-May/018893.html
The initial report was made 2021-03-19. We didn't go the route of landing a
covert patch as it was appreciated that potential DoS risks outweighs the
safety of non-anchors exposed LN channels. Weakness report was made
available the 2021-05-06 after noticing maintainers of most-likely exposed
Bitcoin softwares, so a delay of 50-days. As a reminder, in the full
disclosure report I myself champion some changes in the BOLT protocol such
as dynamic upgrades that would make handling this kind of security issues
easier [0].
I believe in the present "free-relay" bandwidth wasting, letting a minimal
2-weeks delay would have been more reasonable. Security list members might
be in flight travels or at conferences, or under other operational
constraints and domain experts in the area of transaction-relay might not
be available to give full-fledged answers. Even if you have private
contacts of someone, don't rush them to get an answer when it can be
midnight in their time zones and they're recovering from jet lags.
On the other hand, if you don't receive a satisfying answer as a security
finding reporter after 2 weeks, or an acknowledgement of email reporting
reception after ~72 hours from vendors, I still think you're free to move
ahead with a full disclosure. Sadly, I had "bad faith" vendor cases in my
career as a security researcher in considerations of ethical infosec rules.
Best,
Antoine
[0] By the way the pinning vector exposed in CVE-2021-31876 still affects
LDK channels as the commit beef584c `negotiate_anchors_zero_fee_htlc_tx` is
false by default. And this is not fixed by v3 without avoiding all
nversion=2 by an on-chain confirmation to be replayed (L792,
src/validation.cpp - commit d1e9a02). I"ll be polite and not ask what LDK
maintainers are doing with their time.
Le mer. 27 mars 2024 à 22:14, Steve Lee <steven.j.lee@gmail•com> a écrit :
>
>
> On Wed, Mar 27, 2024 at 2:56 PM Peter Todd <pete@petertodd•org> wrote:
>
>>
>> I'm not the only person who thinks this looks like harassment. The fact
>> is you
>> started this conversation with: "I'm especially concerned given your past
>> history of publicly revealing vulnerabilities before they could be quietly
>> patched and the conflict of interest of you using this disclosure to
>> advocate
>> for a policy change you are championing."
>>
>> You haven't substantiated any of this.
>
>
> He literally cites a reference to an example.
>
> --
> 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/CABu3BAeYsMG7TuM_htTYREgDdGOKV%3DgwFJ%2BT59L%3DqHqbewz4vw%40mail.gmail.com
> <https://groups.google.com/d/msgid/bitcoindev/CABu3BAeYsMG7TuM_htTYREgDdGOKV%3DgwFJ%2BT59L%3DqHqbewz4vw%40mail.gmail.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/CALZpt%2BEK26%3DE6U9OdY%2Bc9LVQnGtb-f5zzKt5RTwBoHpr_SSxcA%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 7160 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-27 20:30 ` Peter Todd
@ 2024-03-27 22:05 ` Steve Lee
2024-03-28 18:34 ` Antoine Riard
0 siblings, 1 reply; 22+ messages in thread
From: Steve Lee @ 2024-03-27 22:05 UTC (permalink / raw)
To: Peter Todd; +Cc: David A. Harding, bitcoindev
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
On Wed, Mar 27, 2024 at 2:56 PM Peter Todd <pete@petertodd•org> wrote:
>
> I'm not the only person who thinks this looks like harassment. The fact is
> you
> started this conversation with: "I'm especially concerned given your past
> history of publicly revealing vulnerabilities before they could be quietly
> patched and the conflict of interest of you using this disclosure to
> advocate
> for a policy change you are championing."
>
> You haven't substantiated any of this.
He literally cites a reference to an example.
--
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/CABu3BAeYsMG7TuM_htTYREgDdGOKV%3DgwFJ%2BT59L%3DqHqbewz4vw%40mail.gmail.com.
[-- Attachment #2: Type: text/html, Size: 1581 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-27 19:50 ` David A. Harding
@ 2024-03-27 20:30 ` Peter Todd
2024-03-27 22:05 ` Steve Lee
0 siblings, 1 reply; 22+ messages in thread
From: Peter Todd @ 2024-03-27 20:30 UTC (permalink / raw)
To: David A. Harding; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 2493 bytes --]
On Wed, Mar 27, 2024 at 09:50:20AM -1000, David A. Harding wrote:
> On 2024-03-27 08:04, Peter Todd wrote:
> > I was able to verify independently that the relevant people had seen
> > the email and weren't planning on replying.
>
> Can you provide detail on this?
I'm not going because I don't want anyone else subject to harassment over this.
> > You're just harassing me here; I highly
> > suspect you'd have said nothing at all if I hadn't brought up
> > disclosure.
>
> I think I would have said something. Any time I'm writing a description for
> Optech about an attack that affects existing Bitcoin software and was
> responsibly disclosed, I back link to it from a special page [1]. In cases
> of ambiguity about whether or not an attack was responsibly disclosed, I
> investigate.
>
> I'm sorry this feels to you like harassment. To me it feels like whiplash:
> I inferred responsible disclosure based on your original text, learned it
> might not have been, and now am being told by you that it was indeed
> responsible.
I'm not the only person who thinks this looks like harassment. The fact is you
started this conversation with: "I'm especially concerned given your past
history of publicly revealing vulnerabilities before they could be quietly
patched and the conflict of interest of you using this disclosure to advocate
for a policy change you are championing."
You haven't substantiated any of this. Nor have you even tried to argue that my
take on the vulnerability is incorrect: it's just an interesting variation of
well-known attacks that doesn't substantially change the situation.
Anyway, this conversation is just wasting everyones' time. If this actually is
a deal-breaking exploit that must be fixed quickly and quietly - the type of
exploit for which responsible disclosure is necessary - what we should be
talking about is how to fix it. I proposed two different design changes that
mitigates it. One of which fixes other issues too. Antoine Riard also proposed
potential mitigations.
Do you have a useful comment on these proposals?
--
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/ZgSB6kmLiDG08Yrd%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-27 18:04 ` Peter Todd
@ 2024-03-27 19:50 ` David A. Harding
2024-03-27 20:30 ` Peter Todd
0 siblings, 1 reply; 22+ messages in thread
From: David A. Harding @ 2024-03-27 19:50 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoindev
On 2024-03-27 08:04, Peter Todd wrote:
> I was able to verify independently that the relevant people had seen
> the email and weren't planning on replying.
Can you provide detail on this?
> You're just harassing me here; I highly
> suspect you'd have said nothing at all if I hadn't brought up
> disclosure.
I think I would have said something. Any time I'm writing a description
for Optech about an attack that affects existing Bitcoin software and
was responsibly disclosed, I back link to it from a special page [1].
In cases of ambiguity about whether or not an attack was responsibly
disclosed, I investigate.
I'm sorry this feels to you like harassment. To me it feels like
whiplash: I inferred responsible disclosure based on your original text,
learned it might not have been, and now am being told by you that it was
indeed responsible.
-Dave
[1] https://bitcoinops.org/en/topics/responsible-disclosures/
--
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/bbc33ff01e464f8c84a593ac05c5722c%40dtrt.org.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
2024-03-27 17:18 David A. Harding
@ 2024-03-27 18:04 ` Peter Todd
2024-03-27 19:50 ` David A. Harding
0 siblings, 1 reply; 22+ messages in thread
From: Peter Todd @ 2024-03-27 18:04 UTC (permalink / raw)
To: David A. Harding; +Cc: bitcoindev
[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]
On Wed, Mar 27, 2024 at 07:18:08AM -1000, David A. Harding wrote:
> On 2024-03-27 02:10, Peter Todd wrote:
> > On Tue, Mar 26, 2024 at 08:36:45AM -1000, David A. Harding wrote:
> > > Could you tell us more about the disclosure process you followed?
> >
> > see attached.
>
> Do I correctly infer from this that you privately reported the attack on
> Thursday around 15:46 UTC, didn't receive any replies in four days
> (including a weekend), and published the attack on Monday at 13:21 UTC?
>
> That's a very short timeline to use for going public due to not receiving a
> response. I think it's typical to give triage at least 30 days to respond,
> often while also prompting them additional times for a response if
> necessary.
I'm on the bitcoin-security mailing list. Every single plausible issue that has
been raised in the past few years has gotten a response within two days. A few
days is plenty of time to at least respond with a simple "give us more time" if
needed.
Secondly, I was able to verify independently that the relevant people had seen
the email and weren't planning on replying. Which isn't surprising. It's just
another way to perform an obvious, well known, class of attack.
Anyway, I think the lesson to be learned here is I'd have been better off not
disclosing to bitcoin-security first. You're just harassing me here; I highly
suspect you'd have said nothing at all if I hadn't brought up disclosure.
--
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/ZgRfvrYatcpqPNRn%40petertodd.org.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [bitcoindev] A Free-Relay Attack Exploiting RBF Rule #6
@ 2024-03-27 17:18 David A. Harding
2024-03-27 18:04 ` Peter Todd
0 siblings, 1 reply; 22+ messages in thread
From: David A. Harding @ 2024-03-27 17:18 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoindev
On 2024-03-27 02:10, Peter Todd wrote:
> On Tue, Mar 26, 2024 at 08:36:45AM -1000, David A. Harding wrote:
>> Could you tell us more about the disclosure process you followed?
>
> see attached.
Do I correctly infer from this that you privately reported the attack on
Thursday around 15:46 UTC, didn't receive any replies in four days
(including a weekend), and published the attack on Monday at 13:21 UTC?
That's a very short timeline to use for going public due to not
receiving a response. I think it's typical to give triage at least 30
days to respond, often while also prompting them additional times for a
response if necessary.
-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/f7fbeb4f58904fc5a24b6fc2d829036c%40dtrt.org.
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2024-03-29 21:14 UTC | newest]
Thread overview: 22+ 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
2024-03-27 17:18 David A. Harding
2024-03-27 18:04 ` Peter Todd
2024-03-27 19:50 ` David A. Harding
2024-03-27 20:30 ` Peter Todd
2024-03-27 22:05 ` Steve Lee
2024-03-28 18:34 ` Antoine Riard
2024-03-28 19:16 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox