A Free-Relay Attack Exploiting RBF Rule #6

[Peter Todd]

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

[Nagaev Boris]

Hi Peter,

On Mon, Mar 18, 2024 at 10:24 AM Peter Todd <pe...@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

[Peter Todd]

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 <pe...@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.

[Antoine Riard]

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

[Nagaev Boris]

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).

[David A. Harding]

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

[Antoine Riard]

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

 

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/012f89763cc336cd91eec13dccefc921%40dtrt.org.

[Peter Todd]

If you're going to accuse me of having a "history" of "publicly revealing
vulnerabilities before they could be quietly patched", do you have more than
one example, from 6 years ago, for a vulnerability that was impossible to
quietly patch, and more costly to exploit than already existing
vulnerabilities, that only impacts an insecure way of using Bitcoin? As I said,
I was simply mistaken about whether or not that issue had been publicly
revealed. Six years later we still haven't even tried to fix it in a soft-fork.
In hindsight, I was correct to talk about it publicly as people relying on
SPV-style proofs should know about the issue and find ways to mitigate it; I
even proposed one such mitigation.

Anyway, see attached. I disclosed the issue, received confirmation that
relevant people had seen it, and no-one raised any objections to publishing it.
I'm not surprised by that, as I merely disclosed a realtively small extension
to an already publicly known class of vulnerability.

Now, do you have a proposal for how this could be "quietly patched"?

[Peter Todd]

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.

[Peter Todd]

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.

[David A. Harding]

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

[Peter Todd]

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.

[Antoine Riard]

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

[David A. Harding]

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/

[Peter Todd]

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?

[Steve Lee]

On Wed, Mar 27, 2024 at 2:56 PM Peter Todd <pe...@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.

[Peter Todd]

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.

[Peter Todd]

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.

[Antoine Riard]

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.

--

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+...@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.

[Antoine Riard]

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

[Peter Todd]

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.

[Peter Todd]

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.

[Antoine Riard]

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