[bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 8003 bytes --]

# Summary

This is a public disclosure of a vulnerability that I previously disclosed to
the bitcoin-security mailing list. It's an easy vulnerability to fix. Although
as with other "free" relay attacks I've disclosed, I didn't get a substantive
response from Bitcoin Core, other than Core closing the my pull-req enabling
full-RBF by default that would fix this specific vulnerability.

But read on, this is quite an odd case of Core politics, and the story is not
as simple as Core refusing to fix a vulnerability. Also, I've including a fun
homework problem at the end: figure out how TRUC/V3 transactions itself creates
a "free" relay attack.


# Background

This is just one of a few "free" relay attacks that I have recently disclosed,
including, but not limited to:

    "A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2024
    https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg

    "A Free-Relay Attack Exploiting Min-Relay-Fee Differences" - Mar 31st 2024
    https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo

The term "free relay attack" simply refers to any mechanism where transaction
data can be broadcast at unusually low cost; the "free" in "free relay" is a
misnomer as all these attacks do in fact have some cost.

This particular attack isn't significantly different than the other attacks
I've disclosed. With one important exception: unlike those other attacks,
fixing this particular attack would be quite easy, by enabling full-rbf by
default. So I disclosed it to the bitcoin-security mailing list as a test: does
Bitcoin Core actually care about free relay attacks? My hypothesis is that Core
does not, as they know full well that "free" relay is an unavoidable problem;
I've received absolutely no feedback from any Bitcoin Core members for the
other disclosed attacks, beyond achow using my disclosure of the RBF Rule #6
attack as an excuse to remove me from the bitcoin-security mailing list.

The fact that Core doesn't actually care about "free" relay attacks is relevant
to TRUC/V3 Transactions. As per BIP-431:

    "The primary problem with [RBFR proposals] is the potential for free relay and DDoS attacks.

    Removing Rule 3 and 4 in general would allow free relay [27]."
    https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki#user-content-Alternatives_replace_by_feerate

I believe the authors of that BIP are fully aware of the fact that "free" relay
is an unavoidable problem, making their rational for TRUC/V3 bogus, and don't
want to admit that they've wasted a large amount of engineering time on a bad
proposal. I will be submitting a pull-req to get BIP-431 corrected, as the many
"free" relay attacks I've disclosed clearly show that claiming RBFR would
"allow" free relay is simply not true.

Notably, full-RBF is _itself_ a transaction pinning fix for many use-cases;
part of the TRUC/V3 standard is to force full-RBF behavior for V3 transactions.
So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a second
way, and TRUC/V3 proponents were the ones who tried to get the full-RBF option
removed from Core in the first place. If not for this dumb bit of Core
politics, I'm sure my year-old pull-req to enable full-RBF by default would
have been merged many months ago, as almost all hashpower has adopted full-RBF
making objections based on "zeroconf" absurd.


# The Attack

If you're a competent Bitcoin engineer, familiar with how mempools work, you've
probably figured it out already based on the title: obviously, if a high
percentage of miners are adopting a policy that Bitcoin Core nodes are not, you
can cheaply consume transaction relay bandwidth by simply relaying transations
that miners are rejecting.

Specifically, do the following:

1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled.
2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate.
3. Spend the outputs of A in a large, low fee-rate, transaction B with BIP-125
   opt-in enabled. ~100% of miners will reject B, as it spends an input not in
   their mempools. However Bitcoin Core nodes will waste bandwidth propagating
   B.
4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will waste
   bandwidth propagating Bn's that ~100% of miners are ignoring.
5. Double-spend A2 to recover your funds and do it all over again (or if A2 had
   a high enough fee-rate, just wait for it to be mined).

The cost to relay each B transaction depends on the fee-rate of B. Since
Bitcoin Core defaults to a fairly large mempool, the minimum relay fee-rate is
typically well below the economic fee-rate required for miners to actually mine
a transaction; Core accepts transactions that are uneconomical for miners to
mine for the forseeable future.

For example, at the moment typical mempools require transactions to pay at
least 1sat/vB, while there are hundreds of MvB worth of transactions paying
4sat/vB, the minimum economical fee-rate. Thus, transactions paying less than
4sat/VB are extremely unlikely to get mined in the nearish future.

Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/vB would
have almost zero cost as the probability of those transactions getting mined is
nearly zero. This is true _regardless_ of what % of miners are mining full-RBF!
As long as you can get at least one miner to mine the A double-spend, the
attack only costs what it cost to get A mined.

If B's are broadcast at a higher fee-rate than the minimum economical fee-rate,
then the % of full-RBF miners matters. For example, if only 99% of miners mine
full-RBF, the chance of a B transaction getting mined per block is about 1%, so
the amortized cost of broadcasting B is about 1% of whatever total fee the
highest fee-rate variant of B pays.

For an attacker who does not need any B to be broadcast, the cost savings to
use of relay bandwidth is approximately the ratio of the difference in size
between B and and A. With a maximum standard transaction size of 100KvB, or
400KB serialized size, this ratio is on the order of 5000:1, times the total
number of B variants broadcast, and the % chance of each B being mined; it's a
few orders of magnitude.

Of course, as mentioned above, this is just one of *many* "free" relay attacks,
so fixing this particular issue doesn't change much.


# Attackers Who Benefit From B Getting Mined

Some attackers actually need B to get mined. For example, imagine an exchange
who needs to do large consolidation transactions. They could use this attack
(and some attacks like it) as a way to goad users and miners into mining
consolidation transactions for them at low cost. In this variant of the attack,
the attacker would pad the size of B with consolidation spends that they needed
to do anyway. Someone who tried to stop the attack by getting B mined (eg via
mempool.space's transaction accellerator) would simply be paying the attacker's
fees for them.

Obviously, this strategy is only relevant for B's below the economic fee-rate.
However, the weaker version of this strategy is to parallize the attack, and do
your consolidation with the _A_ double-spends to reduce the # of bytes used per
full-rbf double-spend.


# TRUC/V3 Creates a Free Relay Attack

I'll leave the details of this as a homework problem. But obviously, the
introduction of TRUC/V3 transactions *itself* creates a free relay attack very
similar to the above! Just like full-RBF, not all miners will mine V3
transactions. So you can do the exact same type of attack by taking advantage
of this difference in mining policy.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zpk7EYgmlgPP3Y9D%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 12764 bytes --]

Hi Peter,

Thanks for the sharing of information about "free relay" attack.

I have one question I'm curious to know the answer which is how much time 
have
been left the private report of this issue to the bitcoin-security mailing 
list
and the public disclosure. With still in mind the conversation that happens 
on
the other thread few months ago, and unless emergency I think it's good to 
give
few weeks of leeway for a vendor team to answer substantially [0].

Beyond, if what you're saying is correct, in your administrative removal 
from the
bitcoin-security mailing list by achow, I'm curious in achow explaining in 
public
its rational in this unexpected decision and what did happen in its own 
words.
I respect achow as a bitcoin core maintainer from years of collaboration on 
the
repository and achow is one of the few bitcoin professionals I still 
reasonably
trust in matters of security report and coordinated mitigation in this 
space.

All that said, with the new information you're sharing and without achow's 
substantial
answer, it let me ponder if achow is still worthy that it's someome with 
whom I'll share
in the future security-sensitive related information to bitcoin core and 
the base-layer
robustnes. After all, the bitcoin-security mailing list is just a 
communication endpoint
and there is no adamant ethical rule abstraining a security researcher to 
diligently 
report issues.

About V3 / TRUC, I must say that originally few years ago when we 
discovered all the
transaction pinning issues affecting lightning funds security in a strict 
sense, I was
among the people advocating the design and deployment of new policy rules 
as a way to
migitate the pinnings concerns [1]. I must say with more implementation 
experiences of
policy rules, new discovery like replacement cycling issues and reasoning 
on the mining
game-theory of policy rules, I've come incredebly skeptical that V3 / TRUC 
is the "right
way" to mitigate pinnings vectors. At the very best, in my opinion it's a 
"poor's man band
aid"'s in waiting that someone design something better.

This wouldn't bet the first time that less-than-perfect p2p / mempools 
extensions are
introduced in bitcoin (e.g bip37) and with time more and more folks realize 
that effectively
the design has more and more apparent weakeness with time.

About the new attack itself, which I beleive holds at first read, I think 
your explanation
can benefit to layout more the mining topology configutation and policy 
default which makes
the free-relay attack exploitable and explain step-by-step how the spend 
and double-spend
are propagate in the transaction-relay network.

In my understanding, the attack efficiency varies widely in function of the 
hashrate ressources
of the miner getting the high-feerate double-spend A2 transaction. I think 
higher are the hashrate
ressources, lower would have been the transaction B (re)-broadcast 
bandwidth waste.

I don't think the exploitation example with an exchange you're giving is 
the more speaking
adversarial example, however I believe it's an interesting building block 
for other types of
attacks, which is worthy of research.

On the TRUC / V3 creating new attacks vectors, this will all dependent if 
the miners adopt
this change and if they estimate it's maximzing their mining income revenue 
in average, it's
a one line of code to disable currently (L134 in `src/policy/policy.h` 
tweaking the 3 back to 2).

Best,
Antoine
ots hash: d40d371e725626589feaf439dcc301af9ae287f5dc06eb26155b95fcd608438e

[0] I checked my own archive after writing this email on the "free relay" 
thread [2]. In fact
even about time-dilation attack, I gave more than 2 weeks for the lightning 
maintainers to do
something, if they wished so before to do a full-disclosure. 2 weeks is a 
reasonable heuristic.

[1] See 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018063.html

[2] https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg
Le jeudi 18 juillet 2024 à 17:04:26 UTC+1, Peter Todd a écrit :

> # Summary
>
> This is a public disclosure of a vulnerability that I previously disclosed 
> to
> the bitcoin-security mailing list. It's an easy vulnerability to fix. 
> Although
> as with other "free" relay attacks I've disclosed, I didn't get a 
> substantive
> response from Bitcoin Core, other than Core closing the my pull-req 
> enabling
> full-RBF by default that would fix this specific vulnerability.
>
> But read on, this is quite an odd case of Core politics, and the story is 
> not
> as simple as Core refusing to fix a vulnerability. Also, I've including a 
> fun
> homework problem at the end: figure out how TRUC/V3 transactions itself 
> creates
> a "free" relay attack.
>
>
> # Background
>
> This is just one of a few "free" relay attacks that I have recently 
> disclosed,
> including, but not limited to:
>
> "A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2024
> https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg
>
> "A Free-Relay Attack Exploiting Min-Relay-Fee Differences" - Mar 31st 2024
> https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo
>
> The term "free relay attack" simply refers to any mechanism where 
> transaction
> data can be broadcast at unusually low cost; the "free" in "free relay" is 
> a
> misnomer as all these attacks do in fact have some cost.
>
> This particular attack isn't significantly different than the other attacks
> I've disclosed. With one important exception: unlike those other attacks,
> fixing this particular attack would be quite easy, by enabling full-rbf by
> default. So I disclosed it to the bitcoin-security mailing list as a test: 
> does
> Bitcoin Core actually care about free relay attacks? My hypothesis is that 
> Core
> does not, as they know full well that "free" relay is an unavoidable 
> problem;
> I've received absolutely no feedback from any Bitcoin Core members for the
> other disclosed attacks, beyond achow using my disclosure of the RBF Rule 
> #6
> attack as an excuse to remove me from the bitcoin-security mailing list.
>
> The fact that Core doesn't actually care about "free" relay attacks is 
> relevant
> to TRUC/V3 Transactions. As per BIP-431:
>
> "The primary problem with [RBFR proposals] is the potential for free relay 
> and DDoS attacks.
>
> Removing Rule 3 and 4 in general would allow free relay [27]."
>
> https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki#user-content-Alternatives_replace_by_feerate
>
> I believe the authors of that BIP are fully aware of the fact that "free" 
> relay
> is an unavoidable problem, making their rational for TRUC/V3 bogus, and 
> don't
> want to admit that they've wasted a large amount of engineering time on a 
> bad
> proposal. I will be submitting a pull-req to get BIP-431 corrected, as the 
> many
> "free" relay attacks I've disclosed clearly show that claiming RBFR would
> "allow" free relay is simply not true.
>
> Notably, full-RBF is _itself_ a transaction pinning fix for many use-cases;
> part of the TRUC/V3 standard is to force full-RBF behavior for V3 
> transactions.
> So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a second
> way, and TRUC/V3 proponents were the ones who tried to get the full-RBF 
> option
> removed from Core in the first place. If not for this dumb bit of Core
> politics, I'm sure my year-old pull-req to enable full-RBF by default would
> have been merged many months ago, as almost all hashpower has adopted 
> full-RBF
> making objections based on "zeroconf" absurd.
>
>
> # The Attack
>
> If you're a competent Bitcoin engineer, familiar with how mempools work, 
> you've
> probably figured it out already based on the title: obviously, if a high
> percentage of miners are adopting a policy that Bitcoin Core nodes are 
> not, you
> can cheaply consume transaction relay bandwidth by simply relaying 
> transations
> that miners are rejecting.
>
> Specifically, do the following:
>
> 1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled.
> 2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate.
> 3. Spend the outputs of A in a large, low fee-rate, transaction B with 
> BIP-125
> opt-in enabled. ~100% of miners will reject B, as it spends an input not in
> their mempools. However Bitcoin Core nodes will waste bandwidth propagating
> B.
> 4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will 
> waste
> bandwidth propagating Bn's that ~100% of miners are ignoring.
> 5. Double-spend A2 to recover your funds and do it all over again (or if 
> A2 had
> a high enough fee-rate, just wait for it to be mined).
>
> The cost to relay each B transaction depends on the fee-rate of B. Since
> Bitcoin Core defaults to a fairly large mempool, the minimum relay 
> fee-rate is
> typically well below the economic fee-rate required for miners to actually 
> mine
> a transaction; Core accepts transactions that are uneconomical for miners 
> to
> mine for the forseeable future.
>
> For example, at the moment typical mempools require transactions to pay at
> least 1sat/vB, while there are hundreds of MvB worth of transactions paying
> 4sat/vB, the minimum economical fee-rate. Thus, transactions paying less 
> than
> 4sat/VB are extremely unlikely to get mined in the nearish future.
>
> Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/vB 
> would
> have almost zero cost as the probability of those transactions getting 
> mined is
> nearly zero. This is true _regardless_ of what % of miners are mining 
> full-RBF!
> As long as you can get at least one miner to mine the A double-spend, the
> attack only costs what it cost to get A mined.
>
> If B's are broadcast at a higher fee-rate than the minimum economical 
> fee-rate,
> then the % of full-RBF miners matters. For example, if only 99% of miners 
> mine
> full-RBF, the chance of a B transaction getting mined per block is about 
> 1%, so
> the amortized cost of broadcasting B is about 1% of whatever total fee the
> highest fee-rate variant of B pays.
>
> For an attacker who does not need any B to be broadcast, the cost savings 
> to
> use of relay bandwidth is approximately the ratio of the difference in size
> between B and and A. With a maximum standard transaction size of 100KvB, or
> 400KB serialized size, this ratio is on the order of 5000:1, times the 
> total
> number of B variants broadcast, and the % chance of each B being mined; 
> it's a
> few orders of magnitude.
>
> Of course, as mentioned above, this is just one of *many* "free" relay 
> attacks,
> so fixing this particular issue doesn't change much.
>
>
> # Attackers Who Benefit From B Getting Mined
>
> Some attackers actually need B to get mined. For example, imagine an 
> exchange
> who needs to do large consolidation transactions. They could use this 
> attack
> (and some attacks like it) as a way to goad users and miners into mining
> consolidation transactions for them at low cost. In this variant of the 
> attack,
> the attacker would pad the size of B with consolidation spends that they 
> needed
> to do anyway. Someone who tried to stop the attack by getting B mined (eg 
> via
> mempool.space's transaction accellerator) would simply be paying the 
> attacker's
> fees for them.
>
> Obviously, this strategy is only relevant for B's below the economic 
> fee-rate.
> However, the weaker version of this strategy is to parallize the attack, 
> and do
> your consolidation with the _A_ double-spends to reduce the # of bytes 
> used per
> full-rbf double-spend.
>
>
> # TRUC/V3 Creates a Free Relay Attack
>
> I'll leave the details of this as a homework problem. But obviously, the
> introduction of TRUC/V3 transactions *itself* creates a free relay attack 
> very
> similar to the above! Just like full-RBF, not all miners will mine V3
> transactions. So you can do the exact same type of attack by taking 
> advantage
> of this difference in mining policy.
>
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/18fc443d-c347-4a84-94fe-81308ae20b76n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 15576 bytes --]

Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1219 bytes --]

On Thu, Jul 18, 2024 at 04:04:47PM -0700, Antoine Riard wrote:
> Hi Peter,
>
> In my understanding, the attack efficiency varies widely in function of the 
> hashrate ressources
> of the miner getting the high-feerate double-spend A2 transaction. I think 
> higher are the hashrate
> ressources, lower would have been the transaction B (re)-broadcast 
> bandwidth waste.

I think you need to re-read the attack carefully before we discuss this
further. The % of hash power mining full-rbf does not significantly change the
cost efficiency of the attack as long as the fee-rate of the B transaction(s)
is below the minimum economic fee-rate necessary for miners to mine a
transaction. Above the minimum economic fee-rate, the cost efficiency is an
essentially linear function of % of full-rbf miners.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zpm73WHBNIkkIT0Y%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[/dev /fd0]

[-- Attachment #1.1: Type: text/plain, Size: 9279 bytes --]

Hi Peter,

> I didn't get a substantive
> response from Bitcoin Core, other than Core closing the my pull-req 
enabling
> full-RBF by default that would fix this specific vulnerability.

The last comment in the pull request suggests opening a new pull request to 
enable full RBF by default, referencing the one closed due to off-topic 
comments. 

> But read on, this is quite an odd case of Core politics, and the story is 
not
> as simple as Core refusing to fix a vulnerability.

It seems that you are the one trying to politicize this issue. 

/dev/fd0
floppy disk guy

On Thursday, July 18, 2024 at 4:04:26 PM UTC Peter Todd wrote:

> # Summary
>
> This is a public disclosure of a vulnerability that I previously disclosed 
> to
> the bitcoin-security mailing list. It's an easy vulnerability to fix. 
> Although
> as with other "free" relay attacks I've disclosed, I didn't get a 
> substantive
> response from Bitcoin Core, other than Core closing the my pull-req 
> enabling
> full-RBF by default that would fix this specific vulnerability.
>
> But read on, this is quite an odd case of Core politics, and the story is 
> not
> as simple as Core refusing to fix a vulnerability. Also, I've including a 
> fun
> homework problem at the end: figure out how TRUC/V3 transactions itself 
> creates
> a "free" relay attack.
>
>
> # Background
>
> This is just one of a few "free" relay attacks that I have recently 
> disclosed,
> including, but not limited to:
>
> "A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2024
> https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg
>
> "A Free-Relay Attack Exploiting Min-Relay-Fee Differences" - Mar 31st 2024
> https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo
>
> The term "free relay attack" simply refers to any mechanism where 
> transaction
> data can be broadcast at unusually low cost; the "free" in "free relay" is 
> a
> misnomer as all these attacks do in fact have some cost.
>
> This particular attack isn't significantly different than the other attacks
> I've disclosed. With one important exception: unlike those other attacks,
> fixing this particular attack would be quite easy, by enabling full-rbf by
> default. So I disclosed it to the bitcoin-security mailing list as a test: 
> does
> Bitcoin Core actually care about free relay attacks? My hypothesis is that 
> Core
> does not, as they know full well that "free" relay is an unavoidable 
> problem;
> I've received absolutely no feedback from any Bitcoin Core members for the
> other disclosed attacks, beyond achow using my disclosure of the RBF Rule 
> #6
> attack as an excuse to remove me from the bitcoin-security mailing list.
>
> The fact that Core doesn't actually care about "free" relay attacks is 
> relevant
> to TRUC/V3 Transactions. As per BIP-431:
>
> "The primary problem with [RBFR proposals] is the potential for free relay 
> and DDoS attacks.
>
> Removing Rule 3 and 4 in general would allow free relay [27]."
>
> https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki#user-content-Alternatives_replace_by_feerate
>
> I believe the authors of that BIP are fully aware of the fact that "free" 
> relay
> is an unavoidable problem, making their rational for TRUC/V3 bogus, and 
> don't
> want to admit that they've wasted a large amount of engineering time on a 
> bad
> proposal. I will be submitting a pull-req to get BIP-431 corrected, as the 
> many
> "free" relay attacks I've disclosed clearly show that claiming RBFR would
> "allow" free relay is simply not true.
>
> Notably, full-RBF is _itself_ a transaction pinning fix for many use-cases;
> part of the TRUC/V3 standard is to force full-RBF behavior for V3 
> transactions.
> So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a second
> way, and TRUC/V3 proponents were the ones who tried to get the full-RBF 
> option
> removed from Core in the first place. If not for this dumb bit of Core
> politics, I'm sure my year-old pull-req to enable full-RBF by default would
> have been merged many months ago, as almost all hashpower has adopted 
> full-RBF
> making objections based on "zeroconf" absurd.
>
>
> # The Attack
>
> If you're a competent Bitcoin engineer, familiar with how mempools work, 
> you've
> probably figured it out already based on the title: obviously, if a high
> percentage of miners are adopting a policy that Bitcoin Core nodes are 
> not, you
> can cheaply consume transaction relay bandwidth by simply relaying 
> transations
> that miners are rejecting.
>
> Specifically, do the following:
>
> 1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled.
> 2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate.
> 3. Spend the outputs of A in a large, low fee-rate, transaction B with 
> BIP-125
> opt-in enabled. ~100% of miners will reject B, as it spends an input not in
> their mempools. However Bitcoin Core nodes will waste bandwidth propagating
> B.
> 4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will 
> waste
> bandwidth propagating Bn's that ~100% of miners are ignoring.
> 5. Double-spend A2 to recover your funds and do it all over again (or if 
> A2 had
> a high enough fee-rate, just wait for it to be mined).
>
> The cost to relay each B transaction depends on the fee-rate of B. Since
> Bitcoin Core defaults to a fairly large mempool, the minimum relay 
> fee-rate is
> typically well below the economic fee-rate required for miners to actually 
> mine
> a transaction; Core accepts transactions that are uneconomical for miners 
> to
> mine for the forseeable future.
>
> For example, at the moment typical mempools require transactions to pay at
> least 1sat/vB, while there are hundreds of MvB worth of transactions paying
> 4sat/vB, the minimum economical fee-rate. Thus, transactions paying less 
> than
> 4sat/VB are extremely unlikely to get mined in the nearish future.
>
> Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/vB 
> would
> have almost zero cost as the probability of those transactions getting 
> mined is
> nearly zero. This is true _regardless_ of what % of miners are mining 
> full-RBF!
> As long as you can get at least one miner to mine the A double-spend, the
> attack only costs what it cost to get A mined.
>
> If B's are broadcast at a higher fee-rate than the minimum economical 
> fee-rate,
> then the % of full-RBF miners matters. For example, if only 99% of miners 
> mine
> full-RBF, the chance of a B transaction getting mined per block is about 
> 1%, so
> the amortized cost of broadcasting B is about 1% of whatever total fee the
> highest fee-rate variant of B pays.
>
> For an attacker who does not need any B to be broadcast, the cost savings 
> to
> use of relay bandwidth is approximately the ratio of the difference in size
> between B and and A. With a maximum standard transaction size of 100KvB, or
> 400KB serialized size, this ratio is on the order of 5000:1, times the 
> total
> number of B variants broadcast, and the % chance of each B being mined; 
> it's a
> few orders of magnitude.
>
> Of course, as mentioned above, this is just one of *many* "free" relay 
> attacks,
> so fixing this particular issue doesn't change much.
>
>
> # Attackers Who Benefit From B Getting Mined
>
> Some attackers actually need B to get mined. For example, imagine an 
> exchange
> who needs to do large consolidation transactions. They could use this 
> attack
> (and some attacks like it) as a way to goad users and miners into mining
> consolidation transactions for them at low cost. In this variant of the 
> attack,
> the attacker would pad the size of B with consolidation spends that they 
> needed
> to do anyway. Someone who tried to stop the attack by getting B mined (eg 
> via
> mempool.space's transaction accellerator) would simply be paying the 
> attacker's
> fees for them.
>
> Obviously, this strategy is only relevant for B's below the economic 
> fee-rate.
> However, the weaker version of this strategy is to parallize the attack, 
> and do
> your consolidation with the _A_ double-spends to reduce the # of bytes 
> used per
> full-rbf double-spend.
>
>
> # TRUC/V3 Creates a Free Relay Attack
>
> I'll leave the details of this as a homework problem. But obviously, the
> introduction of TRUC/V3 transactions *itself* creates a free relay attack 
> very
> similar to the above! Just like full-RBF, not all miners will mine V3
> transactions. So you can do the exact same type of attack by taking 
> advantage
> of this difference in mining policy.
>
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/18a5e5a2-92b3-4345-853d-5a63b71d848bn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 12031 bytes --]

Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard]

[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]

Hi Peter,

> I think you need to re-read the attack carefully before we discuss this
> further. The % of hash power mining full-rbf does not significantly
change the
> cost efficiency of the attack as long as the fee-rate of the B
transaction(s)
> is below the minimum economic fee-rate necessary for miners to mine a
> transaction. Above the minimum economic fee-rate, the cost efficiency is
an
> essentially linear function of % of full-rbf miners.

This is not the % of hash power mining _full-rbf_ I was pointing to, just
the indistinct
total % of hash power mining.

In my understanding, this is the scenario:
- Alice broadcasts small size, low-feerate transaction opt-in disabled A to
99% of the miners+network nodes mempools
- Alice broadcasts a double-spend of A, a high-feerate transaction A2 to
Mark, a single miner
- Network nodes does not relay transaction A to Mark and vice-versa Mark
does not relay transaction A2 to network nodes
- Alice broadcasts a child B of transaction A to 99% of the miners+network
nodes mempools
- Mark, the single miner confirms in a block A2, rendering as a waste A+B
network bandwidth

Correct if I'm wrong with this scenario and if it does not match the attack
vector you're describing.

The child B can be extended with a full chain of useless children within
max mempool limits.

The attack efficiency (i.e the total vB of bandwidth network waste) is
dependent on the delay
by which transaction A2 is included in Mark's block template and
subsequently mined. Back to
my observation, higher are Mark hashrate ressources, less there is latency
to let transaction B
spontaneously propagate on the network, or for Alice to (re)-broadcast in
cycle.

All that said, I think my open question to you at the beginning of my
answer is still there,
i.e how much time has been left between the private report of this issue to
the sec mailing
list and the public disclosure of your email.

Best,
Antoine
ots hash: 001081aba5b44bf98f8774090fcd62109061e1623965ab8ec71068274b46aaf8

Le ven. 19 juil. 2024 à 02:05, Peter Todd <pete@petertodd.org> a écrit :

> On Thu, Jul 18, 2024 at 04:04:47PM -0700, Antoine Riard wrote:
> > Hi Peter,
> >
> > In my understanding, the attack efficiency varies widely in function of
> the
> > hashrate ressources
> > of the miner getting the high-feerate double-spend A2 transaction. I
> think
> > higher are the hashrate
> > ressources, lower would have been the transaction B (re)-broadcast
> > bandwidth waste.
>
> I think you need to re-read the attack carefully before we discuss this
> further. The % of hash power mining full-rbf does not significantly change
> the
> cost efficiency of the attack as long as the fee-rate of the B
> transaction(s)
> is below the minimum economic fee-rate necessary for miners to mine a
> transaction. Above the minimum economic fee-rate, the cost efficiency is an
> essentially linear function of % of full-rbf miners.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/CALZpt%2BHJvBXM_geK7JC8umrt1goq8bc%2BpnY0mk%2Bo%2Br_%2Bbjrtew%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 4369 bytes --]

Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 6279 bytes --]

On Fri, Jul 19, 2024 at 02:52:29PM +0100, Antoine Riard wrote:
> Hi Peter,
> 
> > I think you need to re-read the attack carefully before we discuss this
> > further. The % of hash power mining full-rbf does not significantly
> change the
> > cost efficiency of the attack as long as the fee-rate of the B
> transaction(s)
> > is below the minimum economic fee-rate necessary for miners to mine a
> > transaction. Above the minimum economic fee-rate, the cost efficiency is
> an
> > essentially linear function of % of full-rbf miners.
> 
> This is not the % of hash power mining _full-rbf_ I was pointing to, just
> the indistinct
> total % of hash power mining.
> 
> In my understanding, this is the scenario:
> - Alice broadcasts small size, low-feerate transaction opt-in disabled A to
> 99% of the miners+network nodes mempools
> - Alice broadcasts a double-spend of A, a high-feerate transaction A2 to
> Mark, a single miner
> - Network nodes does not relay transaction A to Mark and vice-versa Mark
> does not relay transaction A2 to network nodes

Here I think you've misunderstood the attack.

A is a low fee-rate transaction with opt-in disabled. When it is broadcast, it
reaches 100% of nodes.

A2 is a full-RBF double-spend of A. When it is broadcast, it reaches all
nodes/miners with full-RBF enabled, replacing A. Full-RBF nodes do in fact
relay A2 to non-full-rbf nodes they're peered with. But those nodes reject A2
as it is a full-RBF replacement.

We are *not* trying to limit A2 to a single miner, or do any kind of
simultaneous broadcast. We don't need to.

> - Alice broadcasts a child B of transaction A to 99% of the miners+network
> nodes mempools

The % of miners/nodes that accept B isn't particularly relevant; this is an
attack primarily against nodes that have full-RBF disabled (though those nodes
will waste the bandwidth of their full-RBF peers).

> - Mark, the single miner confirms in a block A2, rendering as a waste A+B
> network bandwidth

Again, the attack does not depend on a single miner receiving A2. Indeed, it
works fine even if 100% of hash power is mining A2.

Also, A2 isn't necessarily what gets mined. A2 can be broadcast with a fee-rate
only slightly higher than A that is still below the minimum economic fee-rate,
and then replaced later with an even higher fee-rate double-spend that is a
high enough fee-rate to get mined. Remember that RBF Rule #6 prohibits a
replacement if the fee-rate of the replacement is lower than the directly
replaced transaction.

> Correct if I'm wrong with this scenario and if it does not match the attack
> vector you're describing.

You're not far off. But I believe you are still misunderstanding details, as
described above.

> The child B can be extended with a full chain of useless children within
> max mempool limits.

Correct. Although it's probably simplest to just pick a B that is large enough
to max out the mempool limits on its own.

> The attack efficiency (i.e the total vB of bandwidth network waste) is
> dependent on the delay
> by which transaction A2 is included in Mark's block template and
> subsequently mined. Back to
> my observation, higher are Mark hashrate ressources, less there is latency
> to let transaction B
> spontaneously propagate on the network, or for Alice to (re)-broadcast in
> cycle.

Again, A2 does not need to pay a high enough fee-rate to be economical to mine.
So there are no particular latency requirements between when A, B, and A2 are
broadcast.

All that is necessary for this class of attack is there be at least one miner
willing to mine A2 (or a further double-spend), who rejects A.

> All that said, I think my open question to you at the beginning of my
> answer is still there,
> i.e how much time has been left between the private report of this issue to
> the sec mailing
> list and the public disclosure of your email.

This attack is simply a variant of attacks that were publicly disclosed months
ago, that Core has chosen not to respond to at all, so the exact timeframe
isn't very relevant. This is not actually a new class of attack; the whole
point of my disclosure is to show that Core does not actually care about this
class of attack by showing they won't even bother to fix the simplest possible
version, even when the fix is trivial.

But anyway, I disclosed on Jul 7th giving a 7 day deadline before I'd publish
if I couldn't get any response. I publicly verified that achow (and others) had
received my email on Jul 10th, with achow promising a response. On Jul 12th
rather than replying, Core closed my full-RBF pull-req that fixes this issue.
On Jul 15th I reached out again, and after someone else pointed out that
failing to reply to me was degrading the value of the security mailing list,
and finally got achow and glozow to respond in a perfunctory fashion (glozow
recommended that I open a new full-RBF pull-req). So I published this on Jul
18th after my replies to achow and glozow didn't get any response. This whole
time no-one has asked me to not publish this attack; asking me to keep this
fact about mempools a secret would be rather duplicitous given that a key
argument for TRUC/V3 relies on "free" relay attacks not being possible.

Core could have *easily* responded by simply merging my pull-req to enable
full-RBF by default, a trivial change that has had lots of ACKs from technical
reviewers, which ~100% of hash power has adopted. No-one reasonable would have
questioned merging that pull-req. They chose not to do so, proving my point
that none of this has anything to do with a genuine technical concern.

I was previously on the bitcoin-security mailing list for years, and almost
every disclosed attack has gotten a response within 24 hours, with the longest
about 72 hours (I just skimmed through my archives to double check). Failing to
respond at all is very unusual.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zpp6U00Mp7Z/bOej%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Murch]

On 7/18/24 11:56, Peter Todd wrote:
> # Summary
> 
> This is a public disclosure of a vulnerability that I previously disclosed to
> the bitcoin-security mailing list.

It seems redundant to point out that some transactions are only relayed 
by a subset of a node population if there are multiple diverging mempool 
policies with significant adoption.

However, I concur that Bitcoin Core should match its default setting for 
`mempoolfullrbf` to the behavior of miners, and there appears to be 
palpable evidence that a supermajority of the hashrate has enabled 
`mempoolfullrbf`.

Murch

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/6f6177b4-4fd3-4c22-ad13-97d430d7d0bc%40murch.one.

[bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 12375 bytes --]

Hi /dev/fd0

> The last comment in the pull request suggests opening a new pull request 
to enable full RBF by default, referencing the one closed due to off-topic 
comments.

I'm interested if you can propose a formal or mathematical definition of 
what constitute
an in-topic of off-topic comments on a matters like full RBF, which has 
been controversial
for like a decade. I can only think such definition could make future 
conversations about
the boundaries of what is in / off bitcoin engineering topic more objective.

> It seems that you are the one trying to politicize this issue.

Let's be realistic on the state of bitcoin core security issues handling in 
the recent words of
a group of some active contributors:

"The project has historically done a poor job at publicly disclosing 
security-critical bugs, whether
externally reported or found by contributors. This has led to a situation 
where a lot of users perceive
Bitcoin Core as never having bugs. This perception is dangerous and, 
unfortunately, not accurate." [0].

[0] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w

Again, I'm interested if you can propose a formal or mathematical 
definition of what constitute
a reasonable bitcoin core vulnerability handling policy and that way give 
more ground on qualifying
if a present situation is falling out of this reasonable guidelines and 
that can be qualified more 
objectively as "politics".

I think we have a mailing list to favorize textual long format and 
encourage a more self-reflexive
mode of reasoning in the conduct of bitcoin engineering discussions. I 
believe comments not bringing
new factual information or pointing to past experiences or concrete piece 
of information are better
left to twitter / nostr / reddit, whatever other communication channel 
where the scientific and
ethics of conversation standards are less stringent.

All that said, I'm thinking to agree that the usage of all political 
rhethoric is a fallacy better
left for expressions on other communication channels and this is note wise 
to bundle it with novel
technical information, as from the outset it does not favor to concentrate 
the discussion on the fact
and logical reasoning themselves. Even more, political rhetoric very easily 
downgrade in moralistic
contest among protagonists on who has the monopole of the good / truth. 
Somehow bitcoin is beyond
good and evil (-- under some long-term and abstract perspective).

Best,
Antoine
ots hash: 3088507ecfb55ed301bb0defce9fb490daa6bb9594e96d57336d603556a8fdab
Le vendredi 19 juillet 2024 à 19:27:36 UTC+1, /dev /fd0 a écrit :

> Hi Peter,
>
> > I didn't get a substantive
> > response from Bitcoin Core, other than Core closing the my pull-req 
> enabling
> > full-RBF by default that would fix this specific vulnerability.
>
> The last comment in the pull request suggests opening a new pull request 
> to enable full RBF by default, referencing the one closed due to off-topic 
> comments. 
>
> > But read on, this is quite an odd case of Core politics, and the story 
> is not
> > as simple as Core refusing to fix a vulnerability.
>
> It seems that you are the one trying to politicize this issue. 
>
> /dev/fd0
> floppy disk guy
>
> On Thursday, July 18, 2024 at 4:04:26 PM UTC Peter Todd wrote:
>
>> # Summary 
>>
>> This is a public disclosure of a vulnerability that I previously 
>> disclosed to 
>> the bitcoin-security mailing list. It's an easy vulnerability to fix. 
>> Although 
>> as with other "free" relay attacks I've disclosed, I didn't get a 
>> substantive 
>> response from Bitcoin Core, other than Core closing the my pull-req 
>> enabling 
>> full-RBF by default that would fix this specific vulnerability. 
>>
>> But read on, this is quite an odd case of Core politics, and the story is 
>> not 
>> as simple as Core refusing to fix a vulnerability. Also, I've including a 
>> fun 
>> homework problem at the end: figure out how TRUC/V3 transactions itself 
>> creates 
>> a "free" relay attack. 
>>
>>
>> # Background 
>>
>> This is just one of a few "free" relay attacks that I have recently 
>> disclosed, 
>> including, but not limited to: 
>>
>> "A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2024 
>> https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg 
>>
>> "A Free-Relay Attack Exploiting Min-Relay-Fee Differences" - Mar 31st 
>> 2024 
>> https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo 
>>
>> The term "free relay attack" simply refers to any mechanism where 
>> transaction 
>> data can be broadcast at unusually low cost; the "free" in "free relay" 
>> is a 
>> misnomer as all these attacks do in fact have some cost. 
>>
>> This particular attack isn't significantly different than the other 
>> attacks 
>> I've disclosed. With one important exception: unlike those other attacks, 
>> fixing this particular attack would be quite easy, by enabling full-rbf 
>> by 
>> default. So I disclosed it to the bitcoin-security mailing list as a 
>> test: does 
>> Bitcoin Core actually care about free relay attacks? My hypothesis is 
>> that Core 
>> does not, as they know full well that "free" relay is an unavoidable 
>> problem; 
>> I've received absolutely no feedback from any Bitcoin Core members for 
>> the 
>> other disclosed attacks, beyond achow using my disclosure of the RBF Rule 
>> #6 
>> attack as an excuse to remove me from the bitcoin-security mailing list. 
>>
>> The fact that Core doesn't actually care about "free" relay attacks is 
>> relevant 
>> to TRUC/V3 Transactions. As per BIP-431: 
>>
>> "The primary problem with [RBFR proposals] is the potential for free 
>> relay and DDoS attacks. 
>>
>> Removing Rule 3 and 4 in general would allow free relay [27]." 
>>
>> https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki#user-content-Alternatives_replace_by_feerate 
>>
>> I believe the authors of that BIP are fully aware of the fact that "free" 
>> relay 
>> is an unavoidable problem, making their rational for TRUC/V3 bogus, and 
>> don't 
>> want to admit that they've wasted a large amount of engineering time on a 
>> bad 
>> proposal. I will be submitting a pull-req to get BIP-431 corrected, as 
>> the many 
>> "free" relay attacks I've disclosed clearly show that claiming RBFR would 
>> "allow" free relay is simply not true. 
>>
>> Notably, full-RBF is _itself_ a transaction pinning fix for many 
>> use-cases; 
>> part of the TRUC/V3 standard is to force full-RBF behavior for V3 
>> transactions. 
>> So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a 
>> second 
>> way, and TRUC/V3 proponents were the ones who tried to get the full-RBF 
>> option 
>> removed from Core in the first place. If not for this dumb bit of Core 
>> politics, I'm sure my year-old pull-req to enable full-RBF by default 
>> would 
>> have been merged many months ago, as almost all hashpower has adopted 
>> full-RBF 
>> making objections based on "zeroconf" absurd. 
>>
>>
>> # The Attack 
>>
>> If you're a competent Bitcoin engineer, familiar with how mempools work, 
>> you've 
>> probably figured it out already based on the title: obviously, if a high 
>> percentage of miners are adopting a policy that Bitcoin Core nodes are 
>> not, you 
>> can cheaply consume transaction relay bandwidth by simply relaying 
>> transations 
>> that miners are rejecting. 
>>
>> Specifically, do the following: 
>>
>> 1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled. 
>> 2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate. 
>> 3. Spend the outputs of A in a large, low fee-rate, transaction B with 
>> BIP-125 
>> opt-in enabled. ~100% of miners will reject B, as it spends an input not 
>> in 
>> their mempools. However Bitcoin Core nodes will waste bandwidth 
>> propagating 
>> B. 
>> 4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will 
>> waste 
>> bandwidth propagating Bn's that ~100% of miners are ignoring. 
>> 5. Double-spend A2 to recover your funds and do it all over again (or if 
>> A2 had 
>> a high enough fee-rate, just wait for it to be mined). 
>>
>> The cost to relay each B transaction depends on the fee-rate of B. Since 
>> Bitcoin Core defaults to a fairly large mempool, the minimum relay 
>> fee-rate is 
>> typically well below the economic fee-rate required for miners to 
>> actually mine 
>> a transaction; Core accepts transactions that are uneconomical for miners 
>> to 
>> mine for the forseeable future. 
>>
>> For example, at the moment typical mempools require transactions to pay 
>> at 
>> least 1sat/vB, while there are hundreds of MvB worth of transactions 
>> paying 
>> 4sat/vB, the minimum economical fee-rate. Thus, transactions paying less 
>> than 
>> 4sat/VB are extremely unlikely to get mined in the nearish future. 
>>
>> Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/vB 
>> would 
>> have almost zero cost as the probability of those transactions getting 
>> mined is 
>> nearly zero. This is true _regardless_ of what % of miners are mining 
>> full-RBF! 
>> As long as you can get at least one miner to mine the A double-spend, the 
>> attack only costs what it cost to get A mined. 
>>
>> If B's are broadcast at a higher fee-rate than the minimum economical 
>> fee-rate, 
>> then the % of full-RBF miners matters. For example, if only 99% of miners 
>> mine 
>> full-RBF, the chance of a B transaction getting mined per block is about 
>> 1%, so 
>> the amortized cost of broadcasting B is about 1% of whatever total fee 
>> the 
>> highest fee-rate variant of B pays. 
>>
>> For an attacker who does not need any B to be broadcast, the cost savings 
>> to 
>> use of relay bandwidth is approximately the ratio of the difference in 
>> size 
>> between B and and A. With a maximum standard transaction size of 100KvB, 
>> or 
>> 400KB serialized size, this ratio is on the order of 5000:1, times the 
>> total 
>> number of B variants broadcast, and the % chance of each B being mined; 
>> it's a 
>> few orders of magnitude. 
>>
>> Of course, as mentioned above, this is just one of *many* "free" relay 
>> attacks, 
>> so fixing this particular issue doesn't change much. 
>>
>>
>> # Attackers Who Benefit From B Getting Mined 
>>
>> Some attackers actually need B to get mined. For example, imagine an 
>> exchange 
>> who needs to do large consolidation transactions. They could use this 
>> attack 
>> (and some attacks like it) as a way to goad users and miners into mining 
>> consolidation transactions for them at low cost. In this variant of the 
>> attack, 
>> the attacker would pad the size of B with consolidation spends that they 
>> needed 
>> to do anyway. Someone who tried to stop the attack by getting B mined (eg 
>> via 
>> mempool.space's transaction accellerator) would simply be paying the 
>> attacker's 
>> fees for them. 
>>
>> Obviously, this strategy is only relevant for B's below the economic 
>> fee-rate. 
>> However, the weaker version of this strategy is to parallize the attack, 
>> and do 
>> your consolidation with the _A_ double-spends to reduce the # of bytes 
>> used per 
>> full-rbf double-spend. 
>>
>>
>> # TRUC/V3 Creates a Free Relay Attack 
>>
>> I'll leave the details of this as a homework problem. But obviously, the 
>> introduction of TRUC/V3 transactions *itself* creates a free relay attack 
>> very 
>> similar to the above! Just like full-RBF, not all miners will mine V3 
>> transactions. So you can do the exact same type of attack by taking 
>> advantage 
>> of this difference in mining policy. 
>>
>> -- 
>> https://petertodd.org 'peter'[:-1]@petertodd.org 
>>
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/9c4c2a65-2c87-47f1-85d1-137c32099fb7n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 15012 bytes --]

Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 15101 bytes --]

Hi Peter,

> A is a low fee-rate transaction with opt-in disabled. When it is 
broadcast, it
> reaches 100% of nodes.
> 
> A2 is a full-RBF double-spend of A. When it is broadcast, it reaches all
> nodes/miners with full-RBF enabled, replacing A. Full-RBF nodes do in fact
> relay A2 to non-full-rbf nodes they're peered with. But those nodes 
reject A2
> as it is a full-RBF replacement.
>
> We are *not* trying to limit A2 to a single miner, or do any kind of
> simultaneous broadcast. We don't need to.

Okay, I see. Effectively, the attack holds are you're describing as 
transaction A2
will propagate along the `mempoolfullrbf=1` transaction-relay network 
paths. I think
the initial description could have been clearer with this additional 
observation, as
somehow I think there is the low-odd marginal situation where the attacker 
broadcasting
full-node is randomly peered with only transaction-relay `mempoolfullrbf=0` 
neighboring
nodes, and as such the bandwidth waste denial-of-service negligeable.

This is correct there is no concurrent broadcast necessarily involved.

> The % of miners/nodes that accept B isn't particularly relevant; this is 
an
> attack primarily against nodes that have full-RBF disabled (though those 
nodes
> will waste the bandwidth of their full-RBF peers).

Yes I agree with this observation. In a world where a supermajority of 
miners is running
full-rbf as policy settings, I'll let what the corrollorary means in terms 
of transaction-relay
network decentralization to be fully explained by someone else.

> Again, the attack does not depend on a single miner receiving A2. Indeed, 
it
> works fine even if 100% of hash power is mining A2.
> 
> Also, A2 isn't necessarily what gets mined. A2 can be broadcast with a 
fee-rate
> only slightly higher than A that is still below the minimum economic 
fee-rate,
> and then replaced later with an even higher fee-rate double-spend that is 
a
> high enough fee-rate to get mined. Remember that RBF Rule #6 prohibits a
> replacement if the fee-rate of the replacement is lower than the directly
> replaced transaction.

Yes, I think what you're pointing is what makes the attack quite 
interesting as there
is no strict attacker necessity for A2 to be mined at some point in time 
for the attack
effect to play out. Note, see bitcoin core issue #14895 were few years ago 
such mempool
adaptive attacker were pondered about transaction pinnings affecting 
lightning.

> You're not far off. But I believe you are still misunderstanding details, 
as
described above.

See above.

> Correct. Although it's probably simplest to just pick a B that is large 
enough
to max out the mempool limits on its own.

I believe this observation can be still game out more at the advantage of 
the attacker.

> Again, A2 does not need to pay a high enough fee-rate to be economical to 
mine.
> So there are no particular latency requirements between when A, B, and A2 
are
> broadcast.
> 
> All that is necessary for this class of attack is there be at least one 
miner
> willing to mine A2 (or a further double-spend), who rejects A.

Yes, I see more what is interesting with this attack by playing out on 
network
mepool feerate segment asymmetries arising from transaction-relay policy 
divergence.

> This attack is simply a variant of attacks that were publicly disclosed 
months
> ago, that Core has chosen not to respond to at all, so the exact timeframe
> isn't very relevant. This is not actually a new class of attack; the whole
> point of my disclosure is to show that Core does not actually care about 
this
> class of attack by showing they won't even bother to fix the simplest 
possible
> version, even when the fix is trivial.

As I said few months ago, I don't think this is a new class of attacks in 
bitcoin dev
circles conversations about network DoS. To point out more historical 
conversation this
class of attack was pointed out by gmaxwell years ago on the bitcoin core 
pr #16698 few
years ago [0].

[0] https://github.com/bitcoin/bitcoin/pull/16698#issuecomment-571399346

I think rather to accuse people currently maintaining the bitcoin-core sec 
mailing list
of malovencly, it's more constructive to question if this set of people 
still have the
competency and bitcoin security culture to diligently understand and 
address this class
of attacks (and with gmaxwell in its own recent words on another channel 
being far far less
active in bitcoin protocol dev it's not a purely rhetorical question).

In general, there is no necessity to assign to malevolency what can be 
assigned to
genuine incompetence or willful laziness.

> But anyway, I disclosed on Jul 7th giving a 7 day deadline before I'd 
publish
> if I couldn't get any response. I publicly verified that achow (and 
others) had
> received my email on Jul 10th, with achow promising a response. On Jul 
12th
> rather than replying, Core closed my full-RBF pull-req that fixes this 
issue.
> On Jul 15th I reached out again, and after someone else pointed out that
> failing to reply to me was degrading the value of the security mailing 
list,
> and finally got achow and glozow to respond in a perfunctory fashion 
(glozow
> recommended that I open a new full-RBF pull-req). So I published this on 
Jul
> 18th after my replies to achow and glozow didn't get any response. This 
whole
> time no-one has asked me to not publish this attack; asking me to keep 
this
> fact about mempools a secret would be rather duplicitous given that a key
> argument for TRUC/V3 relies on "free" relay attacks not being possible.
> 
> Core could have *easily* responded by simply merging my pull-req to enable
> full-RBF by default, a trivial change that has had lots of ACKs from 
technical
> reviewers, which ~100% of hash power has adopted. No-one reasonable would 
have
> questioned merging that pull-req. They chose not to do so, proving my 
point
> that none of this has anything to do with a genuine technical concern.

Okay, with more information I think both achow and glozow answers are 
reasonable
in matters of formal responsiveness.

That they pointed out to carry with a public process to fix that category 
of attacks
only give more ground at my hypothesis highlighted above that it can be a 
problem of
security culture knowledge or lack of experience know-how in handling 
"half" / full 
covert fixes.

Sadly, I must say this is matching my historical experience with the 
bitcoin security
mailing list (and I had far more seasoned interlocutors) or the ones of 
other security
issues reporters I'm aware off.

> I was previously on the bitcoin-security mailing list for years, and 
almost
> every disclosed attack has gotten a response within 24 hours, with the 
longest
> about 72 hours (I just skimmed through my archives to double check). 
Failing to
> respond at all is very unusual.

As said in one my previous email, I'm still curious about achow101 
explaining publicly
why you have been kicked-out of the bitcoin-security mailing list, when you 
were certainly
more senior than achow101 in matters of base-layer security issues or even 
hard technical
issues like consensus interactions (e.g bip65). I'll re-iterate my respect 
towards achow101
as a maintainer from years of collaboration, though this is a topic worthy 
of an answer.

Without a public answer under 2 weeks, I'll remove achow101 from among the 
future security
reports recipients I can make about the bitcoin core project, be it a 
report that is codebase-only
or any security issues related to the base layer and affecting all 
full-nodes implementations
or the mining stack.

Under the information shared and from my perspective, achow101 argued 
conduct of playing
for unknown reasons with an adminstrative communication endpoint creates a 
moral hazard
and this would be further unethical for me as a security researcher to 
share sensitive security
information with that bitcoin maintainer.

Best,
Antoine
ots hash: e8a6473014d397c35779fd4d165bea20ea03c14091078d6140b3394c6a88a464

Le vendredi 19 juillet 2024 à 19:27:40 UTC+1, Peter Todd a écrit :

> On Fri, Jul 19, 2024 at 02:52:29PM +0100, Antoine Riard wrote:
> > Hi Peter,
> > 
> > > I think you need to re-read the attack carefully before we discuss this
> > > further. The % of hash power mining full-rbf does not significantly
> > change the
> > > cost efficiency of the attack as long as the fee-rate of the B
> > transaction(s)
> > > is below the minimum economic fee-rate necessary for miners to mine a
> > > transaction. Above the minimum economic fee-rate, the cost efficiency 
> is
> > an
> > > essentially linear function of % of full-rbf miners.
> > 
> > This is not the % of hash power mining _full-rbf_ I was pointing to, just
> > the indistinct
> > total % of hash power mining.
> > 
> > In my understanding, this is the scenario:
> > - Alice broadcasts small size, low-feerate transaction opt-in disabled A 
> to
> > 99% of the miners+network nodes mempools
> > - Alice broadcasts a double-spend of A, a high-feerate transaction A2 to
> > Mark, a single miner
> > - Network nodes does not relay transaction A to Mark and vice-versa Mark
> > does not relay transaction A2 to network nodes
>
> Here I think you've misunderstood the attack.
>
> A is a low fee-rate transaction with opt-in disabled. When it is 
> broadcast, it
> reaches 100% of nodes.
>
> A2 is a full-RBF double-spend of A. When it is broadcast, it reaches all
> nodes/miners with full-RBF enabled, replacing A. Full-RBF nodes do in fact
> relay A2 to non-full-rbf nodes they're peered with. But those nodes reject 
> A2
> as it is a full-RBF replacement.
>
> We are *not* trying to limit A2 to a single miner, or do any kind of
> simultaneous broadcast. We don't need to.
>
> > - Alice broadcasts a child B of transaction A to 99% of the 
> miners+network
> > nodes mempools
>
> The % of miners/nodes that accept B isn't particularly relevant; this is an
> attack primarily against nodes that have full-RBF disabled (though those 
> nodes
> will waste the bandwidth of their full-RBF peers).
>
> > - Mark, the single miner confirms in a block A2, rendering as a waste A+B
> > network bandwidth
>
> Again, the attack does not depend on a single miner receiving A2. Indeed, 
> it
> works fine even if 100% of hash power is mining A2.
>
> Also, A2 isn't necessarily what gets mined. A2 can be broadcast with a 
> fee-rate
> only slightly higher than A that is still below the minimum economic 
> fee-rate,
> and then replaced later with an even higher fee-rate double-spend that is a
> high enough fee-rate to get mined. Remember that RBF Rule #6 prohibits a
> replacement if the fee-rate of the replacement is lower than the directly
> replaced transaction.
>
> > Correct if I'm wrong with this scenario and if it does not match the 
> attack
> > vector you're describing.
>
> You're not far off. But I believe you are still misunderstanding details, 
> as
> described above.
>
> > The child B can be extended with a full chain of useless children within
> > max mempool limits.
>
> Correct. Although it's probably simplest to just pick a B that is large 
> enough
> to max out the mempool limits on its own.
>
> > The attack efficiency (i.e the total vB of bandwidth network waste) is
> > dependent on the delay
> > by which transaction A2 is included in Mark's block template and
> > subsequently mined. Back to
> > my observation, higher are Mark hashrate ressources, less there is 
> latency
> > to let transaction B
> > spontaneously propagate on the network, or for Alice to (re)-broadcast in
> > cycle.
>
> Again, A2 does not need to pay a high enough fee-rate to be economical to 
> mine.
> So there are no particular latency requirements between when A, B, and A2 
> are
> broadcast.
>
> All that is necessary for this class of attack is there be at least one 
> miner
> willing to mine A2 (or a further double-spend), who rejects A.
>
> > All that said, I think my open question to you at the beginning of my
> > answer is still there,
> > i.e how much time has been left between the private report of this issue 
> to
> > the sec mailing
> > list and the public disclosure of your email.
>
> This attack is simply a variant of attacks that were publicly disclosed 
> months
> ago, that Core has chosen not to respond to at all, so the exact timeframe
> isn't very relevant. This is not actually a new class of attack; the whole
> point of my disclosure is to show that Core does not actually care about 
> this
> class of attack by showing they won't even bother to fix the simplest 
> possible
> version, even when the fix is trivial.
>
> But anyway, I disclosed on Jul 7th giving a 7 day deadline before I'd 
> publish
> if I couldn't get any response. I publicly verified that achow (and 
> others) had
> received my email on Jul 10th, with achow promising a response. On Jul 12th
> rather than replying, Core closed my full-RBF pull-req that fixes this 
> issue.
> On Jul 15th I reached out again, and after someone else pointed out that
> failing to reply to me was degrading the value of the security mailing 
> list,
> and finally got achow and glozow to respond in a perfunctory fashion 
> (glozow
> recommended that I open a new full-RBF pull-req). So I published this on 
> Jul
> 18th after my replies to achow and glozow didn't get any response. This 
> whole
> time no-one has asked me to not publish this attack; asking me to keep this
> fact about mempools a secret would be rather duplicitous given that a key
> argument for TRUC/V3 relies on "free" relay attacks not being possible.
>
> Core could have *easily* responded by simply merging my pull-req to enable
> full-RBF by default, a trivial change that has had lots of ACKs from 
> technical
> reviewers, which ~100% of hash power has adopted. No-one reasonable would 
> have
> questioned merging that pull-req. They chose not to do so, proving my point
> that none of this has anything to do with a genuine technical concern.
>
> I was previously on the bitcoin-security mailing list for years, and almost
> every disclosed attack has gotten a response within 24 hours, with the 
> longest
> about 72 hours (I just skimmed through my archives to double check). 
> Failing to
> respond at all is very unusual.
>
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/4d950527-4430-49f2-8e38-3755bc58e301n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 17011 bytes --]

Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

['Ava Chow' via Bitcoin Development Mailing List]

On 07/19/2024 07:58 PM, Antoine Riard wrote:
> As said in one my previous email, I'm still curious about achow101 
> explaining publicly
> why you have been kicked-out of the bitcoin-security mailing list, when 
> you were certainly
> more senior than achow101 in matters of base-layer security issues or 
> even hard technical
> issues like consensus interactions (e.g bip65). I'll re-iterate my 
> respect towards achow101
> as a maintainer from years of collaboration, though this is a topic 
> worthy of an answer.

I am not the one that removed Peter from the mailing list, nor do I even 
have the login(s) to do so.

There was a discussion amongst several members of the security list 
about who was on the list, and who should be on the list. Given that the 
security list is the _Bitcoin Core_ security list, we determined that 
the people who should be on the list are people who still actively 
contribute to the project. As Peter Todd no longer actively contribute 
code nor code review to the project, we decided that it didn't make 
sense to continue to have him on the list.

My recollection is that multiple other people were removed from the list 
for the same reason at the same time.

Ava

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/4f7eddff-9e2d-4beb-bcc6-832584cb939d%40achow101.com.

[bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[/dev /fd0]

[-- Attachment #1.1: Type: text/plain, Size: 14845 bytes --]

Hi Antoine,

>  I'm interested if you can propose a formal or mathematical definition of 
what constitute
> an in-topic of off-topic comments on a matters like full RBF, which has 
been controversial
> for like a decade.

I will quote _willcl-ark_'s last comment as I do not have enough 
permissions in bitcoin core repository to moderate comments:

"However the comments section here has become difficult to follow due to 
numerous off-topic comments, a few personal disagreements, and repetition 
of arguments. In the interest of having a more productive and focused 
technical and philosophical discussion we are going to close and lock this 
PR."

A new pull request should help reviewers. If you do not agree with it, feel 
free to discuss it with moderators in bitcoin core IRC channel.

>  Again, I'm interested if you can propose a formal or mathematical 
definition of what constitute
> a reasonable bitcoin core vulnerability handling policy and that way give 
more ground on qualifying
> if a present situation is falling out of this reasonable guidelines and 
that can be qualified more
> objectively as "politics".

Related discussion: https://github.com/bitcoin-core/meta/issues/5

> I think we have a mailing list to favorize textual long format and 
encourage a more self-reflexive
> mode of reasoning in the conduct of bitcoin engineering discussions. I 
believe comments not bringing
> new factual information or pointing to past experiences or concrete piece 
of information are better
> left to twitter / nostr / reddit, whatever other communication channel 
where the scientific and
> ethics of conversation standards are less stringent.

Ironically, this is exactly how moderation works in bitcoin core pull 
requests and some comments were marked off-topic..

I have opened a pull request with the same commits (Peter Todd being the 
author) to enable Full RBF by default: 
https://github.com/bitcoin/bitcoin/pull/30493

/dev/fd0
floppy disk guy

On Saturday, July 20, 2024 at 12:01:12 AM UTC Antoine Riard wrote:

> Hi /dev/fd0
>
> > The last comment in the pull request suggests opening a new pull request 
> to enable full RBF by default, referencing the one closed due to off-topic 
> comments.
>
> I'm interested if you can propose a formal or mathematical definition of 
> what constitute
> an in-topic of off-topic comments on a matters like full RBF, which has 
> been controversial
> for like a decade. I can only think such definition could make future 
> conversations about
> the boundaries of what is in / off bitcoin engineering topic more 
> objective.
>
> > It seems that you are the one trying to politicize this issue.
>
> Let's be realistic on the state of bitcoin core security issues handling 
> in the recent words of
> a group of some active contributors:
>
> "The project has historically done a poor job at publicly disclosing 
> security-critical bugs, whether
> externally reported or found by contributors. This has led to a situation 
> where a lot of users perceive
> Bitcoin Core as never having bugs. This perception is dangerous and, 
> unfortunately, not accurate." [0].
>
> [0] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w
>
> Again, I'm interested if you can propose a formal or mathematical 
> definition of what constitute
> a reasonable bitcoin core vulnerability handling policy and that way give 
> more ground on qualifying
> if a present situation is falling out of this reasonable guidelines and 
> that can be qualified more 
> objectively as "politics".
>
> I think we have a mailing list to favorize textual long format and 
> encourage a more self-reflexive
> mode of reasoning in the conduct of bitcoin engineering discussions. I 
> believe comments not bringing
> new factual information or pointing to past experiences or concrete piece 
> of information are better
> left to twitter / nostr / reddit, whatever other communication channel 
> where the scientific and
> ethics of conversation standards are less stringent.
>
> All that said, I'm thinking to agree that the usage of all political 
> rhethoric is a fallacy better
> left for expressions on other communication channels and this is note wise 
> to bundle it with novel
> technical information, as from the outset it does not favor to concentrate 
> the discussion on the fact
> and logical reasoning themselves. Even more, political rhetoric very 
> easily downgrade in moralistic
> contest among protagonists on who has the monopole of the good / truth. 
> Somehow bitcoin is beyond
> good and evil (-- under some long-term and abstract perspective).
>
> Best,
> Antoine
> ots hash: 3088507ecfb55ed301bb0defce9fb490daa6bb9594e96d57336d603556a8fdab
> Le vendredi 19 juillet 2024 à 19:27:36 UTC+1, /dev /fd0 a écrit :
>
>> Hi Peter,
>>
>> > I didn't get a substantive
>> > response from Bitcoin Core, other than Core closing the my pull-req 
>> enabling
>> > full-RBF by default that would fix this specific vulnerability.
>>
>> The last comment in the pull request suggests opening a new pull request 
>> to enable full RBF by default, referencing the one closed due to off-topic 
>> comments. 
>>
>> > But read on, this is quite an odd case of Core politics, and the story 
>> is not
>> > as simple as Core refusing to fix a vulnerability.
>>
>> It seems that you are the one trying to politicize this issue. 
>>
>> /dev/fd0
>> floppy disk guy
>>
>> On Thursday, July 18, 2024 at 4:04:26 PM UTC Peter Todd wrote:
>>
>>> # Summary 
>>>
>>> This is a public disclosure of a vulnerability that I previously 
>>> disclosed to 
>>> the bitcoin-security mailing list. It's an easy vulnerability to fix. 
>>> Although 
>>> as with other "free" relay attacks I've disclosed, I didn't get a 
>>> substantive 
>>> response from Bitcoin Core, other than Core closing the my pull-req 
>>> enabling 
>>> full-RBF by default that would fix this specific vulnerability. 
>>>
>>> But read on, this is quite an odd case of Core politics, and the story 
>>> is not 
>>> as simple as Core refusing to fix a vulnerability. Also, I've including 
>>> a fun 
>>> homework problem at the end: figure out how TRUC/V3 transactions itself 
>>> creates 
>>> a "free" relay attack. 
>>>
>>>
>>> # Background 
>>>
>>> This is just one of a few "free" relay attacks that I have recently 
>>> disclosed, 
>>> including, but not limited to: 
>>>
>>> "A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2024 
>>> https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg 
>>>
>>> "A Free-Relay Attack Exploiting Min-Relay-Fee Differences" - Mar 31st 
>>> 2024 
>>> https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo 
>>>
>>> The term "free relay attack" simply refers to any mechanism where 
>>> transaction 
>>> data can be broadcast at unusually low cost; the "free" in "free relay" 
>>> is a 
>>> misnomer as all these attacks do in fact have some cost. 
>>>
>>> This particular attack isn't significantly different than the other 
>>> attacks 
>>> I've disclosed. With one important exception: unlike those other 
>>> attacks, 
>>> fixing this particular attack would be quite easy, by enabling full-rbf 
>>> by 
>>> default. So I disclosed it to the bitcoin-security mailing list as a 
>>> test: does 
>>> Bitcoin Core actually care about free relay attacks? My hypothesis is 
>>> that Core 
>>> does not, as they know full well that "free" relay is an unavoidable 
>>> problem; 
>>> I've received absolutely no feedback from any Bitcoin Core members for 
>>> the 
>>> other disclosed attacks, beyond achow using my disclosure of the RBF 
>>> Rule #6 
>>> attack as an excuse to remove me from the bitcoin-security mailing list. 
>>>
>>> The fact that Core doesn't actually care about "free" relay attacks is 
>>> relevant 
>>> to TRUC/V3 Transactions. As per BIP-431: 
>>>
>>> "The primary problem with [RBFR proposals] is the potential for free 
>>> relay and DDoS attacks. 
>>>
>>> Removing Rule 3 and 4 in general would allow free relay [27]." 
>>>
>>> https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki#user-content-Alternatives_replace_by_feerate 
>>>
>>> I believe the authors of that BIP are fully aware of the fact that 
>>> "free" relay 
>>> is an unavoidable problem, making their rational for TRUC/V3 bogus, and 
>>> don't 
>>> want to admit that they've wasted a large amount of engineering time on 
>>> a bad 
>>> proposal. I will be submitting a pull-req to get BIP-431 corrected, as 
>>> the many 
>>> "free" relay attacks I've disclosed clearly show that claiming RBFR 
>>> would 
>>> "allow" free relay is simply not true. 
>>>
>>> Notably, full-RBF is _itself_ a transaction pinning fix for many 
>>> use-cases; 
>>> part of the TRUC/V3 standard is to force full-RBF behavior for V3 
>>> transactions. 
>>> So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a 
>>> second 
>>> way, and TRUC/V3 proponents were the ones who tried to get the full-RBF 
>>> option 
>>> removed from Core in the first place. If not for this dumb bit of Core 
>>> politics, I'm sure my year-old pull-req to enable full-RBF by default 
>>> would 
>>> have been merged many months ago, as almost all hashpower has adopted 
>>> full-RBF 
>>> making objections based on "zeroconf" absurd. 
>>>
>>>
>>> # The Attack 
>>>
>>> If you're a competent Bitcoin engineer, familiar with how mempools work, 
>>> you've 
>>> probably figured it out already based on the title: obviously, if a high 
>>> percentage of miners are adopting a policy that Bitcoin Core nodes are 
>>> not, you 
>>> can cheaply consume transaction relay bandwidth by simply relaying 
>>> transations 
>>> that miners are rejecting. 
>>>
>>> Specifically, do the following: 
>>>
>>> 1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled. 
>>> 2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate. 
>>> 3. Spend the outputs of A in a large, low fee-rate, transaction B with 
>>> BIP-125 
>>> opt-in enabled. ~100% of miners will reject B, as it spends an input not 
>>> in 
>>> their mempools. However Bitcoin Core nodes will waste bandwidth 
>>> propagating 
>>> B. 
>>> 4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will 
>>> waste 
>>> bandwidth propagating Bn's that ~100% of miners are ignoring. 
>>> 5. Double-spend A2 to recover your funds and do it all over again (or if 
>>> A2 had 
>>> a high enough fee-rate, just wait for it to be mined). 
>>>
>>> The cost to relay each B transaction depends on the fee-rate of B. Since 
>>> Bitcoin Core defaults to a fairly large mempool, the minimum relay 
>>> fee-rate is 
>>> typically well below the economic fee-rate required for miners to 
>>> actually mine 
>>> a transaction; Core accepts transactions that are uneconomical for 
>>> miners to 
>>> mine for the forseeable future. 
>>>
>>> For example, at the moment typical mempools require transactions to pay 
>>> at 
>>> least 1sat/vB, while there are hundreds of MvB worth of transactions 
>>> paying 
>>> 4sat/vB, the minimum economical fee-rate. Thus, transactions paying less 
>>> than 
>>> 4sat/VB are extremely unlikely to get mined in the nearish future. 
>>>
>>> Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/vB 
>>> would 
>>> have almost zero cost as the probability of those transactions getting 
>>> mined is 
>>> nearly zero. This is true _regardless_ of what % of miners are mining 
>>> full-RBF! 
>>> As long as you can get at least one miner to mine the A double-spend, 
>>> the 
>>> attack only costs what it cost to get A mined. 
>>>
>>> If B's are broadcast at a higher fee-rate than the minimum economical 
>>> fee-rate, 
>>> then the % of full-RBF miners matters. For example, if only 99% of 
>>> miners mine 
>>> full-RBF, the chance of a B transaction getting mined per block is about 
>>> 1%, so 
>>> the amortized cost of broadcasting B is about 1% of whatever total fee 
>>> the 
>>> highest fee-rate variant of B pays. 
>>>
>>> For an attacker who does not need any B to be broadcast, the cost 
>>> savings to 
>>> use of relay bandwidth is approximately the ratio of the difference in 
>>> size 
>>> between B and and A. With a maximum standard transaction size of 100KvB, 
>>> or 
>>> 400KB serialized size, this ratio is on the order of 5000:1, times the 
>>> total 
>>> number of B variants broadcast, and the % chance of each B being mined; 
>>> it's a 
>>> few orders of magnitude. 
>>>
>>> Of course, as mentioned above, this is just one of *many* "free" relay 
>>> attacks, 
>>> so fixing this particular issue doesn't change much. 
>>>
>>>
>>> # Attackers Who Benefit From B Getting Mined 
>>>
>>> Some attackers actually need B to get mined. For example, imagine an 
>>> exchange 
>>> who needs to do large consolidation transactions. They could use this 
>>> attack 
>>> (and some attacks like it) as a way to goad users and miners into mining 
>>> consolidation transactions for them at low cost. In this variant of the 
>>> attack, 
>>> the attacker would pad the size of B with consolidation spends that they 
>>> needed 
>>> to do anyway. Someone who tried to stop the attack by getting B mined 
>>> (eg via 
>>> mempool.space's transaction accellerator) would simply be paying the 
>>> attacker's 
>>> fees for them. 
>>>
>>> Obviously, this strategy is only relevant for B's below the economic 
>>> fee-rate. 
>>> However, the weaker version of this strategy is to parallize the attack, 
>>> and do 
>>> your consolidation with the _A_ double-spends to reduce the # of bytes 
>>> used per 
>>> full-rbf double-spend. 
>>>
>>>
>>> # TRUC/V3 Creates a Free Relay Attack 
>>>
>>> I'll leave the details of this as a homework problem. But obviously, the 
>>> introduction of TRUC/V3 transactions *itself* creates a free relay 
>>> attack very 
>>> similar to the above! Just like full-RBF, not all miners will mine V3 
>>> transactions. So you can do the exact same type of attack by taking 
>>> advantage 
>>> of this difference in mining policy. 
>>>
>>> -- 
>>> https://petertodd.org 'peter'[:-1]@petertodd.org 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/fd1e1dd3-ffda-416b-9bc8-900d0b69c8c1n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 17942 bytes --]

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[David A. Harding]

On 2024-07-18 05:56, Peter Todd wrote:
> I disclosed it to the bitcoin-security mailing list as a test: does
> Bitcoin Core actually care about free relay attacks?

They do.  Several free relay attacks that were present in earlier
versions of Bitcoin were eliminated in later versions.  New proposals
are evaluated for their potential to create new permanent free relay
vectors.  The discovery of free relay is almost always reason enough to
reject a proposal.

The free relay attack you describe in your email and the type of free
relay enabled by your replace-by-feerate (RBFr) proposal can allow an
attacker to 10x to 100x the amount of bandwidth used network wide by
relay nodes for a cost of $10,000 to $50,000 a day (or, as you mention,
effectively for free if they were going to send a bunch of transactions
anyway).

I cannot imagine what would make you think that protocol developers are
not concerned about attacks that could drive large numbers of relay
nodes off the network for a cost easily affordable to any well-funded
adversary.

In this case, you've found a specific instance (full-RBF vs signaled
RBF) of a well-known general problem (optional policies leading to
mempool inconsistencies, allowing free relay) and appear to be arguing
that devs don't care about free relay because they refused to reverse a
previous decision (to not change the RBF configuration default) that has
been hotly debated multiple times.

An alternative interpretation is that they (1) do care about free relay,
(2) recognize that solving free relay is a hard problem that requires
research and development, and (3) refuse to be forced into restarting
debate on an already overdiscussed issue that gets nobody closer to
fundamental solutions.

> I believe the authors of that BIP are fully aware of the fact that
> "free" relay is an unavoidable problem, making their rational for
> TRUC/V3 bogus

Differences in node policy leading to mempool inconsistencies (which
allows free relay) is a well known problem that's the result of Bitcoin
being an open protocol based on free/libre software (two things I think
we all want).  Many protocol developers have attempted to address the
problem over the years, most recently just a few months ago with an
updated proposal for using weak blocks as a first step to address
"diverging mempool policies".[1]

A currently unsolved problem is not necessarily an unavoidable problem
and it seems reasonable to me for devs to be skeptical of proposals like
RBFr that add to the list of things that enable free relay.

> I believe the authors of [BIP431...] don't want to admit that they've
> wasted a large amount of engineering time on a bad proposal.

You've previously argued against designing contract protocols to depend
CPFP-style fee bumping for their offchain transactions, however that is
what is widely used by LN today and it appears to be what LN and other
offchain protocol developers want to use in the future.  If we accept
that, at least for the purposes of argument, what can we do to improve
CPFP fee bumping for LN?

All we really need at this point is to enable package relay so that
parent transactions are no longer subject to a dynamic mempool minimum
when they're bundled with a high-feerate child.  Preliminary support for
that should be released in the next major version of Bitcoin Core, with
improved support being worked on for later releases.

Package relay is the only thing we need at this point because the
existing LN protocol makes use of CPFP carve-out, which minimizes
transaction pinning issues.

However, another substantial Bitcoin Core improvement, cluster mempool,
is incompatible with CPFP carve-out.  TRUC is an alternative to CPFP
carve-out that is easy to reason about, easy to use, more general in
nature (good news for newer contract protocols), and which can possibly
be automatically applied to existing LN onchain transactions, allowing
cluster mempool to be deployed ASAP without requiring any significant
changes to anyone else's software.

As you've shown[2], the main downside of TRUC transactions (if we're
going to depend on CPFP-style fee bumping anyway) is that users of TRUC
transactions who have a malicious counterparty might need to pay a
slightly higher onchain feerate than they would need to pay under the
same situation with CPFP carve-out.  However, the increase is small
enough that most honest parties should be able to afford it, so there's
no incentive for a counterparty to do it.  I don't think we need to be
overly concerned about large numbers of LN users suddenly performing a
malicious action that does not benefit them and does not put the network
at risk.

The alternative to TRUC that you've proposed is replace-by-feerate
(RBFr).  This is also compatible with existing LN transactions and it's
conceptually super simple (I assume the code is too), which is
wonderful.  However, it's downsides are:

1. It fundamentally enables a significant amount of free relay.  I'll
    sketch a super basic attack at the end of this email that costs 0.55
    BTC per day ($67,000 USD) to 100x the amount of bandwidth used by
    relay nodes.  I'm sure more efficient attacks are possible.

    An attacker who is able to consume an excessive amount of relay node
    bandwidth at relatively low cost may be able to create both
    short-term and long-term problems for all Bitcoin users.  If the
    created problems result in a rapid increase in user feerates, then
    free relay attacks become cheaper due to low feerate transactions
    being automatically evicted from the bottom of the mempool.

2. It may allow empting the mempool at relatively low cost.  An attacker
    sending just 750 transactions at the top mempool feerate can
    guarantee eviction of every honest user's transactions.  The attacker
    can then replace 300 MB of transactions with a single 43,179 vbyte
    transaction.  Even if the replacement transaction pays 100
    sats/vbyte, when you compare that to the 1,000,000 vbytes of
    next-block transactions each miner lost, the miner is only earning an
    effective feerate of 4.3 sats/vbyte.

    Further, it's easy to imagine situations where evicting
    time-sensitive transactions from mempools might allow theft of funds
    in excess of a few thousand dollars (my immediate thoughts go to
    situations involving watchtowers).

3. Limiting the worst-case free relay and excessive mempool eviction
    requires additional rules (e.g. one-shot RBFr) that are challenging
    to implement and analyze at present, as several devs have noted[3].
    Both implementation and analysis should become much easier if cluster
    mempool is deployed (also noted by devs), but the deployment of
    cluster mempool requires removal of CPFP carve-out, and removal of
    CPFP carve-out requires either the upgrade of thousands of LN nodes
    and channels or a drop-in solution (ideally one that can be analyzed
    independently from cluster mempool, like TRUC).

To me, TRUC seems like an excellent approach.  It's something that can
be evaluated independently of cluster mempool but which can help allow
that deployment to proceed (in addition to the other previously
described benefits that TRUC brings).

There have already been multiple public discussions about how improved
RBF policies can be implemented once cluster mempool is available, many
of which bring us closer to something like RBFr in a way that's easier
to prove won't enable free relay, and perusing that seems to me like a
productive outlet if you are interested.

> this is quite an odd case of Core politics

I began writing this reply to force me to examine your claims for
myself.  You have a long history of noticing things other people missed.
I was worried that some compelling point of yours was being ignored as
the result of past controversies.

After several hours of writing and thinking, I don't see any problems
with the current approach using TRUC or with the general lack of
interest in RBFr solutions at this time.  I've tried to explain how I
arrived at my conclusions at each step and I welcome any corrections.

Thanks,

-Dave

[1] https://delvingbitcoin.org/t/second-look-at-weak-blocks/805
[2] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022211.html
[3] 
https://bitcoinops.org/en/newsletters/2024/02/07/#proposal-for-replace-by-feerate-to-escape-pinning

---
A simple free relay attack using RBFr

## Constants

100,000 vbytes == ~400,000 bytes
   A 1-input, 1-output P2TR scriptpath spend with the maximum amount
   of witness data allowed by Bitcoin Core defaults

111 vbytes == 162 bytes
   A 1-input, 1-output P2TR keypath spend

## Attack

- Attacker obtains 500,000 UTXOs

- For each UTXO

   - At the dynamic mempool minimum, broadcasts a 100,000 vbyte (400,000
     byte) transacton.

   - Waits for it to propagate.

   - At 1.25x the dynamic mempool minimum, broadcasts a RBFr replacement
     that is 111 vbytes (162 bytes).

## Analysis

- At 162 bytes each, 500,000 transactions is 81 MB.  I think that will
   fit in a default-sized mempool.

- The total amount of transaction data relayed is 500_000 * (400_000 +
   162), or about 200 GB.

- The typical daily bandwidth requirement of a blocks-only node is
   roughly 2.5 MB * 144, or about 0.36 GB per day.  Ideally a relaying
   node is about the same due to compact blocks, but realistically, it's
   a small multiple of that.  Call it 2 GB per day.

   - This implies the attack push each RBFr relay node to use 100x a
     non-RBFr relay node.

- At 111 vbytes each, 500,000 transactions is 55.5 million vbytes.  At
   my nodes current mempoolminfee (1 sat/vb), that's 55.5 million sats,
   or 0.55 BTC (about $37,000 USD).

- This analysis ignores the cost of obtaining the UTXOs and possibly
   later consolidating them, but it also ignores some easy optimizations
   such as batching the replacements.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/c6593662694f9d4a4fe999dd432f87ff%40dtrt.org.

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1866 bytes --]

On Fri, Jul 19, 2024 at 02:26:44PM -0400, Murch wrote:
> On 7/18/24 11:56, Peter Todd wrote:
> > # Summary
> > 
> > This is a public disclosure of a vulnerability that I previously disclosed to
> > the bitcoin-security mailing list.
> 
> It seems redundant to point out that some transactions are only relayed by a
> subset of a node population if there are multiple diverging mempool policies
> with significant adoption.

1) So you agree with me in general that this is just one of a large class of
"free" relay attacks?

2) You should re-read my analysis. You do _not_ need significant adoption of
the diverging mempool policy for this attack to work. Literally a single miner
is sufficient.

Indeed, as I pointed out one month ago on this mailing list, a "free" relay
"attack" was happening by accident due to good samaritans attemping to spend
Lightning anchor outputs to clean up the UTXO set, accidentally pinning
Lightning nodes in the process, and the fact that Libre Relay's RBFR was
already sufficent to get the intended transactions mined:

"Libre Relay v27.1 released with lower 1.25x replacement threshold" - Jun 20th 2024
https://groups.google.com/g/bitcoindev/c/n2GNmnz0btw/m/IemUVKBoAgAJ

> However, I concur that Bitcoin Core should match its default setting for
> `mempoolfullrbf` to the behavior of miners, and there appears to be palpable
> evidence that a supermajority of the hashrate has enabled `mempoolfullrbf`.

Thanks!

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZpvFaRDoNbzSOgIq%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 5133 bytes --]

On Fri, Jul 19, 2024 at 08:41:07PM -1000, David A. Harding wrote:
> On 2024-07-18 05:56, Peter Todd wrote:
> > I disclosed it to the bitcoin-security mailing list as a test: does
> > Bitcoin Core actually care about free relay attacks?
> 
> They do.  Several free relay attacks that were present in earlier
> versions of Bitcoin were eliminated in later versions.

I can think of two such eliminated attacks, both significantly more "free" than
anything we're discussing here, and interestingly, both attacks that I
participated in discovering or fixing:

1) The fact that non-final transactions were accepted into the mempool, even if
   they wouldn't be valid for thousands of years (IIRC I exploited the
   mempool.space mixer with this).

2) nSequence replacement, which replace-by-fee ultimately fixed.

What other "free" relay attacks can you think of that were fixed?

> New proposals
> are evaluated for their potential to create new permanent free relay
> vectors.  The discovery of free relay is almost always reason enough to
> reject a proposal.

Yet even though Murch (I think quite accurately) said that the full-rbf "free"
relay attack was a fairly obvious attack, my pull-req to enable it sat for over
a year without any comment from Core... Surely, if Core was genuinely concerned
about these attacks, Core would rush to quietly fix them; we could have shipped
full-RBF by default something like six months ago.

And in spite of this apparent concern about "free" relay, I don't see anyone
trying to mitigate the "free" relay attack that the introduction of TRUC/V3
transactions will cause.

It's also notable that Core *introduced* a new form of "free" relay a few years
back with mempool expiration.

> The free relay attack you describe in your email and the type of free
> relay enabled by your replace-by-feerate (RBFr) proposal can allow an
> attacker to 10x to 100x the amount of bandwidth used network wide by
> relay nodes for a cost of $10,000 to $50,000 a day (or, as you mention,
> effectively for free if they were going to send a bunch of transactions
> anyway).

Did you actually read my One-Shot RBFR proposal? I covered DoS attacks:

https://petertodd.org/2024/one-shot-replace-by-fee-rate#denial-of-service-attacks

The *status quo* is that free relay attacks are unavoidable, because, at
minimum, you can always pull them off by simultaneous broadcast of
contradictory transactions (especially if you, eg, need to do consolidation
transactions anyway). RBFR does not change that.

> I cannot imagine what would make you think that protocol developers are
> not concerned about attacks that could drive large numbers of relay
> nodes off the network for a cost easily affordable to any well-funded
> adversary.
> 
> In this case, you've found a specific instance (full-RBF vs signaled
> RBF) of a well-known general problem (optional policies leading to
> mempool inconsistencies, allowing free relay) and appear to be arguing
> that devs don't care about free relay because they refused to reverse a
> previous decision (to not change the RBF configuration default) that has
> been hotly debated multiple times.

...and your point is? Are you saying that Core developers put politics above
security, by refusing to fix a known "free" relay attack simply because it was
"hotly debated"?

> > I believe the authors of that BIP are fully aware of the fact that
> > "free" relay is an unavoidable problem, making their rational for
> > TRUC/V3 bogus
> 
> Differences in node policy leading to mempool inconsistencies (which
> allows free relay) is a well known problem that's the result of Bitcoin
> being an open protocol based on free/libre software (two things I think
> we all want).  Many protocol developers have attempted to address the
> problem over the years, most recently just a few months ago with an
> updated proposal for using weak blocks as a first step to address
> "diverging mempool policies".[1]

Weak blocks are not a solution to any of the "free" relay attacks I've
disclosed, and your source, https://delvingbitcoin.org/t/second-look-at-weak-blocks/805,
does not claim that they are a "free" relay solution.

Weak blocks simply aren't relevant until a miner has received a transaction and
found a weak block. By that point the "free" relay has already happened.


Anyway, before I spend time replying to the rest of your email, I think it'd be
helpful if you confirm two things to make sure we're actually on the same page:

1) Have you've read my One Shot RBFR proposal? In particular, my analysis of
   DoS attacks *including* existing DoS attacks like simultaneous broadcast.

2) Do you agree or disagree with me that these existing DoS attacks are real?

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZpvRvRybauFFnhQV%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1763 bytes --]

On Fri, Jul 19, 2024 at 10:57:40PM -0700, /dev /fd0 wrote:
> Hi Antoine,
> 
> >  I'm interested if you can propose a formal or mathematical definition of 
> what constitute
> > an in-topic of off-topic comments on a matters like full RBF, which has 
> been controversial
> > for like a decade.
> 
> I will quote _willcl-ark_'s last comment as I do not have enough 
> permissions in bitcoin core repository to moderate comments:
> 
> "However the comments section here has become difficult to follow due to 
> numerous off-topic comments, a few personal disagreements, and repetition 
> of arguments. In the interest of having a more productive and focused 
> technical and philosophical discussion we are going to close and lock this 
> PR."
> 
> A new pull request should help reviewers. If you do not agree with it, feel 
> free to discuss it with moderators in bitcoin core IRC channel.

It's quite bizzare to use "off topic comments" as an excuse to close a pull-req
fixing a specific security vulnerability, assuming you actually care about that
vulnerability. As I've said elsewhere, Core could have easily and quietly
merged that pull-req as-is, possibly by having a few people write some obvious
ACK rationals.

The only good explanation for closing it is to further delay merging the
pull-req, as well as disclosing the vulnerability.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZpvS2haduzUQiojV%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]

On Sat, Jul 20, 2024 at 03:03:25PM +0000, Peter Todd wrote:
> 1) The fact that non-final transactions were accepted into the mempool, even if
>    they wouldn't be valid for thousands of years (IIRC I exploited the
>    mempool.space mixer with this).

Brainfart! I mean, the blockchain.info space mixer obviously.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZpvYJPB0B0aHczab%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 5883 bytes --]

Hi Ava,

Thanks for the answer and the additional information.

I think this is unclear to me if Peter himself was part of the discussion
amongst several members of the security list on re-examining if their 
presence
and the ones of others was still worthy on the list, be it online or 
offline.

I fully understrand this is a kind of conversation which certainly does not
warrant to be public, and I mostly agree with that. Yet I believe it's 
ethically
bordeline to not invite someome to express its own viewpoint in asking to be
removal of its own access, especially in a project that aims to be 
decentralized
and a technnical meritocracy (-- I believe an ideal we aspire all).

Beyond, and forgive the expression if it's a bit rude, I believe it's a bit 
"naive",
"short-sighted" as a position of the members of the security list, with 
whatever
level of true consensus such removal has being done (-- and I'm not aware 
there
was operational security emergency that justified such removal).

"Naive", as saying this is the _Bitcoin Core_ project list only can only 
provoke blind
spot among the list members if the security issues are either affecting old 
part of
the codebases that younger members have less experiences with (some parts 
like consensus
or block-relay are modified only every 5 years) or novel factors from 
upstream or downstream
(e.g the internet networking stack or implications on deployed contract 
protocols like
lightning). On both the former and latter criterias, I think Peter overly 
meets the bar.

"Short-sighted", as it's making the members of the security list both party 
and arbiter
of appreciating what is an _active_ contributor among themselves (all in a 
very ethically
bordeline fashion). In my experience with lightning over the past years, 
with discovering
more and more issues which in fact that arises from imperfect interfacting 
with the base-layer,
I was progressively lead to spend more and more time on the core side as it 
was natural to
have things fixed thhere (or at least advocate so). Of course, I was in 
consequence less active
on the lighting development day-to-day side. Did it make be less competent 
to be responsive when
issues affected lighting ? I don't believe so (though obviously I'll let 
other lightning experts
corroborate or infirm this self-cogtratulory statement of mine).

Same for Peter, if he had make the choices to consencrate its open-source 
time on more long-term
things like transaction denial-of-service vectors or analyzing new 
consensus changes proposals
(whatever the long-erm outcome, R&D is a stochastic process -- his track 
records with things like
bip65 shall give him a positive presumption)

I think as a community to give such cultural margin to do so, even if it's 
as the trade-off of
less review on day-to-day core things with a more reduced global scope like 
the gui or the wallet.

When you've big sh*t hitting the fan like inflation bugs or level DB 2013 
unexpected fork you
prefer have experts with a decade of experience to collaborate with, and 
sharing the same cultural
and ethical norms of the active contributors evaluated by numbers on 
commits on the last single-digit
years.

I'll repropose Peter admission on the security list mailing list in the 
coming weeks by opening an
issue on the bitcoin-meta repository, once this current mailing list thread 
has slowed down a bit,
or at least the technical analysis has been dissociated from the 
proceedings which have all been
bundle in a big message. In my very personal opinion, I still trust more 
Peter competence and experience
than some other people I know who are on the security mailing list.

All that said I appreciate your answer and I'm satisfied from the personal 
role you've have played
in the matter with, and be reassured I'll keep you among the recipient of 
future security issues with
a potential impact on bitcoin core that I might find or be aware off.

Best,
Antoine
ots hash: db441b51684ad3a6897f67d42c74ccfcb9a4ffed40d4bdbe30a2edd867ccdd54

Le samedi 20 juillet 2024 à 01:50:25 UTC+1, Ava Chow a écrit :

> On 07/19/2024 07:58 PM, Antoine Riard wrote:
> > As said in one my previous email, I'm still curious about achow101 
> > explaining publicly
> > why you have been kicked-out of the bitcoin-security mailing list, when 
> > you were certainly
> > more senior than achow101 in matters of base-layer security issues or 
> > even hard technical
> > issues like consensus interactions (e.g bip65). I'll re-iterate my 
> > respect towards achow101
> > as a maintainer from years of collaboration, though this is a topic 
> > worthy of an answer.
>
> I am not the one that removed Peter from the mailing list, nor do I even 
> have the login(s) to do so.
>
> There was a discussion amongst several members of the security list 
> about who was on the list, and who should be on the list. Given that the 
> security list is the _Bitcoin Core_ security list, we determined that 
> the people who should be on the list are people who still actively 
> contribute to the project. As Peter Todd no longer actively contribute 
> code nor code review to the project, we decided that it didn't make 
> sense to continue to have him on the list.
>
> My recollection is that multiple other people were removed from the list 
> for the same reason at the same time.
>
> Ava
>
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 6638 bytes --]

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 25607 bytes --]


Hi Dave,

Thanks for your thoughtful answer (even if its wasn't addressed to me 
primarly).

> I cannot imagine what would make you think that protocol developers are
> not concerned about attacks that could drive large numbers of relay
> nodes off the network for a cost easily affordable to any well-funded
> adversary.

From my experience code reviewing the wallet / mempool re-broadcast of few
years ago, free tx-relay / bandwidth waste attacks were far to be 
understood 
or plainly weighted by some contributors of a newer generations, including 
by
the own champion of the proposal. The proposal was finally abandonned when a
more senior dev came up with quantitative analysis of code changes [0].

[0] https://github.com/bitcoin/bitcoin/pull/21061#issuecomment-851563105

> In this case, you've found a specific instance (full-RBF vs signaled
> RBF) of a well-known general problem (optional policies leading to
> mempool inconsistencies, allowing free relay) and appear to be arguing
> that devs don't care about free relay because they refused to reverse a
> previous decision (to not change the RBF configuration default) that has
> been hotly debated multiple times.

I think what is more interesting and noteworhty in the whole line of 
reaosning
of Peter with the present disclosure is how much the adversial effect is 
favor
by the supermajority of miners running `mempoolfullrbf` [1].

[1] https://github.com/bitcoin/bitcoin/pull/28132#issue-1817178316

That Peter's sample calls for empirical measures of their own by other 
contributors 
that can only make the whole review process and consensus-building towards 
a change
or the status quo better. Being able to empirically measure how bitcoin 
full-node
software is practically used by end-users, be it miners, second-layers 
nodes, simple
coins wallet users, exchanges, and making that a protocol development 
standard I believe
that how we progress as an ecosystem.

> An alternative interpretation is that they (1) do care about free relay,
> (2) recognize that solving free relay is a hard problem that requires
> research and development, and (3) refuse to be forced into restarting
> debate on an already overdiscussed issue that gets nobody closer to
> fundamental solutions.

The strong statement we have from the bitcoin core about attacks and 
vulnerabilities
mitigation, which probably represents the viewpoint of many generation of
contributors is the following as old than few weeks ago:

"The project has historically done a poor job at publicly disclosing 
security-critical bugs,
whether externally reported or found by contributors. This has led to a 
situation where a lot
of users perceive Bitcoin Core as never having bugs. This perception is 
dangerous and, 
unfortunately, not accurate."

[2] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w

Under those conditions, where it took 9 years for the bitcoin core project 
to disclosre
some vulnerabilitires, personally I'm more likely to understand that the 
bitcoin core project
is under-staffed is competent experts to keep public disclosure in 
reasonable timeframe (-- at
least equivalent to the kernel world), and as corollorary to fully evaluate 
technical proposal
with all its strength and weaknesses.

Saying an "already overdiscussed issues that gets nobody closer to 
fundamental solutions" is
insulting for Peter, honestly.

> Many protocol developers have attempted to address the problem over the 
years, most recently just
> a few months ago with an updated proposal for using weak blocks as a 
first step to address
> "diverging mempool policies".[1]

With all my respect for the developers involved in the design of this 
proposal who are skilled bitcoin
engineers in themsleves, I think betting on the "weak blocks" idea is a 
dead end in itself as in relying
on the slow convergence idea, that it's at the heart of the ghost, block 
dag and other ideas we've seen
10 years ago to make mining income "more fair" among geographically 
distributed mining pools.

I conjecture, it's a dead end as you will more or less have to re-build a 
secondary consensus algorithm
in the block-relay stack or in the mining stack, which is going to run 
intou its own mempool convergence
issues again, in a recursive fashion.

I believe such proposal is more an instance of the ill-managed conflict of 
interest blockstream-style
syndrom that bitcoin protocol devs, who ever they care can be affected 
with. In the present instance:

"My employer has gained a commercial interest in mining business recently 
so now let's advocate a very
complex bitcoin p2p protocol changes, rather than humbly realize that 
mining economic units are more akin
to a traditional energy company which not really in the less than 2-decades 
corporate DNA of said employer,
and why actually the economic units results of our mining division are 
floppy and now we engage in bitcoin
core changes at our advantage" (in my own reasonable view -- though I can 
only invite the "weak block" employer
company corporate board to comment here if they diverge on my analysis).

From a more pure technical viewpoint, I think bitcoin core compact blocks 
block-relay handling code, after
7 years of having been merged in bitcoin core has still `TODO` left in the 
codebase, and it could be an area
worhty of more testing / cleaning refactoring, I'm just saying by the way.

> You've previously argued against designing contract protocols to depend 
> CPFP-style fee bumping for their offchain transactions, however that is 
> what is widely used by LN today and it appears to be what LN and other 
> offchain protocol developers want to use in the future. If we accept 
> that, at least for the purposes of argument, what can we do to improve 
> CPFP fee bumping for LN? 

As an offchain protocol developers which has been involved in the majority 
of technical conversations,
implementations and deployment of the "anchor output" upgrade, I believe on 
the long-term CPFP-style fee-bumping
of contract protocol, including lighting, is not the most robust technical 
solutions. I think anyone can check
in the bitcoin optech anchor output glossary the numerous vulnerabilities 
that have plagued this fee-bumping 
solutions over the past years.

Pursuing on that trend will more only probably lead to a current state of 
what we have with DNS / BGP at the
internet-stack level, which are still constantly the sources of new 
security vulnerabilitiies and single-point
of-failure securiyt solutions like X509 certificates management (do we wish 
bitcoin to be plagued by crowdstyle
technical incident 15 years from now ? I'm not so sure).

> All we really need at this point is to enable package relay so that 
> parent transactions are no longer subject to a dynamic mempool minimum 
> when they're bundled with a high-feerate child. Preliminary support for 
> that should be released in the next major version of Bitcoin Core, with 
> improved support being worked on for later releases. 
> 
> Package relay is the only thing we need at this point because the 
> existing LN protocol makes use of CPFP carve-out, which minimizes 
> transaction pinning issues. 

I don't disagree on package relay deployment at this stage, with the some 
degree of technical skeptiscism
that shall accomaphny all p2p proposals. Let's remember things that have 
been rollback or slowly rollout like
bip37 or `MEMPOOL` p2p message.

> However, another substantial Bitcoin Core improvement, cluster mempool, 
> is incompatible with CPFP carve-out. TRUC is an alternative to CPFP 
> carve-out that is easy to reason about, easy to use, more general in 
> nature (good news for newer contract protocols), and which can possibly 
> be automatically applied to existing LN onchain transactions, allowing 
> cluster mempool to be deployed ASAP without requiring any significant 
> changes to anyone else's software. 

If you or anoyone think TRUC as an alternative to the CPFP as a transsction 
pinning mitigation as argued
in its merged BIP is easy to reason on, thanks to communicate your 
lightning node pubkey, with TRUC patch
applied and a GPG-signed message authorizing me to demonstrate the security 
properties of this solutions have
not been submitted to a fully contradictory evaluation.

I pointed out few years ago that relying on mempool-policy changes as a 
fully hardening solution was very
likely limited to mitigate econommical-based pinnings (i.e bip125 absolute 
fee rule), and this was before
the discovery of new transaction-relay jamming vector (a terminology 
catched by your himself in some
private conversation if my memory is correct) like replacement cycling 
attacks [4].

[4] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019084.html 
"high-half" in this post
corresponds to what roughly is bip331 today.

> I don't think we need to be overly concerned about large numbers of LN 
users suddenly performing a malicious
> action that does not benefit them and does not put the network at risk.

Have a look on base-layer based exploitation description that could provoke 
a large number of LN users, without
their own involvement, that could put the base-network at risk [5].

[5] 
https://github.com/jamesob/mempool.work?tab=readme-ov-file#failure-one-mempool-to-rule-them-all

> The alternative to TRUC that you've proposed is replace-by-feerate 
> (RBFr). This is also compatible with existing LN transactions and it's 
> conceptually super simple (I assume the code is too), which is 
> wonderful. However, it's downsides are: 

About replace-by-feerate, I think it's a solution that have downside on its 
own, especially for
second-layers like lightning. I never took time to write a canonical post 
as infosec ethics would ask
me to notice lightning maininters to do first, even if the vulnerability 
idea has been vaguely sketched
out to few years ago.

On all your replace-by-feerate analysis, I think it deserves a thread on 
its own, as somehow the issue
can have interactions with degree of fulfillness of miner block templates, 
a conversation we had when V3
was proposed as solution [6].

[6] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html 
and following answers

> but the deployment of cluster mempool requires removal of CPFP carve-out, 
and removal of CPFP carve-out requires
> either the upgrade of thousands of LN nodes and channels or a drop-in 
solution (ideally one that can be analyzed 
> independently from cluster mempool, like TRUC)

And as I observed on one of the V3 PR threads and corresponding 
conversations, the CPFP carve-out do not provide
security to lightning implementation as (a) old revoked commitment 
transactions can be used to fail the CPFP bump,
V3 or not V3 and (b) there is no base-layer p2p protocol discovery of txids 
[6]. And I won't observe that when I looked
on lightning implementations code, only Eclair have minimal correct 
implementation of remote valid commitment transactions
broadcast, not the other one as it's not even in the bolt spec.

[6] https://github.com/bitcoin/bitcoin/pull/28948

So unless someone argued to the contrary, saying TRUC was needed to then 
deploy cluster mempool is an intellectual
fallacy, of which the origin could likely arises from the back macket of PR 
reviews trading happening in the bitcoin core
project for people to advance their own pet projects. At the very least, 
from my own code review of the folks bitcoin
core PR related to this line of deployment you're exposing, I'm not sure 
they're understanding so well cross-layers issues [7].

[7] https://github.com/bitcoin/bitcoin/pull/29427

I think you're rather making the points that the current group of most 
active bitcoin core contributors, are indeed
skilled bitcoin engineers, vetted with project-management know-how and 
informed about bitcoin technical history and know
how to stay polite and civil (most of the time) to create a fruitful 
technical conversation atmosphere. They're not necessarily
the most astute and adversarial minds to spot on the flight the weakness of 
new technical proposals, neither with the character
to say so _at the cost_ of sometimes being rude and negative in the 
communication tone. And this in line with my point above
recalling that the bitcoin core group of people themselves estimate 
themsleves they don't do a good job in term of security
vulnerabilties handling.

> There have already been multiple public discussions about how improved 
> RBF policies can be implemented once cluster mempool is available, many 
> of which bring us closer to something like RBFr in a way that's easier 
> to prove won't enable free relay, and perusing that seems to me like a 
> productive outlet if you are interested. 

I already reviewed some parts of cluster mempool. Fundamentally, economical 
mempool pinnings for second-layers (bip125 absolute
fee) with pre-signed time-sensitive transactions arises from a world where 
there is (a) an asynchronicity of mempools and (b) one
cannot guess feerates at block + 1 (-- let's say in a deterministic fashion 
as understood by traditional cryptographic litterature
when doing cryptanalysis). Better RBF policies won't solve that, including 
RBFr.

> After several hours of writing and thinking, I don't see any problems
> with the current approach using TRUC or with the general lack of
> interest in RBFr solutions at this time. I've tried to explain how I
> arrived at my conclusions at each step and I welcome any corrections.

On my personal perspective, and after careful considerations of all the 
technical points you've raised. I still think TRUC
has a lot of problems. RBRFr too has technical problems. About TRUC I think 
it's an acceptable temporary solution to minimize
the pinning surface of lightning implementations, pending for the design of 
a better solution (more likely at the consensus-level,
here consistently as I pointed out 3 years ago). Though we shall be honest 
with ourselves and not engage in overdue security theater
about TRUC properties.

To finish, I'll re-assert what is my appreciation. Currently, I don't think 
the bitcoin core folks handling the security list has
necessarily the proven level of competency to fully evaluate the issues 
reported by Peter, however I don't believe in the present
case they have done anything wrong infosec ethically-wise.

Best,
Antoine
ots hash: 001e8dc7fbced4cb9ea30c8a3b7fa22dc1b07939e7125cb46e7a3d65b256caa7

Le samedi 20 juillet 2024 à 07:45:24 UTC+1, David A. Harding a écrit :

> On 2024-07-18 05:56, Peter Todd wrote:
> > I disclosed it to the bitcoin-security mailing list as a test: does
> > Bitcoin Core actually care about free relay attacks?
>
> They do. Several free relay attacks that were present in earlier
> versions of Bitcoin were eliminated in later versions. New proposals
> are evaluated for their potential to create new permanent free relay
> vectors. The discovery of free relay is almost always reason enough to
> reject a proposal.
>
> The free relay attack you describe in your email and the type of free
> relay enabled by your replace-by-feerate (RBFr) proposal can allow an
> attacker to 10x to 100x the amount of bandwidth used network wide by
> relay nodes for a cost of $10,000 to $50,000 a day (or, as you mention,
> effectively for free if they were going to send a bunch of transactions
> anyway).
>
> I cannot imagine what would make you think that protocol developers are
> not concerned about attacks that could drive large numbers of relay
> nodes off the network for a cost easily affordable to any well-funded
> adversary.
>
> In this case, you've found a specific instance (full-RBF vs signaled
> RBF) of a well-known general problem (optional policies leading to
> mempool inconsistencies, allowing free relay) and appear to be arguing
> that devs don't care about free relay because they refused to reverse a
> previous decision (to not change the RBF configuration default) that has
> been hotly debated multiple times.
>
> An alternative interpretation is that they (1) do care about free relay,
> (2) recognize that solving free relay is a hard problem that requires
> research and development, and (3) refuse to be forced into restarting
> debate on an already overdiscussed issue that gets nobody closer to
> fundamental solutions.
>
> > I believe the authors of that BIP are fully aware of the fact that
> > "free" relay is an unavoidable problem, making their rational for
> > TRUC/V3 bogus
>
> Differences in node policy leading to mempool inconsistencies (which
> allows free relay) is a well known problem that's the result of Bitcoin
> being an open protocol based on free/libre software (two things I think
> we all want). Many protocol developers have attempted to address the
> problem over the years, most recently just a few months ago with an
> updated proposal for using weak blocks as a first step to address
> "diverging mempool policies".[1]
>
> A currently unsolved problem is not necessarily an unavoidable problem
> and it seems reasonable to me for devs to be skeptical of proposals like
> RBFr that add to the list of things that enable free relay.
>
> > I believe the authors of [BIP431...] don't want to admit that they've
> > wasted a large amount of engineering time on a bad proposal.
>
> You've previously argued against designing contract protocols to depend
> CPFP-style fee bumping for their offchain transactions, however that is
> what is widely used by LN today and it appears to be what LN and other
> offchain protocol developers want to use in the future. If we accept
> that, at least for the purposes of argument, what can we do to improve
> CPFP fee bumping for LN?
>
> All we really need at this point is to enable package relay so that
> parent transactions are no longer subject to a dynamic mempool minimum
> when they're bundled with a high-feerate child. Preliminary support for
> that should be released in the next major version of Bitcoin Core, with
> improved support being worked on for later releases.
>
> Package relay is the only thing we need at this point because the
> existing LN protocol makes use of CPFP carve-out, which minimizes
> transaction pinning issues.
>
> However, another substantial Bitcoin Core improvement, cluster mempool,
> is incompatible with CPFP carve-out. TRUC is an alternative to CPFP
> carve-out that is easy to reason about, easy to use, more general in
> nature (good news for newer contract protocols), and which can possibly
> be automatically applied to existing LN onchain transactions, allowing
> cluster mempool to be deployed ASAP without requiring any significant
> changes to anyone else's software.
>
> As you've shown[2], the main downside of TRUC transactions (if we're
> going to depend on CPFP-style fee bumping anyway) is that users of TRUC
> transactions who have a malicious counterparty might need to pay a
> slightly higher onchain feerate than they would need to pay under the
> same situation with CPFP carve-out. However, the increase is small
> enough that most honest parties should be able to afford it, so there's
> no incentive for a counterparty to do it. I don't think we need to be
> overly concerned about large numbers of LN users suddenly performing a
> malicious action that does not benefit them and does not put the network
> at risk.
>
> The alternative to TRUC that you've proposed is replace-by-feerate
> (RBFr). This is also compatible with existing LN transactions and it's
> conceptually super simple (I assume the code is too), which is
> wonderful. However, it's downsides are:
>
> 1. It fundamentally enables a significant amount of free relay. I'll
> sketch a super basic attack at the end of this email that costs 0.55
> BTC per day ($67,000 USD) to 100x the amount of bandwidth used by
> relay nodes. I'm sure more efficient attacks are possible.
>
> An attacker who is able to consume an excessive amount of relay node
> bandwidth at relatively low cost may be able to create both
> short-term and long-term problems for all Bitcoin users. If the
> created problems result in a rapid increase in user feerates, then
> free relay attacks become cheaper due to low feerate transactions
> being automatically evicted from the bottom of the mempool.
>
> 2. It may allow empting the mempool at relatively low cost. An attacker
> sending just 750 transactions at the top mempool feerate can
> guarantee eviction of every honest user's transactions. The attacker
> can then replace 300 MB of transactions with a single 43,179 vbyte
> transaction. Even if the replacement transaction pays 100
> sats/vbyte, when you compare that to the 1,000,000 vbytes of
> next-block transactions each miner lost, the miner is only earning an
> effective feerate of 4.3 sats/vbyte.
>
> Further, it's easy to imagine situations where evicting
> time-sensitive transactions from mempools might allow theft of funds
> in excess of a few thousand dollars (my immediate thoughts go to
> situations involving watchtowers).
>
> 3. Limiting the worst-case free relay and excessive mempool eviction
> requires additional rules (e.g. one-shot RBFr) that are challenging
> to implement and analyze at present, as several devs have noted[3].
> Both implementation and analysis should become much easier if cluster
> mempool is deployed (also noted by devs), but the deployment of
> cluster mempool requires removal of CPFP carve-out, and removal of
> CPFP carve-out requires either the upgrade of thousands of LN nodes
> and channels or a drop-in solution (ideally one that can be analyzed
> independently from cluster mempool, like TRUC).
>
> To me, TRUC seems like an excellent approach. It's something that can
> be evaluated independently of cluster mempool but which can help allow
> that deployment to proceed (in addition to the other previously
> described benefits that TRUC brings).
>
> There have already been multiple public discussions about how improved
> RBF policies can be implemented once cluster mempool is available, many
> of which bring us closer to something like RBFr in a way that's easier
> to prove won't enable free relay, and perusing that seems to me like a
> productive outlet if you are interested.
>
> > this is quite an odd case of Core politics
>
> I began writing this reply to force me to examine your claims for
> myself. You have a long history of noticing things other people missed.
> I was worried that some compelling point of yours was being ignored as
> the result of past controversies.
>
> After several hours of writing and thinking, I don't see any problems
> with the current approach using TRUC or with the general lack of
> interest in RBFr solutions at this time. I've tried to explain how I
> arrived at my conclusions at each step and I welcome any corrections.
>
> Thanks,
>
> -Dave
>
> [1] https://delvingbitcoin.org/t/second-look-at-weak-blocks/805
> [2] 
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-December/022211.html
> [3] 
>
> https://bitcoinops.org/en/newsletters/2024/02/07/#proposal-for-replace-by-feerate-to-escape-pinning
>
> ---
> A simple free relay attack using RBFr
>
> ## Constants
>
> 100,000 vbytes == ~400,000 bytes
> A 1-input, 1-output P2TR scriptpath spend with the maximum amount
> of witness data allowed by Bitcoin Core defaults
>
> 111 vbytes == 162 bytes
> A 1-input, 1-output P2TR keypath spend
>
> ## Attack
>
> - Attacker obtains 500,000 UTXOs
>
> - For each UTXO
>
> - At the dynamic mempool minimum, broadcasts a 100,000 vbyte (400,000
> byte) transacton.
>
> - Waits for it to propagate.
>
> - At 1.25x the dynamic mempool minimum, broadcasts a RBFr replacement
> that is 111 vbytes (162 bytes).
>
> ## Analysis
>
> - At 162 bytes each, 500,000 transactions is 81 MB. I think that will
> fit in a default-sized mempool.
>
> - The total amount of transaction data relayed is 500_000 * (400_000 +
> 162), or about 200 GB.
>
> - The typical daily bandwidth requirement of a blocks-only node is
> roughly 2.5 MB * 144, or about 0.36 GB per day. Ideally a relaying
> node is about the same due to compact blocks, but realistically, it's
> a small multiple of that. Call it 2 GB per day.
>
> - This implies the attack push each RBFr relay node to use 100x a
> non-RBFr relay node.
>
> - At 111 vbytes each, 500,000 transactions is 55.5 million vbytes. At
> my nodes current mempoolminfee (1 sat/vb), that's 55.5 million sats,
> or 0.55 BTC (about $37,000 USD).
>
> - This analysis ignores the cost of obtaining the UTXOs and possibly
> later consolidating them, but it also ignores some easy optimizations
> such as batching the replacements.
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/99f8b3b5-996e-41a4-bca8-eb1ddcba4ef3n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 28823 bytes --]

[bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 18566 bytes --]

Hi dev0,

> I will quote _willcl-ark_'s last comment as I do not have enough 
permissions in bitcoin core repository to moderate comments:
> 
> "However the comments section here has become difficult to follow due to 
numerous off-topic comments, a few personal disagreements, and repetition 
of arguments. In the interest of having a more productive and focused 
technical and p> hilosophical discussion we are going to close and lock 
this PR."

I think you're missing my argument about formalization as ways to have 
moderation norms shared and accepted by all contributors whatever, their
cultural or professional background. 

I believe (a) the moderation criteria on in / off-topic comment and its 
exercise by moderator shall be objective enough to be understood and 
spontaneously
followed by contributors and (b) the moderators vetted with permissions 
should adhere to a minimal of conflicts of interests guidelines to avoid 
being accused
of being "political" in the exercise of their permsisions (cf. bitcoin-meta 
issue #3 which I'll observe has been opened for 2 months now and have not 
received an answer).

> A new pull request should help reviewers. If you do not agree with it, 
feel free to discuss it with moderators in bitcoin core IRC channel.

This is a non-sense to say a new pull request should help reviewers, when 
as a PR author you cannot know with certainty who will be the reviewers in 
a FOSS project like Core.
About engaging on the moderation rules, like said, it's already done on the 
gituhb, which favors long-format and in-depth discussion (rather than an 
IRC channel).

> Related discussion: https://github.com/bitcoin-core/meta/issues/5

This is certainly a discussion that we shall have a community, be it 
bitcoin core project active contributors, or security researchers offering 
their time to report sec issues.

> Ironically, this is exactly how moderation works in bitcoin core pull 
requests and some comments were marked off-topic..

I'll observe that we're quite limited by the medium itself, i.e github as 
we cannot prioritize review comments based on contributors reputation.

Though this is not answering the risk of having an in / off-topic 
moderation criteria inflating with time and vicissiating from intellectual 
substance the "public communication channels".

If you look on the history of public space in the world over the last 2 
millenias and what lessons we can drawn or ponder for FOSS development, a 
public space is always
a frail notion that it always at risk of disappearing or being captured. I 
can always recommend you to read Hannah Arendet's The Crisis of Culture or 
The Human Condition if
you wish to meditate on this notion of public space, and the significance 
of it (it's a philosopher I hope relatively universal, whatever your 
cultural background).

> I have opened a pull request with the same commits (Peter Todd being the 
author) to enable Full RBF by default: 
https://github.com/bitcoin/bitcoin/pull/30493

Interesting, I'll review it again in the coming future.

Best,
Antoine
ots hash: 6ba9cae6564f1ef8c583115ec71d155e9b4504907e02059e7a02046b6220dc2e

Le samedi 20 juillet 2024 à 07:51:09 UTC+1, /dev /fd0 a écrit :

> Hi Antoine,
>
> >  I'm interested if you can propose a formal or mathematical definition 
> of what constitute
> > an in-topic of off-topic comments on a matters like full RBF, which has 
> been controversial
> > for like a decade.
>
> I will quote _willcl-ark_'s last comment as I do not have enough 
> permissions in bitcoin core repository to moderate comments:
>
> "However the comments section here has become difficult to follow due to 
> numerous off-topic comments, a few personal disagreements, and repetition 
> of arguments. In the interest of having a more productive and focused 
> technical and philosophical discussion we are going to close and lock this 
> PR."
>
> A new pull request should help reviewers. If you do not agree with it, 
> feel free to discuss it with moderators in bitcoin core IRC channel.
>
> >  Again, I'm interested if you can propose a formal or mathematical 
> definition of what constitute
> > a reasonable bitcoin core vulnerability handling policy and that way 
> give more ground on qualifying
> > if a present situation is falling out of this reasonable guidelines and 
> that can be qualified more
> > objectively as "politics".
>
> Related discussion: https://github.com/bitcoin-core/meta/issues/5
>
> > I think we have a mailing list to favorize textual long format and 
> encourage a more self-reflexive
> > mode of reasoning in the conduct of bitcoin engineering discussions. I 
> believe comments not bringing
> > new factual information or pointing to past experiences or concrete 
> piece of information are better
> > left to twitter / nostr / reddit, whatever other communication channel 
> where the scientific and
> > ethics of conversation standards are less stringent.
>
> Ironically, this is exactly how moderation works in bitcoin core pull 
> requests and some comments were marked off-topic..
>
> I have opened a pull request with the same commits (Peter Todd being the 
> author) to enable Full RBF by default: 
> https://github.com/bitcoin/bitcoin/pull/30493
>
> /dev/fd0
> floppy disk guy
>
> On Saturday, July 20, 2024 at 12:01:12 AM UTC Antoine Riard wrote:
>
>> Hi /dev/fd0
>>
>> > The last comment in the pull request suggests opening a new pull 
>> request to enable full RBF by default, referencing the one closed due to 
>> off-topic comments.
>>
>> I'm interested if you can propose a formal or mathematical definition of 
>> what constitute
>> an in-topic of off-topic comments on a matters like full RBF, which has 
>> been controversial
>> for like a decade. I can only think such definition could make future 
>> conversations about
>> the boundaries of what is in / off bitcoin engineering topic more 
>> objective.
>>
>> > It seems that you are the one trying to politicize this issue.
>>
>> Let's be realistic on the state of bitcoin core security issues handling 
>> in the recent words of
>> a group of some active contributors:
>>
>> "The project has historically done a poor job at publicly disclosing 
>> security-critical bugs, whether
>> externally reported or found by contributors. This has led to a situation 
>> where a lot of users perceive
>> Bitcoin Core as never having bugs. This perception is dangerous and, 
>> unfortunately, not accurate." [0].
>>
>> [0] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w
>>
>> Again, I'm interested if you can propose a formal or mathematical 
>> definition of what constitute
>> a reasonable bitcoin core vulnerability handling policy and that way give 
>> more ground on qualifying
>> if a present situation is falling out of this reasonable guidelines and 
>> that can be qualified more 
>> objectively as "politics".
>>
>> I think we have a mailing list to favorize textual long format and 
>> encourage a more self-reflexive
>> mode of reasoning in the conduct of bitcoin engineering discussions. I 
>> believe comments not bringing
>> new factual information or pointing to past experiences or concrete piece 
>> of information are better
>> left to twitter / nostr / reddit, whatever other communication channel 
>> where the scientific and
>> ethics of conversation standards are less stringent.
>>
>> All that said, I'm thinking to agree that the usage of all political 
>> rhethoric is a fallacy better
>> left for expressions on other communication channels and this is note 
>> wise to bundle it with novel
>> technical information, as from the outset it does not favor to 
>> concentrate the discussion on the fact
>> and logical reasoning themselves. Even more, political rhetoric very 
>> easily downgrade in moralistic
>> contest among protagonists on who has the monopole of the good / truth. 
>> Somehow bitcoin is beyond
>> good and evil (-- under some long-term and abstract perspective).
>>
>> Best,
>> Antoine
>> ots hash: 3088507ecfb55ed301bb0defce9fb490daa6bb9594e96d57336d603556a8fdab
>> Le vendredi 19 juillet 2024 à 19:27:36 UTC+1, /dev /fd0 a écrit :
>>
>>> Hi Peter,
>>>
>>> > I didn't get a substantive
>>> > response from Bitcoin Core, other than Core closing the my pull-req 
>>> enabling
>>> > full-RBF by default that would fix this specific vulnerability.
>>>
>>> The last comment in the pull request suggests opening a new pull request 
>>> to enable full RBF by default, referencing the one closed due to off-topic 
>>> comments. 
>>>
>>> > But read on, this is quite an odd case of Core politics, and the story 
>>> is not
>>> > as simple as Core refusing to fix a vulnerability.
>>>
>>> It seems that you are the one trying to politicize this issue. 
>>>
>>> /dev/fd0
>>> floppy disk guy
>>>
>>> On Thursday, July 18, 2024 at 4:04:26 PM UTC Peter Todd wrote:
>>>
>>>> # Summary 
>>>>
>>>> This is a public disclosure of a vulnerability that I previously 
>>>> disclosed to 
>>>> the bitcoin-security mailing list. It's an easy vulnerability to fix. 
>>>> Although 
>>>> as with other "free" relay attacks I've disclosed, I didn't get a 
>>>> substantive 
>>>> response from Bitcoin Core, other than Core closing the my pull-req 
>>>> enabling 
>>>> full-RBF by default that would fix this specific vulnerability. 
>>>>
>>>> But read on, this is quite an odd case of Core politics, and the story 
>>>> is not 
>>>> as simple as Core refusing to fix a vulnerability. Also, I've including 
>>>> a fun 
>>>> homework problem at the end: figure out how TRUC/V3 transactions itself 
>>>> creates 
>>>> a "free" relay attack. 
>>>>
>>>>
>>>> # Background 
>>>>
>>>> This is just one of a few "free" relay attacks that I have recently 
>>>> disclosed, 
>>>> including, but not limited to: 
>>>>
>>>> "A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2024 
>>>> https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg 
>>>>
>>>> "A Free-Relay Attack Exploiting Min-Relay-Fee Differences" - Mar 31st 
>>>> 2024 
>>>> https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo 
>>>>
>>>> The term "free relay attack" simply refers to any mechanism where 
>>>> transaction 
>>>> data can be broadcast at unusually low cost; the "free" in "free relay" 
>>>> is a 
>>>> misnomer as all these attacks do in fact have some cost. 
>>>>
>>>> This particular attack isn't significantly different than the other 
>>>> attacks 
>>>> I've disclosed. With one important exception: unlike those other 
>>>> attacks, 
>>>> fixing this particular attack would be quite easy, by enabling full-rbf 
>>>> by 
>>>> default. So I disclosed it to the bitcoin-security mailing list as a 
>>>> test: does 
>>>> Bitcoin Core actually care about free relay attacks? My hypothesis is 
>>>> that Core 
>>>> does not, as they know full well that "free" relay is an unavoidable 
>>>> problem; 
>>>> I've received absolutely no feedback from any Bitcoin Core members for 
>>>> the 
>>>> other disclosed attacks, beyond achow using my disclosure of the RBF 
>>>> Rule #6 
>>>> attack as an excuse to remove me from the bitcoin-security mailing 
>>>> list. 
>>>>
>>>> The fact that Core doesn't actually care about "free" relay attacks is 
>>>> relevant 
>>>> to TRUC/V3 Transactions. As per BIP-431: 
>>>>
>>>> "The primary problem with [RBFR proposals] is the potential for free 
>>>> relay and DDoS attacks. 
>>>>
>>>> Removing Rule 3 and 4 in general would allow free relay [27]." 
>>>>
>>>> https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki#user-content-Alternatives_replace_by_feerate 
>>>>
>>>> I believe the authors of that BIP are fully aware of the fact that 
>>>> "free" relay 
>>>> is an unavoidable problem, making their rational for TRUC/V3 bogus, and 
>>>> don't 
>>>> want to admit that they've wasted a large amount of engineering time on 
>>>> a bad 
>>>> proposal. I will be submitting a pull-req to get BIP-431 corrected, as 
>>>> the many 
>>>> "free" relay attacks I've disclosed clearly show that claiming RBFR 
>>>> would 
>>>> "allow" free relay is simply not true. 
>>>>
>>>> Notably, full-RBF is _itself_ a transaction pinning fix for many 
>>>> use-cases; 
>>>> part of the TRUC/V3 standard is to force full-RBF behavior for V3 
>>>> transactions. 
>>>> So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a 
>>>> second 
>>>> way, and TRUC/V3 proponents were the ones who tried to get the full-RBF 
>>>> option 
>>>> removed from Core in the first place. If not for this dumb bit of Core 
>>>> politics, I'm sure my year-old pull-req to enable full-RBF by default 
>>>> would 
>>>> have been merged many months ago, as almost all hashpower has adopted 
>>>> full-RBF 
>>>> making objections based on "zeroconf" absurd. 
>>>>
>>>>
>>>> # The Attack 
>>>>
>>>> If you're a competent Bitcoin engineer, familiar with how mempools 
>>>> work, you've 
>>>> probably figured it out already based on the title: obviously, if a 
>>>> high 
>>>> percentage of miners are adopting a policy that Bitcoin Core nodes are 
>>>> not, you 
>>>> can cheaply consume transaction relay bandwidth by simply relaying 
>>>> transations 
>>>> that miners are rejecting. 
>>>>
>>>> Specifically, do the following: 
>>>>
>>>> 1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled. 
>>>> 2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate. 
>>>> 3. Spend the outputs of A in a large, low fee-rate, transaction B with 
>>>> BIP-125 
>>>> opt-in enabled. ~100% of miners will reject B, as it spends an input 
>>>> not in 
>>>> their mempools. However Bitcoin Core nodes will waste bandwidth 
>>>> propagating 
>>>> B. 
>>>> 4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will 
>>>> waste 
>>>> bandwidth propagating Bn's that ~100% of miners are ignoring. 
>>>> 5. Double-spend A2 to recover your funds and do it all over again (or 
>>>> if A2 had 
>>>> a high enough fee-rate, just wait for it to be mined). 
>>>>
>>>> The cost to relay each B transaction depends on the fee-rate of B. 
>>>> Since 
>>>> Bitcoin Core defaults to a fairly large mempool, the minimum relay 
>>>> fee-rate is 
>>>> typically well below the economic fee-rate required for miners to 
>>>> actually mine 
>>>> a transaction; Core accepts transactions that are uneconomical for 
>>>> miners to 
>>>> mine for the forseeable future. 
>>>>
>>>> For example, at the moment typical mempools require transactions to pay 
>>>> at 
>>>> least 1sat/vB, while there are hundreds of MvB worth of transactions 
>>>> paying 
>>>> 4sat/vB, the minimum economical fee-rate. Thus, transactions paying 
>>>> less than 
>>>> 4sat/VB are extremely unlikely to get mined in the nearish future. 
>>>>
>>>> Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 
>>>> 3sat/vB would 
>>>> have almost zero cost as the probability of those transactions getting 
>>>> mined is 
>>>> nearly zero. This is true _regardless_ of what % of miners are mining 
>>>> full-RBF! 
>>>> As long as you can get at least one miner to mine the A double-spend, 
>>>> the 
>>>> attack only costs what it cost to get A mined. 
>>>>
>>>> If B's are broadcast at a higher fee-rate than the minimum economical 
>>>> fee-rate, 
>>>> then the % of full-RBF miners matters. For example, if only 99% of 
>>>> miners mine 
>>>> full-RBF, the chance of a B transaction getting mined per block is 
>>>> about 1%, so 
>>>> the amortized cost of broadcasting B is about 1% of whatever total fee 
>>>> the 
>>>> highest fee-rate variant of B pays. 
>>>>
>>>> For an attacker who does not need any B to be broadcast, the cost 
>>>> savings to 
>>>> use of relay bandwidth is approximately the ratio of the difference in 
>>>> size 
>>>> between B and and A. With a maximum standard transaction size of 
>>>> 100KvB, or 
>>>> 400KB serialized size, this ratio is on the order of 5000:1, times the 
>>>> total 
>>>> number of B variants broadcast, and the % chance of each B being mined; 
>>>> it's a 
>>>> few orders of magnitude. 
>>>>
>>>> Of course, as mentioned above, this is just one of *many* "free" relay 
>>>> attacks, 
>>>> so fixing this particular issue doesn't change much. 
>>>>
>>>>
>>>> # Attackers Who Benefit From B Getting Mined 
>>>>
>>>> Some attackers actually need B to get mined. For example, imagine an 
>>>> exchange 
>>>> who needs to do large consolidation transactions. They could use this 
>>>> attack 
>>>> (and some attacks like it) as a way to goad users and miners into 
>>>> mining 
>>>> consolidation transactions for them at low cost. In this variant of the 
>>>> attack, 
>>>> the attacker would pad the size of B with consolidation spends that 
>>>> they needed 
>>>> to do anyway. Someone who tried to stop the attack by getting B mined 
>>>> (eg via 
>>>> mempool.space's transaction accellerator) would simply be paying the 
>>>> attacker's 
>>>> fees for them. 
>>>>
>>>> Obviously, this strategy is only relevant for B's below the economic 
>>>> fee-rate. 
>>>> However, the weaker version of this strategy is to parallize the 
>>>> attack, and do 
>>>> your consolidation with the _A_ double-spends to reduce the # of bytes 
>>>> used per 
>>>> full-rbf double-spend. 
>>>>
>>>>
>>>> # TRUC/V3 Creates a Free Relay Attack 
>>>>
>>>> I'll leave the details of this as a homework problem. But obviously, 
>>>> the 
>>>> introduction of TRUC/V3 transactions *itself* creates a free relay 
>>>> attack very 
>>>> similar to the above! Just like full-RBF, not all miners will mine V3 
>>>> transactions. So you can do the exact same type of attack by taking 
>>>> advantage 
>>>> of this difference in mining policy. 
>>>>
>>>> -- 
>>>> https://petertodd.org 'peter'[:-1]@petertodd.org 
>>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/6d52892b-db6c-4497-894a-cc6f337acb97n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 22018 bytes --]

Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 2314 bytes --]

Hi Peter,

> It's quite bizzare to use "off topic comments" as an excuse to close a 
pull-req
> fixing a specific security vulnerability, assuming you actually care 
about that
> vulnerability. 

Do not assign to malovelence what can be assigned to genuine incompentence 
or willful laziness.

In the present case, it's all to bet that the moderators close the PRs, 
without being
aware of your reported security issue on the mailing list. This what you 
expect in
a open-source community managing sensitive security information, where it 
is formally
segregated between actors. I'm certainly not trusting will-ark with bitcoin 
security
information, at least anything beyond begnign issues. 

> As I've said elsewhere, Core could have easily and quietly
> merged that pull-req as-is, possibly by having a few people write some 
obvious
> ACK rationals.

I think this is the kind of issues, given the plausibility we still have 
laggards
of when `mempoolfullrbf` was introduced almost 2 years ago to reconsider 
their 
bitcoin infrastructure deployment, or 0conf acceptance flow. It's always 
polite
and it can only help building strong cultural norms in an ecosystem where 
the economic
traffic is deal with more and more by codebase which are not bitcoin core.

> The only good explanation for closing it is to further delay merging the
> pull-req, as well as disclosing the vulnerability.

I think this is the issue where it is worhty to purse the conservation:
https://github.com/bitcoin-core/meta/issues/5

All that said, I'll re-advocate your integration to the bitcoin security
mailing list by re-opening an issue on the github repository ?

Thanks to confirm you're okay with that (this can be done in private).
Very pragmatically, I'm trusting you more than most of the folks on the
list right now if I have issues to report.

Best,
Antoine
ots hash: 6c6ab1f4264c63245063a35da7f29f9e874a152a68e521b7f2ca2a972584a95d

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/a7ae8eee-11c8-48ea-80f8-4411741c3d3en%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 2790 bytes --]

Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[/dev /fd0]

[-- Attachment #1.1: Type: text/plain, Size: 2832 bytes --]

Hi Peter,

I agree that handling of vulnerability reports could be improved, although 
I have less expectations from bitcoin core to acknowledge any feedback. 
Here are a few things that we can do to improve the process:

- Report vulnerabilities anonymously and share real identity with 
disclosure later if required.
- Send the email to achow101 or sipa or fanquake and keep 
security@bitcoincore.org in Cc.
- Lets create a hall of fame webpage which has the name of all developers 
who reported vulnerabilities along with other details. Community could also 
donate directly to developers.
- Do not expect response on weekends and wait for at least 7-30 days before 
full disclosure if vulnerability report is ignored.

Maybe you and others on mailing list could add suggest more improvements.

/dev/fd0
floppy disk guy

On Saturday, July 20, 2024 at 3:12:46 PM UTC Peter Todd wrote:

> On Fri, Jul 19, 2024 at 10:57:40PM -0700, /dev /fd0 wrote:
> > Hi Antoine,
> > 
> > > I'm interested if you can propose a formal or mathematical definition 
> of 
> > what constitute
> > > an in-topic of off-topic comments on a matters like full RBF, which 
> has 
> > been controversial
> > > for like a decade.
> > 
> > I will quote _willcl-ark_'s last comment as I do not have enough 
> > permissions in bitcoin core repository to moderate comments:
> > 
> > "However the comments section here has become difficult to follow due to 
> > numerous off-topic comments, a few personal disagreements, and 
> repetition 
> > of arguments. In the interest of having a more productive and focused 
> > technical and philosophical discussion we are going to close and lock 
> this 
> > PR."
> > 
> > A new pull request should help reviewers. If you do not agree with it, 
> feel 
> > free to discuss it with moderators in bitcoin core IRC channel.
>
> It's quite bizzare to use "off topic comments" as an excuse to close a 
> pull-req
> fixing a specific security vulnerability, assuming you actually care about 
> that
> vulnerability. As I've said elsewhere, Core could have easily and quietly
> merged that pull-req as-is, possibly by having a few people write some 
> obvious
> ACK rationals.
>
> The only good explanation for closing it is to further delay merging the
> pull-req, as well as disclosing the vulnerability.
>
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/955e7097-ca7a-452a-953f-718aca14cdc6n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 4032 bytes --]

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[David A. Harding]

On 2024-07-20 05:03, Peter Todd wrote:
> What other "free" relay attacks can you think of that were fixed?

The two you mention were the two I had in mind.

> Did you actually read my One-Shot RBFR proposal?

Yes.  It didn't provide any examples of RBFr free relay and I wanted to
see whether a basic RBFr free relay attack would use significantly more,
significantly less, or about the same amount of bandwidth per dollar
spent as other free relay attacks.  My conclusion is that it's about the
same.

> Weak blocks are not a solution to any of the "free" relay attacks I've
> disclosed and your source does not claim that they are a "free" relay
> solution.

It does not explicitly say that, but it does say: "bonus use-cases:
“Forcible insertion” of transactions that are incentive-compatible but
violate anti-DoS rules".

For example, in some of the scenarios you describe, the attacker sends
an appealing transaction to miners and then sends less appealing
versions of that transaction to relay nodes.  If the appealing
transaction enters the top mempool and gets included in a weak block,
relay nodes will stop relaying less appealing variations minutes to
hours before they otherwise would.

Weak blocks also provide a decentralized DoS-resistant mechanism for
voluntarily communicating all sorts of information from miners to other
miners and relay nodes.  That makes them an excellent tool for resolving
any attack that depends on miners and relay nodes having a divergent set
of transactions.

> 1) Have you've read my One Shot RBFR proposal? In particular, my
> analysis of DoS attacks *including* existing DoS attacks like
> simultaneous broadcast.
> 
> 2) Do you agree or disagree with me that these existing DoS attacks
> are real?

Yes, I've read your proposal, and I agree those attacks are plausible.
In my mind, the major difference between those free relay attacks
and RBFR free relay attacks is how solvable they are.

I think it's easy to sketch a significant mitigation to all free relay
attacks (including RBFR):

- Reduce the maximum size of both relayable transactions and in-mempool
   packages, e.g. from 100,000 vbytes to 1,000 vbytes.

- Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB.

- Increase the default mempool feerate floor, e.g. from e.g. from 1
   sat/vb to 100 sat/vb.

That would break relay of many existing presigned transactions,
potentially leading to money loss, and would break other existing
usecases, not to mention introduce other problems.  However, I think
it's sufficient to prove that a mitigation to free relay is possible
without rendering the network unusable.

Of course, an ideal solution wouldn't require placing any additional
constraints on mempool policy.  For the case of free relay due to
divergent mempool policies, maybe it's something that could be done with
transaction set reconciliation (~erlay), functions for allowing
independent nodes to come to consistent conclusions about the best
revenue set of transactions (~cluster mempool), P2P relay of non-obvious
cluster linearizations[1], and miners voluntarily committing to their
mempool contents in candidate blocks and P2P relaying those commitments
in weak blocks.

Innovations like that don't work for RBFR.  If mempool policy is kept
the same, free relay attacks with RBFR remain equally effective no
matter what mechanisms we implement to improve preconsensus consistency.

If pure RBFR is added and clever protocol developers find ways to
largely fix other free relay attacks, then devs will either need to
significantly restrict mempool policy anyway or will need to restrict or
remove RBFR to make Bitcoin Core safe.  Given that, it seems to me like
a very reasonable decision not to add pure RBFR and to wait until better
tools like cluster mempool become available before evaluating
significant changes to RBF policy (like one-shot RBFR).

Thanks,

-Dave

[1] 
https://github.com/bitcoinops/bitcoinops.github.io/pull/1421#discussion_r1415834695

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/d57a02a84e756dbda03161c9034b9231%40dtrt.org.

Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

['Ava Chow' via Bitcoin Development Mailing List]

On 07/20/2024 10:06 PM, Antoine Riard wrote:
> "Naive", as saying this is the _Bitcoin Core_ project list only can only 
> provoke blind
> spot among the list members if the security issues are either affecting 
> old part of
> the codebases that younger members have less experiences with (some 
> parts like consensus
> or block-relay are modified only every 5 years) or novel factors from 
> upstream or downstream
> (e.g the internet networking stack or implications on deployed contract 
> protocols like
> lightning). On both the former and latter criterias, I think Peter 
> overly meets the bar.

Peter was not the only "senior" person on the security list. Obviously I 
will not disclose non-public information, but certainly there are people 
on the security list who are just as, if not more, senior than Peter.

Furthermore, the "old parts" still do get changed, and someone who no 
longer actively contributes to the project is more likely to be unaware 
of how the code actually works today, even if they are familiar with 
components that change infrequently.

> When you've big sh*t hitting the fan like inflation bugs or level DB 
> 2013 unexpected fork you
> prefer have experts with a decade of experience to collaborate with, and 
> sharing the same cultural
> and ethical norms of the active contributors evaluated by numbers on 
> commits on the last single-digit
> years.

Not being on the list does not preclude him from being consulted if the 
need arises.

With the two examples you provide, I am not aware of Peter being 
actively involved in the resolution of both of those, whereas there are 
current members of the list who were.


In general though, it is not clear to me how it was beneficial to have 
Peter on the security list, nor how not having him is directly harmful. 
In the 2 years that I have been on the security list, I was unaware that 
Peter was a recipient until shortly before he was removed. My 
understanding is that others who have been on the list longer than me 
were also unaware.

Ava

> 
> I'll repropose Peter admission on the security list mailing list in the 
> coming weeks by opening an
> issue on the bitcoin-meta repository, once this current mailing list 
> thread has slowed down a bit,
> or at least the technical analysis has been dissociated from the 
> proceedings which have all been
> bundle in a big message. In my very personal opinion, I still trust more 
> Peter competence and experience
> than some other people I know who are on the security mailing list.
> 
> All that said I appreciate your answer and I'm satisfied from the 
> personal role you've have played
> in the matter with, and be reassured I'll keep you among the recipient 
> of future security issues with
> a potential impact on bitcoin core that I might find or be aware off.
> 
> Best,
> Antoine
> ots hash: db441b51684ad3a6897f67d42c74ccfcb9a4ffed40d4bdbe30a2edd867ccdd54
> 
> Le samedi 20 juillet 2024 à 01:50:25 UTC+1, Ava Chow a écrit :
> 
>     On 07/19/2024 07:58 PM, Antoine Riard wrote:
>      > As said in one my previous email, I'm still curious about achow101
>      > explaining publicly
>      > why you have been kicked-out of the bitcoin-security mailing
>     list, when
>      > you were certainly
>      > more senior than achow101 in matters of base-layer security
>     issues or
>      > even hard technical
>      > issues like consensus interactions (e.g bip65). I'll re-iterate my
>      > respect towards achow101
>      > as a maintainer from years of collaboration, though this is a topic
>      > worthy of an answer.
> 
>     I am not the one that removed Peter from the mailing list, nor do I
>     even
>     have the login(s) to do so.
> 
>     There was a discussion amongst several members of the security list
>     about who was on the list, and who should be on the list. Given that
>     the
>     security list is the _Bitcoin Core_ security list, we determined that
>     the people who should be on the list are people who still actively
>     contribute to the project. As Peter Todd no longer actively contribute
>     code nor code review to the project, we decided that it didn't make
>     sense to continue to have him on the list.
> 
>     My recollection is that multiple other people were removed from the
>     list
>     for the same reason at the same time.
> 
>     Ava
> 
> -- 
> You received this message because you are subscribed to the Google 
> Groups "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to bitcoindev+unsubscribe@googlegroups.com 
> <mailto:bitcoindev+unsubscribe@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com <https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/a8eac5f2-b85a-434f-868e-eba7fd2558c6%40achow101.com.

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 8772 bytes --]

On Sun, Jul 21, 2024 at 05:35:31AM -1000, David A. Harding wrote:
> On 2024-07-20 05:03, Peter Todd wrote:
> > What other "free" relay attacks can you think of that were fixed?
> 
> The two you mention were the two I had in mind.

Right. So in the entire history of Core, we have two quite ridiculous free
relay attacks that got fixed, and we *added* a significant free-relay
vulnerability by adding mempool expiration. We also added a free-relay
vulnerability, and a fill-and-dump vulnerability, with the mempool size limit.

That's not evidence that Core actually cares much about "free" relay.

> > Did you actually read my One-Shot RBFR proposal?
> 
> Yes.  It didn't provide any examples of RBFr free relay and I wanted to
> see whether a basic RBFr free relay attack would use significantly more,
> significantly less, or about the same amount of bandwidth per dollar
> spent as other free relay attacks.  My conclusion is that it's about the
> same.

Good. So you basically agree with me that RBFR does _not_ significantly change
the status quo.

I'll respond to the specifics of your RBFR analysis separately; it does *not*
apply to one-shot RBFR.

> > Weak blocks are not a solution to any of the "free" relay attacks I've
> > disclosed and your source does not claim that they are a "free" relay
> > solution.
> 
> It does not explicitly say that, but it does say: "bonus use-cases:
> “Forcible insertion” of transactions that are incentive-compatible but
> violate anti-DoS rules".
> 
> For example, in some of the scenarios you describe, the attacker sends
> an appealing transaction to miners and then sends less appealing
> versions of that transaction to relay nodes.  If the appealing
> transaction enters the top mempool and gets included in a weak block,
> relay nodes will stop relaying less appealing variations minutes to
> hours before they otherwise would.

Yes, "minutes to hours". Transactions relay on the order of seconds to tens of
seconds. Weak blocks simply aren't relevant.

Also, the attacks I've described are ones that can be pulled off by having a
tiny minority of hash power mine a double spend. Weak blocks don't help you
there, as that tiny minority isn't likely to even find a weak block.

> Weak blocks also provide a decentralized DoS-resistant mechanism for
> voluntarily communicating all sorts of information from miners to other
> miners and relay nodes.  That makes them an excellent tool for resolving
> any attack that depends on miners and relay nodes having a divergent set
> of transactions.

For weak blocks to be a solution, you at minimum need to take away the ability
of miners to choose what transactions they mine. For example, consider the
scenario where you do a "free" relay attack by broadcasting transactions that
OCEAN rejects, and then double-spending them via OCEAN _after_ the transactions
have been broadcast. Equally, you'd need to take away the ability of RBFR
miners to do the revenue maximizing thing: mining RBFR replacements.

I'll also second Antoine Riard's objections to this class of idea in general:
you're really proposing a secondary pseudo-consensus mechanism to solve the
problems in your first pseud-consensus mechanism.

> > 1) Have you've read my One Shot RBFR proposal? In particular, my
> > analysis of DoS attacks *including* existing DoS attacks like
> > simultaneous broadcast.
> > 
> > 2) Do you agree or disagree with me that these existing DoS attacks
> > are real?
> 
> Yes, I've read your proposal, and I agree those attacks are plausible.
> In my mind, the major difference between those free relay attacks
> and RBFR free relay attacks is how solvable they are.
> 
> I think it's easy to sketch a significant mitigation to all free relay
> attacks (including RBFR):
> 
> - Reduce the maximum size of both relayable transactions and in-mempool
>   packages, e.g. from 100,000 vbytes to 1,000 vbytes.
> 
> - Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB.
> 
> - Increase the default mempool feerate floor, e.g. from e.g. from 1
>   sat/vb to 100 sat/vb.
> 
> That would break relay of many existing presigned transactions,
> potentially leading to money loss, and would break other existing
> usecases, not to mention introduce other problems.  However, I think
> it's sufficient to prove that a mitigation to free relay is possible
> without rendering the network unusable.

The irony here is you've almost described a _good_ mitigation to "free" relay
attacks: just reduce the size of the default mempool. A big reason why we have
"free" relay attacks right now is because we allow transactions to be broadcast
that are uneconomical to mine; if you limit transaction broadcast to
transactions that are economical to mine in the near future, relay is more
expensive.

For miners, you can make a decent argument that they want to have on-hand a big
backlog of transactions in case mempools empty out; in my conversations with
miners almost all of them claim they run with much larger than default mempools
(eg >1GB). I've even discussed mempool emptying attacks and RBFR in this
context with miners: they didn't think they were an issue as replacing their
mempools was absurdly expensive.

Fee estimation of course can make use of knowing what backlog of transactions
exist. But I'm sure only a small minority of nodes do fee estimation.

A variant of this solution would be to just pick the minimum relay fee to be
some number N blocks worth of transactions "back" from the highest fee-rate tip
of the mempool. Obviously, this will be easier to implement with a cluster
mempool, and requires package relay for the CPFP case.

> Of course, an ideal solution wouldn't require placing any additional
> constraints on mempool policy.  For the case of free relay due to
> divergent mempool policies, maybe it's something that could be done with
> transaction set reconciliation (~erlay), functions for allowing

Erlay (and transaction set reconciliation in general) does not help you
reconcile conflicting transactions. It simply lets you efficiently learn about
the total set of known transactions. Notice how the Erlay is based on WTXIDs,
and the BIP doesn't even talk about dealing with conflicts.

> independent nodes to come to consistent conclusions about the best
> revenue set of transactions (~cluster mempool),

That's quite irrelevant as RBFR _is_ the highest revenue policy in lots of
situations. That's one reason why in my discussions with miners/pools, they're
interested in implementing it (mining pools have very low profit margins, so
every cent counts, and RBFR replacements are reasonably common already). Mining
pools implemented full-RBF against the wishes of Core for the same reason:
full-RBF earns you more revenue, and I made it easy to implement.

Implementing one-shot RBFR is probably going to be quite a bit cleaner with
cluster mempools, as it'll provide a nice way to rapidly determine what the
minimum economic fee-rate is to get into the next (N) blocks. (though you can
do this in a less clean way by just periodically assembling a trial block and
recording the value, or using the fee estimation code)

Finally, why are clusters even relevant to "free" relay? Most "free" relay
attacks don't even need transaction packages. The really boring and unsolvable
"free" relay attack of simply broadcasting large transactions that conflict
with small ones is done with single transaction packages.

> P2P relay of non-obvious
> cluster linearizations[1], and miners voluntarily committing to their
> mempool contents in candidate blocks and P2P relaying those commitments
> in weak blocks.

As I explained above, weak blocks is not a "free" relay solution.

> Innovations like that don't work for RBFR.  If mempool policy is kept
> the same, free relay attacks with RBFR remain equally effective no
> matter what mechanisms we implement to improve preconsensus consistency.

I could also argue that magic ponies will solve "free" relay. We have to weight
that hope with the likelyhood it will happen; none of the technical
advancements you have mentioned even come close.


Anyway, I'll reply to the rest of your other email separately.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zp1utYduhnWf4oA4%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

['Anonymous User' via Bitcoin Development Mailing List]

[-- Attachment #1.1: Type: text/plain, Size: 9456 bytes --]

I came from some twitter discussion so I think this thread is trending. I 
think we need to figure a way out onward. 

Here is a last resort solution by launching this attack in production. We 
should avoid making this last resort solution, but from what Peter Todd 
said, below seems completely practical.
Please treat it as story reading and do not overthink that this is the way 
to go.

- a few people in the list form a group and fork bitcoin core and apply the 
patch from Peter Todd
- work with a few miners to massively perform the free relay attacks and 
other mempool related attacks in an effort to force mining pools and miners 
to switch from bitcoin core into the fork in order for their nodes to 
continue running in a healthy manner
- build a free service for file transfer or VPN taking advantage of rbf in 
the Bitcoin network and make it a public good that millions of users can 
use, causing most of the mempool transactions to be conflicting (due to 
different implementations of rbf) and therefore wallets have to eventually 
stop broadcasting transactions to bitcoin core nodes (which could be using 
a completely new list of seed nodes, disabling the existing seed node 
list), and non-bitcoin-core nodes, in order to have more healthy 
transaction flows and mempool data sharing, would start node-shopping by 
disconnecting themselves from bitcoin core nodes and refusing to be their 
peers 
- core is forced to find a way onward, or the core gives up and archives 
the bitcoin core repo

The damage is probably just a few days of slower transaction processing, 
much smaller than the price spike caused by ordinals last year. 

Democracy starts with people having different opinions that DO NOT need to 
reconcile. So, it is not about how we get different people in this mail 
list, or the non-public security list, to achieve the same opinions, like 
whether full RBF is needed. It is about how Bitcoin can allow two groups of 
people that have fundamentally different opinions and are unwilling and 
impossible to reconcile. We can have 5-10 security disclosure mail lists by 
different groups of people, and good-faith vulnerability reporters can 
choose to exclusively report the bugs to some groups that the reporters 
feel to be knowledgeable and responsive and, importantly, have the capacity 
and the motivation to work on it. 

I feel bad for Peter Todd. If I were him, I wouldn't report the bug. I 
would sell the bug because I got nothing in return, but probably more 
jealousy or more retaliation for being the only person serious about an 
issue. 
Btw, Peter already has a fork. 

Ethereum has great software development process as well as its ecosystem. 
Smart contracts get heavily audited not because people care about security. 
It is because North Korea has successfully stolen probably hundreds of 
millions of dollars from different projects and even causing some projects 
to fall apart. This is in essence similar to, if one day Bitcoin has a 
memory exploit issue that causes a massive amount of miners to lose coins 
that they own, and the network again needs to decide whether to do a hard 
fork, that is the time when we will be discussing if stopping development 
in C/C++ and limiting Bitcoin core development to Rust and Rust only are 
the way forward.

Thanks,
Anonymous user, as the floppy disk guy recommends this might be the best 
way to engage in the mailing list onward

I strongly encourage people to try engaging in this email list anonymously. 
It feels great to say things out loud without worrying about retaliation on 
unrelated matters. Also, this should be permitted. We still don't know who 
Satoshi is. If I were Satoshi, I probably also wouldn't report a bug I 
know. 

On Sunday, July 21, 2024 at 1:49:10 PM UTC-7 Ava Chow wrote:

> On 07/20/2024 10:06 PM, Antoine Riard wrote:
> > "Naive", as saying this is the _Bitcoin Core_ project list only can only 
> > provoke blind
> > spot among the list members if the security issues are either affecting 
> > old part of
> > the codebases that younger members have less experiences with (some 
> > parts like consensus
> > or block-relay are modified only every 5 years) or novel factors from 
> > upstream or downstream
> > (e.g the internet networking stack or implications on deployed contract 
> > protocols like
> > lightning). On both the former and latter criterias, I think Peter 
> > overly meets the bar.
>
> Peter was not the only "senior" person on the security list. Obviously I 
> will not disclose non-public information, but certainly there are people 
> on the security list who are just as, if not more, senior than Peter.
>
> Furthermore, the "old parts" still do get changed, and someone who no 
> longer actively contributes to the project is more likely to be unaware 
> of how the code actually works today, even if they are familiar with 
> components that change infrequently.
>
> > When you've big sh*t hitting the fan like inflation bugs or level DB 
> > 2013 unexpected fork you
> > prefer have experts with a decade of experience to collaborate with, and 
> > sharing the same cultural
> > and ethical norms of the active contributors evaluated by numbers on 
> > commits on the last single-digit
> > years.
>
> Not being on the list does not preclude him from being consulted if the 
> need arises.
>
> With the two examples you provide, I am not aware of Peter being 
> actively involved in the resolution of both of those, whereas there are 
> current members of the list who were.
>
>
> In general though, it is not clear to me how it was beneficial to have 
> Peter on the security list, nor how not having him is directly harmful. 
> In the 2 years that I have been on the security list, I was unaware that 
> Peter was a recipient until shortly before he was removed. My 
> understanding is that others who have been on the list longer than me 
> were also unaware.
>
> Ava
>
> > 
> > I'll repropose Peter admission on the security list mailing list in the 
> > coming weeks by opening an
> > issue on the bitcoin-meta repository, once this current mailing list 
> > thread has slowed down a bit,
> > or at least the technical analysis has been dissociated from the 
> > proceedings which have all been
> > bundle in a big message. In my very personal opinion, I still trust more 
> > Peter competence and experience
> > than some other people I know who are on the security mailing list.
> > 
> > All that said I appreciate your answer and I'm satisfied from the 
> > personal role you've have played
> > in the matter with, and be reassured I'll keep you among the recipient 
> > of future security issues with
> > a potential impact on bitcoin core that I might find or be aware off.
> > 
> > Best,
> > Antoine
> > ots hash: 
> db441b51684ad3a6897f67d42c74ccfcb9a4ffed40d4bdbe30a2edd867ccdd54
> > 
> > Le samedi 20 juillet 2024 à 01:50:25 UTC+1, Ava Chow a écrit :
> > 
> > On 07/19/2024 07:58 PM, Antoine Riard wrote:
> > > As said in one my previous email, I'm still curious about achow101
> > > explaining publicly
> > > why you have been kicked-out of the bitcoin-security mailing
> > list, when
> > > you were certainly
> > > more senior than achow101 in matters of base-layer security
> > issues or
> > > even hard technical
> > > issues like consensus interactions (e.g bip65). I'll re-iterate my
> > > respect towards achow101
> > > as a maintainer from years of collaboration, though this is a topic
> > > worthy of an answer.
> > 
> > I am not the one that removed Peter from the mailing list, nor do I
> > even
> > have the login(s) to do so.
> > 
> > There was a discussion amongst several members of the security list
> > about who was on the list, and who should be on the list. Given that
> > the
> > security list is the _Bitcoin Core_ security list, we determined that
> > the people who should be on the list are people who still actively
> > contribute to the project. As Peter Todd no longer actively contribute
> > code nor code review to the project, we decided that it didn't make
> > sense to continue to have him on the list.
> > 
> > My recollection is that multiple other people were removed from the
> > list
> > for the same reason at the same time.
> > 
> > Ava
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to bitcoindev+...@googlegroups.com 
> > <mailto:bitcoindev+...@googlegroups.com>.
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com 
> <
> https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
>
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/3f7d43bd-af9e-4af5-860a-223504bb4fcan%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 11764 bytes --]

[bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 4191 bytes --]

On Fri, Jul 19, 2024 at 08:41:07PM -1000, David A. Harding wrote:
> 3. Limiting the worst-case free relay and excessive mempool eviction
>    requires additional rules (e.g. one-shot RBFr) that are challenging
>    to implement and analyze at present, as several devs have noted[3].
>    Both implementation and analysis should become much easier if cluster
>    mempool is deployed (also noted by devs), but the deployment of
>    cluster mempool requires removal of CPFP carve-out, and removal of
>    CPFP carve-out requires either the upgrade of thousands of LN nodes
>    and channels or a drop-in solution (ideally one that can be analyzed
>    independently from cluster mempool, like TRUC).

I'm going to answer this separately for the sake of easy citation in the
future. tl;dr: cluster RBFR makes the CPFP carve-out obsolete, fixing pinning
for existing implementations; TRUC meanwhile isn't even a drop-in solution, and
requires everyone to upgrade before cluster mempool is even possible.

To recap, the CPFP carve-out¹ is an exception to package size limits that
allows a single transaction to exceed those limits slighty, provided that the
transaction has only one unconfirmed ancestor. This is relevant to protocols
like Lightning, where your counterparty might try to pin a transaction by
spending one of the two anchor outputs with a large, low-fee, transaction such
that the total package size is just under the package limit. Notably, in this
scenario, there is *no* way for you to broadcast a CPFP without the CPFP
carve-out because regardless of fee-rate, your transaction will simply be
rejected due to it causing the package limit to be exceeded.

I won't comment on whether or not the cluster mempool is genuinely incompatible
with CPFP carveouts; I'm not convinced that's true. But that point is
irrelevant anyway. To understand why, let's look at package replacement.

Package replacement is the idea that we can do RBF with packages of
transactions. For situations where the CPFP carve-out is relevant, we can
instead evaluate the CPFP child transaction, and the parent transaction(s), as
a package and compare that package to the package consisting of the existing
child transaction(s), and the parent transaction. With RBF alone, that would
allow you to defeat a package size pin by paying more in fees than the
conflicting child transaction(s), reducing this scenario to a straightforward
BIP-125 Rule #3 total fees pin.

Actually implementing this type of package replacement is simple: if you
receive a single transaction with an unconfirmed parent, if the transaction is
rejected due to package limits, try again, treating it as a package
replacement.

Finally, with package (one-shot) RBFR, we defeat both the package size pin and
the Rule #3 pin: so long as your CPFP child transaction pays a higher fee-rate
than the conflicting large, low-fee-rate, child transaction(s) made by the
attacker, you can replace the conflict and get the parent transaction(s) mined.
The only thing protocols need to do is ensure that the combination of parent
transaction(s) and child CPFP doesn't itself exceed the package size limits,
which Lightning already does just fine.


This is a much better upgrade path than TRUC + cluster mempool. We don't have
to wait for existing Lightning users to upgrade and open new channels. Indeed,
we even fix existing pinning problems for existing Lightning implementations,
which RBFR is already² doing!. And we actually fix pinning in general, for all
use-cases, not just the narrow subset that can make use of TRUC.


# References

1) https://bitcoinops.org/en/topics/cpfp-carve-out/
2) https://groups.google.com/g/bitcoindev/c/n2GNmnz0btw

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zp5GW/yHzPB8wyjU%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 6384 bytes --]

On Sat, Jul 20, 2024 at 07:10:53PM -0700, Antoine Riard wrote:
> 
> Hi Dave,
> 
> Thanks for your thoughtful answer (even if its wasn't addressed to me 
> primarly).
> 
> > I cannot imagine what would make you think that protocol developers are
> > not concerned about attacks that could drive large numbers of relay
> > nodes off the network for a cost easily affordable to any well-funded
> > adversary.
> 
> From my experience code reviewing the wallet / mempool re-broadcast of few
> years ago, free tx-relay / bandwidth waste attacks were far to be 
> understood 
> or plainly weighted by some contributors of a newer generations, including 
> by
> the own champion of the proposal. The proposal was finally abandonned when a
> more senior dev came up with quantitative analysis of code changes [0].
> 
> [0] https://github.com/bitcoin/bitcoin/pull/21061#issuecomment-851563105

An irony here is that rebroadcasting makes most "free" relay attacks *more*
expensive, not less. sdaftuar had some correct points, like avoiding bandwidth
spikes. But for any "free" relay attack based on broadcasting conflicting
transactions at different fee-rates, where the higher fee-rate transaction is
not mined, you get a better attack if the higher fee-rate transaction falls out
of node mempools, allowing the lower fee-rate conflict to be broadcast again.

If rebroadcasters ensure that nodes have the higher fee-rate tx, all you can do
to "reset" the attack is either get your UTXO(s) mined. Or use an even higher
fee-rate. Without rebroadcasting, you can wait for the expiry period to be
reached.

> > In this case, you've found a specific instance (full-RBF vs signaled
> > RBF) of a well-known general problem (optional policies leading to
> > mempool inconsistencies, allowing free relay) and appear to be arguing
> > that devs don't care about free relay because they refused to reverse a
> > previous decision (to not change the RBF configuration default) that has
> > been hotly debated multiple times.
> 
> I think what is more interesting and noteworhty in the whole line of 
> reaosning
> of Peter with the present disclosure is how much the adversial effect is 
> favor
> by the supermajority of miners running `mempoolfullrbf` [1].
> 
> [1] https://github.com/bitcoin/bitcoin/pull/28132#issue-1817178316

Not just miners: any node running with mempoolfullrbf=1 is going to waste less
bandwidth if someone actually does this attack. 

> Under those conditions, where it took 9 years for the bitcoin core project 
> to disclosre
> some vulnerabilitires, personally I'm more likely to understand that the 
> bitcoin core project
> is under-staffed is competent experts to keep public disclosure in 
> reasonable timeframe (-- at
> least equivalent to the kernel world), and as corollorary to fully evaluate 
> technical proposal
> with all its strength and weaknesses.
> 
> Saying an "already overdiscussed issues that gets nobody closer to 
> fundamental solutions" is
> insulting for Peter, honestly.

Indeed. You'd think solid evidence, trivially verifiable by anyone, that almost
all miners had adopted full-rbf would be enough. Instead that evidence doesn't
even receive any acknowledgement.

> As an offchain protocol developers which has been involved in the majority 
> of technical conversations,
> implementations and deployment of the "anchor output" upgrade, I believe on 
> the long-term CPFP-style fee-bumping
> of contract protocol, including lighting, is not the most robust technical 
> solutions. I think anyone can check
> in the bitcoin optech anchor output glossary the numerous vulnerabilities 
> that have plagued this fee-bumping 
> solutions over the past years.

RBF is way underused in protocols in general. And there have probably been
literally millions of dollars wasted on fees spent by inefficient CPFP
solutions when RBF (via pre-signed transactions) could have been used instead.
This financial figure will only get higher as Lightning gets more adoption. It
also limits Lightning in mass failure scenarios: every byte saved while force
closing a channel is room that could be used to force close another channel.

> I already reviewed some parts of cluster mempool. Fundamentally, economical 
> mempool pinnings for second-layers (bip125 absolute
> fee) with pre-signed time-sensitive transactions arises from a world where 
> there is (a) an asynchronicity of mempools and (b) one
> cannot guess feerates at block + 1 (-- let's say in a deterministic fashion 
> as understood by traditional cryptographic litterature
> when doing cryptanalysis). Better RBF policies won't solve that, including 
> RBFr.

I have to disagree here. The nature of protocols like Lightning is there is a
maximum amount that it's worth attempting to pay to get a transaction mined to
perform some action. There also a deadline to perform that action.

For example, an HTLC has a clear expiry time and value. *Even if* you have no
idea what fee-rates are needed to get a transaction mined, you can simply do
repeated RBF bumps at higher and higher fee-rates, ending at a fee-rate that
spends the entire value of the HTLC. As long as you do in fact have uncensored
access to miner mempools - as long as you haven't been sybil attacked - this
approach will do about as well as is possible, modulo pinning attacks. So our
job is now to simply fix the pinning attacks with better RBF policy.

IIUC, this RBF fee-bumping approach is exactly what the RBF sweeper introduced
in LND v0.18 does. Face with, eg, high blockspace demand the sum total of LND
RBF sweepers will result in the most valuable HTLCs and similar things being
mined, while less valuable transactions don't (ignoring pinning of course).
That's fine! That's the best we can do given a limited blockspace.

Traditional cryptography literature is not relevant here, as it's based on the
difficulty of mathematical problems, not economics; the security of L2
protocols is based on economics.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zp52WDL4hV16CbKV%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not

[David A. Harding]

On 2024-07-22 01:45, Peter Todd wrote:
> TRUC meanwhile isn't even a drop-in solution, and requires everyone to
> upgrade before cluster mempool is even possible.

The proposed BIP for TRUC[1] is indeed entirely opt-in and would require
all users of CPFP-CO (e.g. LN anchors channels) to upgrade their
software and switch to a new commitment transactions format, which
currently requires closing and reopening all anchors channels.  There's
work on improving upgrade mechanisms in LN, but it would still be a pain
and a major delay to cluster mempool to depend on every LN user
upgrading.

However, there has also been significant discussion and analysis[2] of 
an
imbued-semantics form of TRUC that could be retroactively applied to
LN-style anchor outputs (which are the only users of CPFP-CO we know
about).  In that case, nobody needs to upgrade before cluster mempool
becomes possible.

In my previous email, I assumed you were familiar with the imbued
semantics proposal; I'm sorry for the miscommunication.

-Dave

[1] 
https://github.com/bitcoin/bips/blob/158acdbbbf8ef13f6b345b6281a96e88e20d2cf9/bip-truc.mediawiki#user-content-Specification
[2] 
https://delvingbitcoin.org/t/analysis-of-attempting-to-imbue-ln-commitment-transaction-spends-with-v3-semantics/527

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/0eeb34c87b4cd7c9165983dc3a613550%40dtrt.org.

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 13924 bytes --]

On Fri, Jul 19, 2024 at 08:41:07PM -1000, David A. Harding wrote:
> > I believe the authors of [BIP431...] don't want to admit that they've
> > wasted a large amount of engineering time on a bad proposal.
> 
> You've previously argued against designing contract protocols to depend
> CPFP-style fee bumping for their offchain transactions, however that is
> what is widely used by LN today and it appears to be what LN and other
> offchain protocol developers want to use in the future.  If we accept
> that, at least for the purposes of argument, what can we do to improve
> CPFP fee bumping for LN?

To be clear, the reason why I came up with one-shot RBFR was _because_ I wanted
to find a pinning solution for CPFP (and SIGHASH_ANYONECANPAY) transactions. If
everything could use pure RBF, eg via pre-signed transcations, RBFR would be
much less useful.

> All we really need at this point is to enable package relay so that
> parent transactions are no longer subject to a dynamic mempool minimum
> when they're bundled with a high-feerate child.  Preliminary support for
> that should be released in the next major version of Bitcoin Core, with
> improved support being worked on for later releases.
> 
> Package relay is the only thing we need at this point because the
> existing LN protocol makes use of CPFP carve-out, which minimizes
> transaction pinning issues.
> 
> However, another substantial Bitcoin Core improvement, cluster mempool,
> is incompatible with CPFP carve-out.  TRUC is an alternative to CPFP
> carve-out that is easy to reason about, easy to use, more general in
> nature (good news for newer contract protocols), and which can possibly
> be automatically applied to existing LN onchain transactions, allowing
> cluster mempool to be deployed ASAP without requiring any significant
> changes to anyone else's software.

So as I explained in my stand-alone email, we can cleanly get rid of the CPFP
carve-out with RBFR *without* needing to change anyone else's software:

https://groups.google.com/g/bitcoindev/c/vfbF7QyVwPE/m/-ewtlB5-AQAJ

TRUC does _not_ allow cluster mempool to be deployed ASAP. It requires all
existing L2 protocols that need the CPFP carve-out to upgrade, and likely close
and reopen channels.

This is a massive downside to TRUC.

> As you've shown[2], the main downside of TRUC transactions (if we're
> going to depend on CPFP-style fee bumping anyway) is that users of TRUC
> transactions who have a malicious counterparty might need to pay a
> slightly higher onchain feerate than they would need to pay under the
> same situation with CPFP carve-out.  However, the increase is small
> enough that most honest parties should be able to afford it, so there's
> no incentive for a counterparty to do it.

As I explained months ago, the oddly high 1000vB limit chosen in TRUC allows
attackers to make TRUC users pay significantly higher fee rates in many mempool
situations, including the situation we are in right now:

https://petertodd.org/2023/v3-txs-pinning-vulnerability

At the moment, a typical TRUC using LN transaction can, IIRC, be forced to pay
something like a 4x higher fee as the difference between "will confirm in the
next block" and "won't confirm for days, if ever", is less than 1sat/VB.

I suggested that limit be reduced to something closer to a typical CPFP
use-case, and my suggestion was rejected.

This gets even worse with keyless ephemeral outputs using TRUC, as *anyone* can
itercept one of those and create a pin. An attacker could, for example, run
compact block enabled nodes and simply wait for LN nodes using compact blocks
to broadcast keyless ephemeral output, CPFP-using transactions, detect those
transactions, and automatically pin them.

> The alternative to TRUC that you've proposed is replace-by-feerate
> (RBFr).  This is also compatible with existing LN transactions and it's
> conceptually super simple (I assume the code is too), which is
> wonderful.  However, it's downsides are:
> 
> 1. It fundamentally enables a significant amount of free relay.  I'll
>    sketch a super basic attack at the end of this email that costs 0.55
>    BTC per day ($67,000 USD) to 100x the amount of bandwidth used by
>    relay nodes.  I'm sure more efficient attacks are possible.

See my analysis at the end. You are analyzing the wrong thing, and missing the
fact that comparable attacks are already possible. Indeed, even attacks that
are probably much *worse*.

>    An attacker who is able to consume an excessive amount of relay node
>    bandwidth at relatively low cost may be able to create both
>    short-term and long-term problems for all Bitcoin users.  If the
>    created problems result in a rapid increase in user feerates, then
>    free relay attacks become cheaper due to low feerate transactions
>    being automatically evicted from the bottom of the mempool.

Relay bandwidth and fee-rates don't have any direct connection in Bitcoin Core.
Fee-rates are set by users outbidding each other. Unless an attacker is willing
to outbid actual user transactions, paying money to do so, they can't make
fee-rates increase (modulo certain exploitable/broken fee-rate estimators
making bad assumptions about mempools, but that's not a new problem).

> 2. It may allow empting the mempool at relatively low cost.  An attacker
>    sending just 750 transactions at the top mempool feerate can
>    guarantee eviction of every honest user's transactions.  The attacker
>    can then replace 300 MB of transactions with a single 43,179 vbyte
>    transaction.  Even if the replacement transaction pays 100
>    sats/vbyte, when you compare that to the 1,000,000 vbytes of
>    next-block transactions each miner lost, the miner is only earning an
>    effective feerate of 4.3 sats/vbyte.

I covered that attack in my one-shot RBFR writeup:

https://petertodd.org/2024/one-shot-replace-by-fee-rate#fill-and-dump-attack

It's not a concern for a few reasons:

0. It's a class of attack that is already possible without RBFR: obviously, you
   can fill and dump by simply double-spending your fill transactions. Eg, this
   is obviously easy to do with full-rbf!

1. One-shot RBFR - my actual incentive-compatible proposal - is not vulnerable
   to fill-and-dump attacks the way you described, as you can't "dump" the top
   of the mempool with one-shot RBFR. The "dump" transactions won't be
   accepted, as one-shot RBFR only allows you to replace transactions with a
   low fee-rate that won't be mined in the near future.

2. Miners routinely run with much larger mempools than normal nodes. As I
   mentioned elsewhere, in my discussions with miners, mempools of 1GB or more
   were common.

3. Rebroadcasting is easy. Anyone can rebroadcast previously broadcast
   transactions. If people actually tried fill-and-dump attacks, all they'd
   succeed in doing is briefly kick out some transactions from typical
   mempools, at the cost of creating a bunch of higher fee-rate transactions
   that will most likely get mined at great expense to the attacker.

>    Further, it's easy to imagine situations where evicting
>    time-sensitive transactions from mempools might allow theft of funds
>    in excess of a few thousand dollars (my immediate thoughts go to
>    situations involving watchtowers).

Watchtowers are actually a uniquely *bad* example. Recall that watchtowers
merely broadcast pre-signed justice transactions in response to a revoked
commitment transaction being mind. AFAIK, all existing watchtower
implementations pre-sign the transactions with a fixed, high, fee-rate. What
they actually should do is provide the watchtower with multiple pre-signed
transactions at different fee-rates, up to the economic maximum. But I digress.

As explained above, rebroadcasting is trivial, and watchtowers are expected to
run 24/7 anyway. Secondly, one-shot RBFR prevents the replacement of any
transaction that is expected to be mined soon. So if the justice transaction
was signed with a high enough fee-rate to get mined, the only thing the
attacker can do is outbid it (and all transactions before it). Which is true
without RBFR anyway!

Finally, in general, while applications like Lightning are time-sensitive,
they're not *that* time sensitive. LND uses 144 blocks as its default CSV
delay, giving you an entire day to get a transaction mined. Doing fill-and-dump
attacks dozens of times in a row is not cheap.

> 3. Limiting the worst-case free relay and excessive mempool eviction
>    requires additional rules (e.g. one-shot RBFr) that are challenging
>    to implement and analyze at present, as several devs have noted[3].
>    Both implementation and analysis should become much easier if cluster
>    mempool is deployed (also noted by devs), but the deployment of
>    cluster mempool requires removal of CPFP carve-out, and removal of
>    CPFP carve-out requires either the upgrade of thousands of LN nodes
>    and channels or a drop-in solution (ideally one that can be analyzed
>    independently from cluster mempool, like TRUC).

As I explained separately, you are very incorrect in your description of the
CPFP carve-out. In fact, it's RBFR that is our only path to having a cluster
mempool without requiring existing applications to upgrade.

As for implementation, it is true that implementing one-shot RBFR is harder
without a cluster mempool. But fee estimation is something Bitcoin Core already
does. It would be fine to either 1) re-use the fee estimation machinery to get
a reasonable minimum one-shot fee-rate, 2) periodically generate a block and
use the minimum fee-rate of that block. Mempools aren't a consensus, so it
simply isn't necessary for every mempool to agree exactly on what the minimum
one-shot fee-rate is, for the same reason that it's not necessary for every
mempool to agree on the same minimum relay fee-rate.

> > this is quite an odd case of Core politics
> 
> I began writing this reply to force me to examine your claims for
> myself.  You have a long history of noticing things other people missed.

Thanks!

> A simple free relay attack using RBFr
> 
> ## Constants
> 
> 100,000 vbytes == ~400,000 bytes
>   A 1-input, 1-output P2TR scriptpath spend with the maximum amount
>   of witness data allowed by Bitcoin Core defaults
> 
> 111 vbytes == 162 bytes
>   A 1-input, 1-output P2TR keypath spend
> 
> ## Attack
> 
> - Attacker obtains 500,000 UTXOs
> 
> - For each UTXO
> 
>   - At the dynamic mempool minimum, broadcasts a 100,000 vbyte (400,000
>     byte) transacton.
> 
>   - Waits for it to propagate.
> 
>   - At 1.25x the dynamic mempool minimum, broadcasts a RBFr replacement
>     that is 111 vbytes (162 bytes).
> 
> ## Analysis
> 
> - At 162 bytes each, 500,000 transactions is 81 MB.  I think that will
>   fit in a default-sized mempool.
> 
> - The total amount of transaction data relayed is 500_000 * (400_000 +
>   162), or about 200 GB.
> 
> - The typical daily bandwidth requirement of a blocks-only node is
>   roughly 2.5 MB * 144, or about 0.36 GB per day.  Ideally a relaying
>   node is about the same due to compact blocks, but realistically, it's
>   a small multiple of that.  Call it 2 GB per day.
> 
>   - This implies the attack push each RBFr relay node to use 100x a
>     non-RBFr relay node.
> 
> - At 111 vbytes each, 500,000 transactions is 55.5 million vbytes.  At
>   my nodes current mempoolminfee (1 sat/vb), that's 55.5 million sats,
>   or 0.55 BTC (about $37,000 USD).
> 
> - This analysis ignores the cost of obtaining the UTXOs and possibly
>   later consolidating them, but it also ignores some easy optimizations
>   such as batching the replacements.
G
First of all, subtlety of the class of attack you are describing is it matters
a lot whether or not you expect the double-spend transactions to be mined in
the near future.

With one-shot RBFR - my actual proposal for Bitcoin Core - the fee-rate of the
double-spend is required to be sufficiently high to be likely to be mined in
the near future. With pure RBFR, which is implemented in Libre Relay as an
_experiment_, the double-spend merely needs to be a higher fee-rate. This
difference is one reason why I'm not proposing that Core actually implement
pure RBFR!

So the relevant question is, can you pull off this class of attack with Bitcoin
Core's current relay rules? The answer is absolutely yes. The only significant
difference is you'll be invalidating the big, "fill", transactions with
transations paying economic fee-rates, either in a block, or likely to soon be
in a block. Thus one-shot RBFR makes no difference: the same class of attacks
are possible whether or not it exists.


Secondly, your attack requires $37,000. That amount of money would pay for
2700TB of bandwidth at 0.01 USD/GB, the (expensive!) cost of bandwidth on
Digital Ocean.  There's about 20,000 publicly accessible nodes. So for that
amount of money, you could just DoS attack all 20,000 nodes simultanously with
about 185GB of data each. Digital Ocean is a very expensive way to get DoS
attack bandwidth, so realistically an attacker would probably pay even less for
the attack.

Even worse, you could use that bandwidth to perform a conflicting transactions
attack. For each publicly accessible node, broadcast a different,
100,000vB/400,000B, transaction spending the same UTXO. Each node will waste
bandwidth telling it's ~100 peers (including non-public nodes) about that
transaction, reducing the attackers bandwidth cost by a factor of ~100.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zp6TTAJ399CKbY5s%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]

On Mon, Jul 22, 2024 at 06:43:14AM -1000, David A. Harding wrote:
> On 2024-07-22 01:45, Peter Todd wrote:
> > TRUC meanwhile isn't even a drop-in solution, and requires everyone to
> > upgrade before cluster mempool is even possible.
> 
> The proposed BIP for TRUC[1] is indeed entirely opt-in and would require
> all users of CPFP-CO (e.g. LN anchors channels) to upgrade their
> software and switch to a new commitment transactions format, which
> currently requires closing and reopening all anchors channels.  There's
> work on improving upgrade mechanisms in LN, but it would still be a pain
> and a major delay to cluster mempool to depend on every LN user
> upgrading.
> 
> However, there has also been significant discussion and analysis[2] of an
> imbued-semantics form of TRUC that could be retroactively applied to
> LN-style anchor outputs (which are the only users of CPFP-CO we know
> about).  In that case, nobody needs to upgrade before cluster mempool
> becomes possible.
> 
> In my previous email, I assumed you were familiar with the imbued
> semantics proposal; I'm sorry for the miscommunication.

I am aware of that proposal. It is not a proposal with "significant discussion
and analysis", your link, [2], has three posts in total, with discussion ending
in Febuary, with only the OP having any significant content. Both replies to
the idea noted potential incompatibilites with existing implementations. I'm
not aware of any running code nor any significant discussion amongst LN
implementations and other stakeholders. The idea hasn't even been posted to
this mailing list.

That's why I never brought it up: the idea seems to have died out.

Frankly, unless you can point to actual "significant discussion and analysis"
of the idea, it's dishonest and toxic of you to portray it as such as you
should know better. RBFR has had more "significant discussion and analysis"
than this idea in this very thread.

Personally, I think it might not be an unreasonable hack before something
better like RBFR gets implemented. But it's only a hack. And if anything, it
strongly suggests that actually permanently specifying TRUC/V3 is an
unnecessary complication.

> -Dave
> 
> [1] https://github.com/bitcoin/bips/blob/158acdbbbf8ef13f6b345b6281a96e88e20d2cf9/bip-truc.mediawiki#user-content-Specification
> [2] https://delvingbitcoin.org/t/analysis-of-attempting-to-imbue-ln-commitment-transaction-spends-with-v3-semantics/527

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zp674YtMTaUX3imH%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not

[David A. Harding]

On 2024-07-22 10:06, Peter Todd wrote:
> can [you] point to actual "significant discussion and analysis"
> of the idea

The idea for imbued TRUC was developed in part during a live
discussion with LN maintainers:
https://btctranscripts.com/lightning-specification/lightning-2024-01-15-specification-call/

I'm aware of three discussions about it on the Delving Bitcoin Forum:

- 
https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418/2
- 
https://delvingbitcoin.org/t/sibling-eviction-for-v3-transactions/472#benefits-1
- (as previously linked) 
https://delvingbitcoin.org/t/analysis-of-attempting-to-imbue-ln-commitment-transaction-spends-with-v3-semantics/527

Each of those discussions was summarized by a Bitcoin Optech Newsletter,
a publication read by many Bitcoin and LN protocol developers
(disclosure: I co-author the newsletter):

   "Adding this policy and automatically applying it to current LN 
anchors
   will allow the CPFP carve-out rule to be removed, which is necessary 
for
   cluster mempool to be implemented, which should allow making
   replacements of all kinds more incentive-compatible in the future."

   
https://bitcoinops.org/en/newsletters/2024/01/31/#kindred-replace-by-fee

   "Imbued v3 logic: In response to concerns voiced in the LN spec 
meeting
   that it may take a long time for LN to design, implement, and deploy
   these changes, Gregory Sanders proposed an intermediate stage with
   temporary special treatment of transactions that look like current
   anchors-style LN commitment transactions, allowing Bitcoin Core to
   deploy cluster mempool without being blocked by LN development."

   https://bitcoinops.org/en/newsletters/2024/01/24/#imbued-v3-logic

   "[...] research into the idea of automatically applying v3 transaction
   relay policy to anchors-style LN commitment and fee-bumping 
transactions
   (see Newsletter #286 for the underlying imbued v3 proposal)."

   
https://bitcoinops.org/en/newsletters/2024/02/14/#what-would-have-happened-if-v3-semantics-had-been-applied-to-anchor-outputs-a-year-ago

The word "imbue" is mentioned in 7 separate posts by 4 separate authors
in a Bitcoin Core discussion issue that includes comments from three
different LN implementation maintainers plus @petertodd, who I assumed
was you: https://github.com/bitcoin/bitcoin/issues/29319

That thread also links to a draft implementation of imbued v3, which was
used for the Analysis forum post:
https://github.com/bitcoin/bitcoin/pull/29427

As discussed in the "sibling eviction" thread (summarized in the
2024-01-31 newsletter), one of the necessary parts for imbued TRUC to be
effective at replacing CPFP-CO is sibling eviction.  A version of that
(currently only for opt-in TRUC) was merged into Bitcoin Core several 
months
ago: https://github.com/bitcoin/bitcoin/pull/29306

I note that none of the above was hidden or hard to find.  All three of
the discussion summaries quoted above are linked on the Bitcoin Optech
topic page about v3 relay/TRUC, and two of them are also linked on the
topic pages about CPFP-CO and anchor outputs.  Most of the other stuff I
found by searching the bitcoin/bitcoin repository for the word "imbue":

- https://bitcoinops.org/en/topics/version-3-transaction-relay/
- https://bitcoinops.org/en/topics/cpfp-carve-out/
- https://bitcoinops.org/en/topics/anchor-outputs/

> Frankly, unless you can point to actual "significant discussion and 
> analysis"
> of the idea, it's dishonest and toxic of you to portray it as such as 
> you
> should know better.

I'm sorry you've been unable to keep up with protocol development and
are confusing that for me being dishonest and toxic.  May I suggest you
subscribe to the weekly Optech newsletter?  It's free.

-Dave

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/6c222c758e10e8061ccdcc180b1826a3%40dtrt.org.

Re: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]

On Mon, Jul 22, 2024 at 12:08:28PM -1000, David A. Harding wrote:
> > Frankly, unless you can point to actual "significant discussion and
> > analysis"
> > of the idea, it's dishonest and toxic of you to portray it as such as
> > you
> > should know better.
> 
> I'm sorry you've been unable to keep up with protocol development and
> are confusing that for me being dishonest and toxic.  May I suggest you
> subscribe to the weekly Optech newsletter?  It's free.

Ironically, while toxicly and dishonestly accusing me of being "unable to keep
up with protocol developments", you proved I was in fact quite aware of imbued
TRUC around the same time it got it's mention in Optech, and was even involved
in the short discussion of it.

Anyway, I'll stand by my earlier comment: the fact is the imbued TRUC proposals
are currently dead, and never received significant discussion and analysis. I
did forget about the fact that a draft pull-req was made. But that pull-req was
a mere draft and the author has abandoned it without responding to critique,
and only a few weeks after authoring it, even said on Feb 28 that "I would also
prefer to not merge the imbued v3 patch.":

https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1969122250

...and one of the LN maintainers queried explicitly argued against it, saying,
among other things, "I'm not a fan of merging hacky, temporary code into
bitcoin core to be honest.":

https://github.com/bitcoin/bitcoin/issues/29319#issuecomment-1968709925

Notice how that's an issue where I commented something like a half dozen times,
including after the author of imbued TRUC gave up on it.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/Zp%2BUAAtYDBqcgzEd%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 14217 bytes --]

Hi Ava,

Thanks for the additional thoughts.

> Peter was not the only "senior" person on the security list. Obviously I
> will not disclose non-public information, but certainly there are people
> on the security list who are just as, if not more, senior than Peter.

Apart of sipa (who is arelady public on the security.md), I think they are
2 more people with whom I had experience of interacting on the list that I
think are as much "senior" than Peter, both of them from public notoriety
and on their own declaration they are less active in bitcoin protocol 
development
(while they keep my reasonable trust if I have to report security 
information).

Apart of those 3 people, I don't see who is most senior than Peter in 
bitcoin
protocol development, and who an equivalent track records in matters of 
adversarial
exploitation, consensus changes and use-cases protocol design (as one needs 
a bit
of understanding of the "userspace" when you're handling issues).

I won't be a jerk to disclose in public people who I think are actually on 
the list,
and that you might think off in saying "just as", and here I have practical 
experiences
with a lot of people in the space who have been there since satoshi time or 
after.

> Furthermore, the "old parts" still do get changed, and someone who no
> longer actively contributes to the project is more likely to be unaware
> of how the code actually works today, even if they are familiar with
> components that change infrequently.

This is not incorrect to say that "old parts" get changed, though the 
frequency
is far from being exceptional and the substantial changes are pretty rare. 
If you
take few iconic files and you run stats (all no merges):
- net_processing.cpp, initial file creation 2016, number of commits 926, in 
average 115 changes yearly
- validation.cpp, initial file creation 2016, number of commits 1075, in 
average 134 changes yearly
- scheduler.cpp, initial file creation 2015, number of commits 47, in 
average 5 changes yearly
- interpreter.cpp, initial file creation 2014, number of commits 145, in 
average 14 changes yearly

One can certainly run more line code stats diff changes at each year point 
to get a
granularity how much substantial changes they are and if they are any trend 
like
subsystem being more stable than other.

Validation and net processing are obviously beefy files ongoing regular 
changes (as there has never
been a patchset landing successs of the many attempts from many authors to 
break them further like
#13413, #16175 and #18963). And what of substantial abstraction have been 
introduced in the past years
in validation ? Package support and a lot of block-relay mitigations and 
cleanup, not something like crazy.

Consensus and its interfaces has by far has a rythm of upgrades more slow, 
for an ecosystem impact
de-multiplied in case of issues (and it's harder to evaluate they might 
have "horizontal" effect on
use-cases like timelocks). Like I was saying evaluating who is active on 
single-digit years timelines
(and more probably 2 than 9) is short-sighted, and this does not match 
practical experiences in other
top open-source codebases like linux kernel.

There is not only a necessity to be aware of how the code actually works 
today, though also the
undocumented or unforseen scope of things like past attacks vectors or 
plausible past misinteractions.

I think this something that Peter full disclosure illustrates well as more 
"junior" security list recipients,
whatever their competency and goodwill, have failed to point out a type of 
class of attack that have come
again and again in discussions about mempool rebroadcast years ago (see the 
PR link I was pointing out in
one my Dave answer above).

> Not being on the list does not preclude him from being consulted if the
> need arises.

"If the need arises" supposes a lot, as first it assumes the report 
timeframes give you leeway to come as more
or less group decision to share the sensitive information to someone like 
Peter, being a default recipient
it's always faster (one might have to deal with situations where the 
security flaw is already half-mentioned
in public and it's better to act fast).

Secondly, "if the need arises" is a technical judgement in itself. One 
worst-case scenario could be for all
the default recipients reading a no-spam report, though missing an angle of 
exposure or that actually it's
a serious attack vector. It did happen to me on the lightning side in the 
past as I pointed out the general
vulnerability and someone cc after comes up with novel observations that 
were worsening the issues, or any
hardening fix of it.

> With the two examples you provide, I am not aware of Peter being
> actively involved in the resolution of both of those, whereas there are
> current members of the list who were.

They were given as examples of situations where you prefer to have too much 
competent and responsible
security list recipient that far too less, as both have temporal 
contengencies far beyond the scope of
bitcoin core list to deal with them (the first as the DB-switch provoked 
fork was already happenin, the
second as the report was from a bitcoin core fork coin).

On the list of people being actively involved in the resolution of them, or 
who got privileged access
to information before disclosure, from my experience they're some names 
that I must say can be a bit
sloppy in terms of reactiveness and implications in security issues 
resolution (whatever the independent
fact they're very skilled bitcoin engineers and pretty good reviewers).

> In general though, it is not clear to me how it was beneficial to have
> Peter on the security list, nor how not having him is directly harmful.
> In the 2 years that I have been on the security list, I was unaware that
> Peter was a recipient until shortly before he was removed. My
> understanding is that others who have been on the list longer than me
> were also unaware.

Personally, I think Peter has still one of the most furnished track records 
in bugs findings around the mempool
(the segwit malleability PR #8312) and understanding of all timelocks 
issues with the authorship of bip65, which
is critical for contract protocols. That one disagrees with another 
security list member on its public technical
opinions for newer changes, I think it's something one has to abstract when 
all security issues handlers are coming
together to bring a mitigation to the issue.

That one can be too much "cowboy" in matters of timelines full disclosure, 
which I think have been a bit about the
last 3 "free relay" disclosure, the best you can do is say so either 
publicly, or privately in all courtesy. No way
to make progress on responsible disclosure standards, if no one never 
speaks up.

I was aware that Peter was on the list from conversations years ago with 
him on a reported issue, far before
all the present topics about V3 / TRUC / RBFR have been raised. In my 
understanding, the fact that you were unaware
that Peter was on the list can only reinforce impression had a very slow 
pace in terms of security issues fixing,
especially when it's coupled with the disclosure of all issues of past 
months with which you have been involved.

My number one recommendation would be to make the list of default security 
list recipient public, as it would
create more personal accountability (both internally among the list 
recipient and externally towards the security
issues reporters / the wider community) and you can have a key fingerprint 
for each one which is good in terms of process.

I certainly don't wish to pour the blame on anyone specifically, as I think 
the current "so-so" state of security
issues handling by bitcoin core has been more a background result of all 
the ups and downs of blocksize wars time,
where contributors didn't focus on it sufficiently. Yet, I think it's very 
beneficial to think more about this process,
before we see either more funds at stake with contract protocols and other 
applications (as it was well pointed out by one
of the optech newsletter and sadly too known by lightning protocol devs, 
what can be a medium severity on the base layer
like transaction-relay censorship vector is very likely a high severity on 
upper layer).

Best,
Antoine
ots hash: b8b4ce2cbed73ef7036bc7d7ebe67c325ff0b0f9336ac480c49d9036c2e40736

Le dimanche 21 juillet 2024 à 21:49:10 UTC+1, Ava Chow a écrit :

> On 07/20/2024 10:06 PM, Antoine Riard wrote:
> > "Naive", as saying this is the _Bitcoin Core_ project list only can only 
> > provoke blind
> > spot among the list members if the security issues are either affecting 
> > old part of
> > the codebases that younger members have less experiences with (some 
> > parts like consensus
> > or block-relay are modified only every 5 years) or novel factors from 
> > upstream or downstream
> > (e.g the internet networking stack or implications on deployed contract 
> > protocols like
> > lightning). On both the former and latter criterias, I think Peter 
> > overly meets the bar.
>
> Peter was not the only "senior" person on the security list. Obviously I 
> will not disclose non-public information, but certainly there are people 
> on the security list who are just as, if not more, senior than Peter.
>
> Furthermore, the "old parts" still do get changed, and someone who no 
> longer actively contributes to the project is more likely to be unaware 
> of how the code actually works today, even if they are familiar with 
> components that change infrequently.
>
> > When you've big sh*t hitting the fan like inflation bugs or level DB 
> > 2013 unexpected fork you
> > prefer have experts with a decade of experience to collaborate with, and 
> > sharing the same cultural
> > and ethical norms of the active contributors evaluated by numbers on 
> > commits on the last single-digit
> > years.
>
> Not being on the list does not preclude him from being consulted if the 
> need arises.
>
> With the two examples you provide, I am not aware of Peter being 
> actively involved in the resolution of both of those, whereas there are 
> current members of the list who were.
>
>
> In general though, it is not clear to me how it was beneficial to have 
> Peter on the security list, nor how not having him is directly harmful. 
> In the 2 years that I have been on the security list, I was unaware that 
> Peter was a recipient until shortly before he was removed. My 
> understanding is that others who have been on the list longer than me 
> were also unaware.
>
> Ava
>
> > 
> > I'll repropose Peter admission on the security list mailing list in the 
> > coming weeks by opening an
> > issue on the bitcoin-meta repository, once this current mailing list 
> > thread has slowed down a bit,
> > or at least the technical analysis has been dissociated from the 
> > proceedings which have all been
> > bundle in a big message. In my very personal opinion, I still trust more 
> > Peter competence and experience
> > than some other people I know who are on the security mailing list.
> > 
> > All that said I appreciate your answer and I'm satisfied from the 
> > personal role you've have played
> > in the matter with, and be reassured I'll keep you among the recipient 
> > of future security issues with
> > a potential impact on bitcoin core that I might find or be aware off.
> > 
> > Best,
> > Antoine
> > ots hash: 
> db441b51684ad3a6897f67d42c74ccfcb9a4ffed40d4bdbe30a2edd867ccdd54
> > 
> > Le samedi 20 juillet 2024 à 01:50:25 UTC+1, Ava Chow a écrit :
> > 
> > On 07/19/2024 07:58 PM, Antoine Riard wrote:
> > > As said in one my previous email, I'm still curious about achow101
> > > explaining publicly
> > > why you have been kicked-out of the bitcoin-security mailing
> > list, when
> > > you were certainly
> > > more senior than achow101 in matters of base-layer security
> > issues or
> > > even hard technical
> > > issues like consensus interactions (e.g bip65). I'll re-iterate my
> > > respect towards achow101
> > > as a maintainer from years of collaboration, though this is a topic
> > > worthy of an answer.
> > 
> > I am not the one that removed Peter from the mailing list, nor do I
> > even
> > have the login(s) to do so.
> > 
> > There was a discussion amongst several members of the security list
> > about who was on the list, and who should be on the list. Given that
> > the
> > security list is the _Bitcoin Core_ security list, we determined that
> > the people who should be on the list are people who still actively
> > contribute to the project. As Peter Todd no longer actively contribute
> > code nor code review to the project, we decided that it didn't make
> > sense to continue to have him on the list.
> > 
> > My recollection is that multiple other people were removed from the
> > list
> > for the same reason at the same time.
> > 
> > Ava
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "Bitcoin Development Mailing List" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to bitcoindev+...@googlegroups.com 
> > <mailto:bitcoindev+...@googlegroups.com>.
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com 
> <
> https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
>
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/f9d17558-4b74-401b-bb64-fed34bd46619n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 16769 bytes --]

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 6935 bytes --]

Hi Dave,

> Weak blocks also provide a decentralized DoS-resistant mechanism for
> voluntarily communicating all sorts of information from miners to other
> miners and relay nodes. That makes them an excellent tool for resolving
> any attack that depends on miners and relay nodes having a divergent set
> of transactions.

I think the mechanism you're describing is plagued by the following 
vulnerability:
- an attacker mempool-partition all miners by exploiting transaction-relay 
asymmetries (e.g same feerate, same weight, diff txid)
- an attacker broadcast an appealing transaction entering the top of mempool
- a weak block up to 4MB is generated for each such miner partitioned and 
relayed to the rest of the network
- the whole block-relay network is wasting 4 MB of block-relay bandwidth 
multiplied by N, the number of miners affected
- the mempool-partitition transaction vector might have paid a sub-minimal 
feerate just to enter in mempool

Bonus point: the attacker has hashrate capabilities to mine the block 
including the mempool-partition transaction vector
rendering a null gain for the DoSed miners whatever the weak block reward 
mechanism for the "weak block" proposal (unless
the reward is exogeneous to the bitcoin blockchain, a type of in-protocol 
reward one might skeptical relatively to bitcoin
security model).

I don't think the "weak block" proposal as you're presenting it makes 
sense, at the very least quantitative evaluations
would be necessary to be sure you're not worsening the denial-of-service 
aspect. In the present layout of the "weak block"
proposal, I really think you saying it's a decentralized DoS-resistant 
mechanism is deeply misleading and inaccurate for
the rest of the community.

Zooming out, I believe it's an intesresting problem wishing to improve 
rewarding of miners income if we wish to encourage
solo miners, and improve on the initial financial liquidity incentives that 
are driving miners to gather themselves in pool
since the early days of bitcon, though I don't see how "weak block" can be 
a viable solution.

Best,
Antoine
ots hash: 85636ac4e91bc781bbcdc8c0a24a17ad1c90039c6cabbb4d3ddd334c2c29fc02 

Le dimanche 21 juillet 2024 à 19:04:29 UTC+1, David A. Harding a écrit :

> On 2024-07-20 05:03, Peter Todd wrote:
> > What other "free" relay attacks can you think of that were fixed?
>
> The two you mention were the two I had in mind.
>
> > Did you actually read my One-Shot RBFR proposal?
>
> Yes. It didn't provide any examples of RBFr free relay and I wanted to
> see whether a basic RBFr free relay attack would use significantly more,
> significantly less, or about the same amount of bandwidth per dollar
> spent as other free relay attacks. My conclusion is that it's about the
> same.
>
> > Weak blocks are not a solution to any of the "free" relay attacks I've
> > disclosed and your source does not claim that they are a "free" relay
> > solution.
>
> It does not explicitly say that, but it does say: "bonus use-cases:
> “Forcible insertion” of transactions that are incentive-compatible but
> violate anti-DoS rules".
>
> For example, in some of the scenarios you describe, the attacker sends
> an appealing transaction to miners and then sends less appealing
> versions of that transaction to relay nodes. If the appealing
> transaction enters the top mempool and gets included in a weak block,
> relay nodes will stop relaying less appealing variations minutes to
> hours before they otherwise would.
>
> Weak blocks also provide a decentralized DoS-resistant mechanism for
> voluntarily communicating all sorts of information from miners to other
> miners and relay nodes. That makes them an excellent tool for resolving
> any attack that depends on miners and relay nodes having a divergent set
> of transactions.
>
> > 1) Have you've read my One Shot RBFR proposal? In particular, my
> > analysis of DoS attacks *including* existing DoS attacks like
> > simultaneous broadcast.
> > 
> > 2) Do you agree or disagree with me that these existing DoS attacks
> > are real?
>
> Yes, I've read your proposal, and I agree those attacks are plausible.
> In my mind, the major difference between those free relay attacks
> and RBFR free relay attacks is how solvable they are.
>
> I think it's easy to sketch a significant mitigation to all free relay
> attacks (including RBFR):
>
> - Reduce the maximum size of both relayable transactions and in-mempool
> packages, e.g. from 100,000 vbytes to 1,000 vbytes.
>
> - Reduce the maximum size of the mempool, e.g. from 300 MB to 10 MB.
>
> - Increase the default mempool feerate floor, e.g. from e.g. from 1
> sat/vb to 100 sat/vb.
>
> That would break relay of many existing presigned transactions,
> potentially leading to money loss, and would break other existing
> usecases, not to mention introduce other problems. However, I think
> it's sufficient to prove that a mitigation to free relay is possible
> without rendering the network unusable.
>
> Of course, an ideal solution wouldn't require placing any additional
> constraints on mempool policy. For the case of free relay due to
> divergent mempool policies, maybe it's something that could be done with
> transaction set reconciliation (~erlay), functions for allowing
> independent nodes to come to consistent conclusions about the best
> revenue set of transactions (~cluster mempool), P2P relay of non-obvious
> cluster linearizations[1], and miners voluntarily committing to their
> mempool contents in candidate blocks and P2P relaying those commitments
> in weak blocks.
>
> Innovations like that don't work for RBFR. If mempool policy is kept
> the same, free relay attacks with RBFR remain equally effective no
> matter what mechanisms we implement to improve preconsensus consistency.
>
> If pure RBFR is added and clever protocol developers find ways to
> largely fix other free relay attacks, then devs will either need to
> significantly restrict mempool policy anyway or will need to restrict or
> remove RBFR to make Bitcoin Core safe. Given that, it seems to me like
> a very reasonable decision not to add pure RBFR and to wait until better
> tools like cluster mempool become available before evaluating
> significant changes to RBF policy (like one-shot RBFR).
>
> Thanks,
>
> -Dave
>
> [1] 
>
> https://github.com/bitcoinops/bitcoinops.github.io/pull/1421#discussion_r1415834695
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/1d64b24e-9ae4-4eac-b93a-c35fdcd26d6en%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 8201 bytes --]

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 13034 bytes --]

Hi Peter,

> An irony here is that rebroadcasting makes most "free" relay attacks 
*more*
> expensive, not less. sdaftuar had some correct points, like avoiding 
bandwidth
> spikes. But for any "free" relay attack based on broadcasting conflicting
> transactions at different fee-rates, where the higher fee-rate 
transaction is
> not mined, you get a better attack if the higher fee-rate transaction 
falls out
> of node mempools, allowing the lower fee-rate conflict to be broadcast 
again.
> 
> If rebroadcasters ensure that nodes have the higher fee-rate tx, all you 
can do
> to "reset" the attack is either get your UTXO(s) mined. Or use an even 
higher
> fee-rate. Without rebroadcasting, you can wait for the expiry period to be
> reached.

I read again my review comments on that PR, and what I noticed at the time 
is
how automatic rebroadcasting might provoke "free" relay attacks among a set
of mempools with different sizes. If you have mempool A at 100 MB and 
mempool
B at 400 MB, assuming the top 100 MB of feerate is of same quality, the 
full diff
of 300 MB of transaction-relay bandwidth is wasted between peers A and B. An
attacker can still have to chain transactions to bypass bip133 fee filters.

So yes, I think rebroadcasting can be a benefice in face of some "free" 
relay
attacks, though far from most and it might worsen if you consider mempool 
sizes
asymmetries.

> Not just miners: any node running with mempoolfullrbf=1 is going to waste 
less
> bandwidth if someone actually does this attack.

If a majority of miners wouldn't run `mempoolfullrbf=1`, I think it would 
have
been a good empirical point that it doesn't increase average block income 
(and 
apart of any DoS vector for contracting protocols / multi-party 
applications).

In such world where a majority of miners are running with 
`mempoolfullrbf=1`,
yes the attack is a bandwidth waste at any `mempoolfullrbf=1` / 
`mempoolfullrbf=0`
transaction-relay partitions.

> RBF is way underused in protocols in general. And there have probably been
> literally millions of dollars wasted on fees spent by inefficient CPFP
> solutions when RBF (via pre-signed transactions) could have been used 
instead.
> This financial figure will only get higher as Lightning gets more 
adoption. It
> also limits Lightning in mass failure scenarios: every byte saved while 
force
> closing a channel is room that could be used to force close another 
channel.

This is correct that with each CPFP we have block chain space weight wasted.
I'm not going to say that RBF is a perfect solution for lightning and other 
off-chain
use-cases, as you have some other limitations (never took time to do a full 
public 
write-up here). Though yes it improves significantly lightning in mass 
failure
scenarios to have the most compact fee-bumping for commitment in a world 
where
block size is limited.

> I have to disagree here. The nature of protocols like Lightning is there 
is a
> maximum amount that it's worth attempting to pay to get a transaction 
mined to
> perform some action. There also a deadline to perform that action.
> 
> For example, an HTLC has a clear expiry time and value. *Even if* you 
have no
> idea what fee-rates are needed to get a transaction mined, you can simply 
do
> repeated RBF bumps at higher and higher fee-rates, ending at a fee-rate 
that
> spends the entire value of the HTLC. As long as you do in fact have 
uncensored
> access to miner mempools - as long as you haven't been sybil attacked - 
this
> approach will do about as well as is possible, modulo pinning attacks. So 
our
> job is now to simply fix the pinning attacks with better RBF policy.

"As long as you do in fact have uncensored access to miner mempools". This 
is
the caveat to highlight as an attacker can batch pinning effect by targeting
unrelated channels and occupying the same place in common mempools. 
Unrelated
channels have a limited fee-bumping budget to dedicate to fixed-amount 
HTLCs.

Such observation was spotted a while back in an old email post of mine on 
advanced
pinning vectors (dubbed "network-aware pinning") [0]

[0] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018011.html

This is correct that one can always have access to miner mempools, while 
completely
disregarding the public transaction-relay network, though here we're 
talking about
a different security model for lightning. We considered on the 
lightning-side that
approach to solve pinnings in the past here [1].

[1] https://github.com/lightning/bolts/issues/783

> IIUC, this RBF fee-bumping approach is exactly what the RBF sweeper 
introduced
> in LND v0.18 does. Face with, eg, high blockspace demand the sum total of 
LND
> RBF sweepers will result in the most valuable HTLCs and similar things 
being
> mined, while less valuable transactions don't (ignoring pinning of 
course).
> That's fine! That's the best we can do given a limited blockspace.

Doesn't work if you consider more advanced pinning vectors like "network 
aware pinnings".

> Traditional cryptography literature is not relevant here, as it's based 
on the
> difficulty of mathematical problems, not economics; the security of L2
> protocols is based on economics.

Traditional cryptography litterature not only based on the difficulty of 
mathematical
problems, though also on computational hardness assumptions e.g "assume no 
one can
efficiently find a preimage collison for 80-bits hash".

That L2 protocol security is based on economics (and physics) doesn't waiwe 
to do the
analytical work on the ressources assumptions beared on attacker to 
pragmatically
determine if an attack is realistic or not (though I don't think deep 
methodological
considerations alter the crux of the conversation about "free relay" 
attacks here).

Best,
Antoine
ots hash: 79f97742d76e6f349f2a881d8acc6afc8623d897472533272390ed9183baa5c5

Le lundi 22 juillet 2024 à 16:15:12 UTC+1, Peter Todd a écrit :

> On Sat, Jul 20, 2024 at 07:10:53PM -0700, Antoine Riard wrote:
> > 
> > Hi Dave,
> > 
> > Thanks for your thoughtful answer (even if its wasn't addressed to me 
> > primarly).
> > 
> > > I cannot imagine what would make you think that protocol developers are
> > > not concerned about attacks that could drive large numbers of relay
> > > nodes off the network for a cost easily affordable to any well-funded
> > > adversary.
> > 
> > From my experience code reviewing the wallet / mempool re-broadcast of 
> few
> > years ago, free tx-relay / bandwidth waste attacks were far to be 
> > understood 
> > or plainly weighted by some contributors of a newer generations, 
> including 
> > by
> > the own champion of the proposal. The proposal was finally abandonned 
> when a
> > more senior dev came up with quantitative analysis of code changes [0].
> > 
> > [0] https://github.com/bitcoin/bitcoin/pull/21061#issuecomment-851563105
>
> An irony here is that rebroadcasting makes most "free" relay attacks *more*
> expensive, not less. sdaftuar had some correct points, like avoiding 
> bandwidth
> spikes. But for any "free" relay attack based on broadcasting conflicting
> transactions at different fee-rates, where the higher fee-rate transaction 
> is
> not mined, you get a better attack if the higher fee-rate transaction 
> falls out
> of node mempools, allowing the lower fee-rate conflict to be broadcast 
> again.
>
> If rebroadcasters ensure that nodes have the higher fee-rate tx, all you 
> can do
> to "reset" the attack is either get your UTXO(s) mined. Or use an even 
> higher
> fee-rate. Without rebroadcasting, you can wait for the expiry period to be
> reached.
>
> > > In this case, you've found a specific instance (full-RBF vs signaled
> > > RBF) of a well-known general problem (optional policies leading to
> > > mempool inconsistencies, allowing free relay) and appear to be arguing
> > > that devs don't care about free relay because they refused to reverse a
> > > previous decision (to not change the RBF configuration default) that 
> has
> > > been hotly debated multiple times.
> > 
> > I think what is more interesting and noteworhty in the whole line of 
> > reaosning
> > of Peter with the present disclosure is how much the adversial effect is 
> > favor
> > by the supermajority of miners running `mempoolfullrbf` [1].
> > 
> > [1] https://github.com/bitcoin/bitcoin/pull/28132#issue-1817178316
>
> Not just miners: any node running with mempoolfullrbf=1 is going to waste 
> less
> bandwidth if someone actually does this attack. 
>
> > Under those conditions, where it took 9 years for the bitcoin core 
> project 
> > to disclosre
> > some vulnerabilitires, personally I'm more likely to understand that the 
> > bitcoin core project
> > is under-staffed is competent experts to keep public disclosure in 
> > reasonable timeframe (-- at
> > least equivalent to the kernel world), and as corollorary to fully 
> evaluate 
> > technical proposal
> > with all its strength and weaknesses.
> > 
> > Saying an "already overdiscussed issues that gets nobody closer to 
> > fundamental solutions" is
> > insulting for Peter, honestly.
>
> Indeed. You'd think solid evidence, trivially verifiable by anyone, that 
> almost
> all miners had adopted full-rbf would be enough. Instead that evidence 
> doesn't
> even receive any acknowledgement.
>
> > As an offchain protocol developers which has been involved in the 
> majority 
> > of technical conversations,
> > implementations and deployment of the "anchor output" upgrade, I believe 
> on 
> > the long-term CPFP-style fee-bumping
> > of contract protocol, including lighting, is not the most robust 
> technical 
> > solutions. I think anyone can check
> > in the bitcoin optech anchor output glossary the numerous 
> vulnerabilities 
> > that have plagued this fee-bumping 
> > solutions over the past years.
>
> RBF is way underused in protocols in general. And there have probably been
> literally millions of dollars wasted on fees spent by inefficient CPFP
> solutions when RBF (via pre-signed transactions) could have been used 
> instead.
> This financial figure will only get higher as Lightning gets more 
> adoption. It
> also limits Lightning in mass failure scenarios: every byte saved while 
> force
> closing a channel is room that could be used to force close another 
> channel.
>
> > I already reviewed some parts of cluster mempool. Fundamentally, 
> economical 
> > mempool pinnings for second-layers (bip125 absolute
> > fee) with pre-signed time-sensitive transactions arises from a world 
> where 
> > there is (a) an asynchronicity of mempools and (b) one
> > cannot guess feerates at block + 1 (-- let's say in a deterministic 
> fashion 
> > as understood by traditional cryptographic litterature
> > when doing cryptanalysis). Better RBF policies won't solve that, 
> including 
> > RBFr.
>
> I have to disagree here. The nature of protocols like Lightning is there 
> is a
> maximum amount that it's worth attempting to pay to get a transaction 
> mined to
> perform some action. There also a deadline to perform that action.
>
> For example, an HTLC has a clear expiry time and value. *Even if* you have 
> no
> idea what fee-rates are needed to get a transaction mined, you can simply 
> do
> repeated RBF bumps at higher and higher fee-rates, ending at a fee-rate 
> that
> spends the entire value of the HTLC. As long as you do in fact have 
> uncensored
> access to miner mempools - as long as you haven't been sybil attacked - 
> this
> approach will do about as well as is possible, modulo pinning attacks. So 
> our
> job is now to simply fix the pinning attacks with better RBF policy.
>
> IIUC, this RBF fee-bumping approach is exactly what the RBF sweeper 
> introduced
> in LND v0.18 does. Face with, eg, high blockspace demand the sum total of 
> LND
> RBF sweepers will result in the most valuable HTLCs and similar things 
> being
> mined, while less valuable transactions don't (ignoring pinning of course).
> That's fine! That's the best we can do given a limited blockspace.
>
> Traditional cryptography literature is not relevant here, as it's based on 
> the
> difficulty of mathematical problems, not economics; the security of L2
> protocols is based on economics.
>
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/db52123b-c5ec-4d6e-94c5-5a36bce186b7n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 15454 bytes --]

Re: [bitcoindev] RBFR makes the CPFP carve-out obsolete with cluster mempool, without upgrading LN nodes; TRUC/V3 does not

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 5413 bytes --]

Hi Dave,

> I'm sorry you've been unable to keep up with protocol development and
> are confusing that for me being dishonest and toxic. May I suggest you
> subscribe to the weekly Optech newsletter? It's free.

See my review comments on the imbuance mechanism PR on bitcoin core, I
think it's broken in the sense that you can escapce the imbuanche mechanism
by playing on commitment output scriptpubkye / amount collision.

Bitcoin core is a public project so you're free to access the 5 months old
comments now and make your own opinion. For now, I think there is no bitcoin
core code available for a robust imbuanche mechanism, so this whole roadmap 
thing you're presenting in your post or in the bitcoin optech newsletter I 
don't
know if it's technically sound, and not a bit misleading for the bitcoin 
industry
players periodically reading it.

Best,
Antoine
ots hash: a75c98ab5166c541ecba5e579639f359e82ff315df89b04264b29f8dfaa87502

Le lundi 22 juillet 2024 à 23:10:33 UTC+1, David A. Harding a écrit :

> On 2024-07-22 10:06, Peter Todd wrote:
> > can [you] point to actual "significant discussion and analysis"
> > of the idea
>
> The idea for imbued TRUC was developed in part during a live
> discussion with LN maintainers:
>
> https://btctranscripts.com/lightning-specification/lightning-2024-01-15-specification-call/
>
> I'm aware of three discussions about it on the Delving Bitcoin Forum:
>
> - 
>
> https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418/2
> - 
>
> https://delvingbitcoin.org/t/sibling-eviction-for-v3-transactions/472#benefits-1
> - (as previously linked) 
>
> https://delvingbitcoin.org/t/analysis-of-attempting-to-imbue-ln-commitment-transaction-spends-with-v3-semantics/527
>
> Each of those discussions was summarized by a Bitcoin Optech Newsletter,
> a publication read by many Bitcoin and LN protocol developers
> (disclosure: I co-author the newsletter):
>
> "Adding this policy and automatically applying it to current LN 
> anchors
> will allow the CPFP carve-out rule to be removed, which is necessary 
> for
> cluster mempool to be implemented, which should allow making
> replacements of all kinds more incentive-compatible in the future."
>
>
> https://bitcoinops.org/en/newsletters/2024/01/31/#kindred-replace-by-fee
>
> "Imbued v3 logic: In response to concerns voiced in the LN spec 
> meeting
> that it may take a long time for LN to design, implement, and deploy
> these changes, Gregory Sanders proposed an intermediate stage with
> temporary special treatment of transactions that look like current
> anchors-style LN commitment transactions, allowing Bitcoin Core to
> deploy cluster mempool without being blocked by LN development."
>
> https://bitcoinops.org/en/newsletters/2024/01/24/#imbued-v3-logic
>
> "[...] research into the idea of automatically applying v3 transaction
> relay policy to anchors-style LN commitment and fee-bumping 
> transactions
> (see Newsletter #286 for the underlying imbued v3 proposal)."
>
>
>
> https://bitcoinops.org/en/newsletters/2024/02/14/#what-would-have-happened-if-v3-semantics-had-been-applied-to-anchor-outputs-a-year-ago
>
> The word "imbue" is mentioned in 7 separate posts by 4 separate authors
> in a Bitcoin Core discussion issue that includes comments from three
> different LN implementation maintainers plus @petertodd, who I assumed
> was you: https://github.com/bitcoin/bitcoin/issues/29319
>
> That thread also links to a draft implementation of imbued v3, which was
> used for the Analysis forum post:
> https://github.com/bitcoin/bitcoin/pull/29427
>
> As discussed in the "sibling eviction" thread (summarized in the
> 2024-01-31 newsletter), one of the necessary parts for imbued TRUC to be
> effective at replacing CPFP-CO is sibling eviction. A version of that
> (currently only for opt-in TRUC) was merged into Bitcoin Core several 
> months
> ago: https://github.com/bitcoin/bitcoin/pull/29306
>
> I note that none of the above was hidden or hard to find. All three of
> the discussion summaries quoted above are linked on the Bitcoin Optech
> topic page about v3 relay/TRUC, and two of them are also linked on the
> topic pages about CPFP-CO and anchor outputs. Most of the other stuff I
> found by searching the bitcoin/bitcoin repository for the word "imbue":
>
> - https://bitcoinops.org/en/topics/version-3-transaction-relay/
> - https://bitcoinops.org/en/topics/cpfp-carve-out/
> - https://bitcoinops.org/en/topics/anchor-outputs/
>
> > Frankly, unless you can point to actual "significant discussion and 
> > analysis"
> > of the idea, it's dishonest and toxic of you to portray it as such as 
> > you
> > should know better.
>
> I'm sorry you've been unable to keep up with protocol development and
> are confusing that for me being dishonest and toxic. May I suggest you
> subscribe to the weekly Optech newsletter? It's free.
>
> -Dave
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/1d532e88-d40a-4417-bdac-6c4bbf90c26en%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 10651 bytes --]

Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 8801 bytes --]

Hi Anonymous,

Let's add more characterization by zooming out on a 15 years timeline on
the situation for an external observer less versed in usual bitcoin core 
development.

Historically, the project has been cared of by veteran of open-source 
projects,
old cypherpunks and other contributors used to security system engineering. 
While
qualms on technical proposals have always been heated even in the early 
days (e.g
the infamous OP_EVAL or bloom-filters bip37), at the very least 
protagonists in
the conversation were taking technical arguments at their sound value and 
killing
weak ideas when a majority of contributors have came to the same conclusion.

The resistant to the arguments, if they did not have the intellectual 
honesty to
fully appreciate arguments, were slowly moving out of contributing to 
bitcoin or
projects around to go work on fork-coins or something else. From my 
experience,
historically bitcoin had some of the most scientifically grounded and 
software
skilled contributors sweating hard and ready to risk their professional 
careeers
to make the bitcoin core codebase advance. There is a bit of subjectivity 
involved
here though I worked on code changes and review with some people since the 
early
days and if you take the "old guard" the level is here.

With time, especially after the block size war which have been intense 
whatever
the camp you have followed, some more "senior" core contributors have take 
a more
or less step back, without necessarily taking the time to fully transmit 
the same
level of technical and ethical standard to newcomers making their dents on 
the project.
This trend has only been worsen with the Faketoshi lawsuits, where even 
more "senior"
contributors have take a step back.

All those "senior" folks, of which Peter is a good specimen, where very 
okay when you
yelled at them that code was broken or a significant low-level proposal was 
weak and
it was better to fix them before to move forward. Without always 
necessarily caring
about following the utmost courtesy and politeness.

At the very same time of the end of the block size war and when faketoshi 
lawsuits where
taking the most of their toll among the contributors, there has been more 
the growth
of a culture of "professionalizing" the bitcoin core space. That have 
translated in a
number of dimensions, e.g we have started to seen a myriad of 
"money-helicopter" open-source
grants (most of the times attributed to hard working folks, sometimes 
giving the impression
that attribution has been done on more external "social" factors). In 
parallel, there
has been an emphasis in the core developnment process to ship complex code 
in low-level
subsystems, whatever the thoroughness of the design and code review, as 
landing complex
code not only make good story to tell on podcasts and twitter but it has 
also become a
self-sustaining argument to grap more open-source grants for some less 
regarding contributors.

(I don't know if a lot of folks are familiar with the school of public 
choice in economics
and the concept of rent-seeking capture, one can wonder if it's not a 
phenomena affecting
bitcoin open-source stage too. This is not saying that it's great to have 
folks on open-source
grants to handle releases, refactor the old parts of the codebase or write 
more tests,
I think just to be more far conservative when it comes to implementation of 
new mechanism and
minimizing the impact of incentives nurturing complacency).

With that accumulation of uncoordinated cultural changes, and open-source 
grants becoming
the norm as a mode of compensation among the majority of bitcoin core 
contributors (rather
than exercising their skills on the market or being good with their btc 
stack), in my
impression there has been more and more a wind of spontanous 
self-censorship arising among
the current generation of contributors. After all, what one would take the 
risk of being
far too negative or adverserial in the review of one's co-contributors 
patchset, when that
very co-contributor might judge for your grant re-attribution at the end of 
the year ?

Better to not take the risk, and if it's coupled with having a small btc 
stack even if there
is a major security failure X years from now, you wouldn't personally pay 
the cost as your
fiat-denominated grant will be still dump on you. All you have to do in 
case of security failure
is run away from any responsibility and engage in a heavy public 
relationship effort saying
everything is all right, bragging about the fact that you're a maintainer 
or that you've seen
worst in the past (were indeed you were not the ones doing the hard work at 
the time).

It might be a very personal opinion, though I think there have been a 
serious downgrade in
bitcoin core culture about technical proposals, where it was estimated that 
the code was broken
to a more current culture of first not making wawe and to be always 
"constructive" (even if no
ones knows exactly what does it mean to be constructive when a technical 
proposal has been analyzed
to be broken and when it's reasonably wiser to abandon months of 
engineering effort rather to
jeopardize end users funds safety) [0].

[0] https://github.com/bitcoin-core/meta/blob/main/MODERATION-GUIDELINES.md

Quote: "One can just have a look on the newer moderation rules, where it is 
explicitly said "on the
understanding that it is easier to rephrase deleted comments to be 
constructive and respectful
than to replace long term contributors who are burnt out from a discussion 
culture that is
unnecessarily contentious and overbearing" [0].

I think here some astute minds could observe that progress in the domain of 
scientific ideas if one
complete history on few centuries are driven a lot by controversy, 
overbearing experiments done again
and again and argumentation layout repeated multiple times in front of many 
audiences, as some brilliant
ideas might be counter-intuitive at first.

With all said and joining on your suggestion to fork core or have in-place 
multiple security
mailing lists. On the former this does not abstract from gathering enough 
dedicated experts
behind the same codebase, though more importantly maintaining a culture of 
collaboration among
the different full-node implementation. If it's go back to the situation of 
Bitcoin XT fork
and Bitcoin Segwit2X, where experts are fighting each other to "dictate" 
the consensus rules
this is not worth it. New civil war in bitcoin is a situation where 
everyone will be at loss.

On the latter suggestion, multiple security list is more or less already 
the current dynamics
as historically you had coordination among lightning implementations or 
with the mining ecosystem.
Whatever the reality of a single endpoint, at the end of the day it's more 
a "peer-to-peer" dynamic,
after a while you know you can personally trust and who is very skilled in 
area X or area Y or bitcoin. 

Degree and goodwill of collaboration is more important that the 
communication channel itself, as some
bitcoin core contributors reveals publicly recently what was more or less 
known in internal circles about
the project management of security issues [1]:

[1] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w

Quote: "The project has historically done a poor job at publicly disclosing 
security-critical bugs, whether externally
reported or found by contributors. This has led to a situation where a lot 
of users perceive Bitcoin Core as
never having bugs. This perception is dangerous and, unfortunately, not 
accurate."

I hope certainly there will be some cultural electro shocks, of which 
Peter's present disclosure email
can consistute an opportunity for a lot of people to medidate on, that we 
improve the security of the bitcoin
ecosystem at large by adopting good security issues handling process. And 
that before we're seeing massively
contract protocols and second layers being p0wned by North Korea sponsored 
hacking groups -- if the evidences
gathered by the wider cybersecurity community is correct on this front.

Reader beware - All those historical considerations on the evolution of 
bitcoin core culture only represents
my own opinion, this is necessarily the reflect of my subjective experience 
as a contributor and there is no need
to trust me.

Best,
Antoine
ots hash: a58adf148ac756bf5e0cb5cb44fdf6baf8874e71cc64df70a76d46a9472c6891

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/1f6d6917-01f1-496d-9c97-8513fce24149n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 9584 bytes --]

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[David A. Harding]

On 2024-07-20 16:10, Antoine Riard wrote:
> If you or anoyone think TRUC as an alternative to the CPFP as a
> transaction pinning mitigation as argued in its merged BIP is easy to
> reason on [...]

Before I address your full point, I think there are two separate things
we want to reason about when considering a proposal like TRUC:

- How does it affect operators of full nodes, including miners and
   volunteer relay node operators?

- How does it affect existing and future protocol users?

By "easy to reason about", I'm mainly referring to how TRUC will affect
operators of full nodes.  IMO, it's critical to get that part right.  In
comparing TRUC to RBFR, it seems to me that it's much easier to reason
about TRUC's effect on relay behavior and mining profitability.

When it comes to reasoning about pinning attacks against LN, this is
almost fundamentally difficult owing to the difficulty of reasoning
about any complex state protocol, especially one that interacts with
multiple layers of multiple other protocol (e.g., TCP/IP, Bitcoin P2P,
Bitcoin consensus).  Whether we're talking about CPFP, CPFP-CO, opt-in
RBF, full-RBF, pure-RBFR, one-shot RBFR, APO, CTV, CAT, TRUC, or
anything else, reasoning about the full implications of a change for LN
users will be difficult.

IMO, when Bitcoin Core developers ship an opt-in feature like BIP431
TRUC, it is not their responsibility to ensure that it is perfectly safe
for downstream projects.  That onus falls on the downstream developers
(e.g., LN devs).  Of course, Bitcoin Core devs want to produce useful
tools and that incentivizes them to produce actual safety improvements;
however, it's unreasonable IMO to expect Bitcoin Core devs to understand
a downstream protocol as well as the devs who work directly on that
protocol.

For something like imbued TRUC, it probably shouldn't be used to replace
an existing mechanism that downstream devs depend on (see subsequent
arguments) unless the downstream devs agree (or there's another very
compelling reason).  Again, the onus falls on the downstream developers
to audit the mechanism's safety because they're the ones with
theoretical and operational experience using the downstream protocol.

Now on to your full point:

> If you or anoyone think TRUC as an alternative to the CPFP as a
> transsction pinning mitigation as argued in its merged BIP is easy to
> reason on, thanks to communicate your lightning node pubkey, with TRUC
> patch applied and a GPG-signed message authorizing me to demonstrate
> the security properties of this solutions have not been submitted to a
> fully contradictory evaluation.

How would that work?  AFAIK, there's no LN software using TRUC, very few
relay nodes are using it (since it isn't yet enabled by default in a
release version), and no miners are using it (again, since it hasn't
been released).  I'm willing to put money at stake to settle a
disagreement that can't be settled with words, but I want to at least
learn something from the process.

My guess is that you're referring to the type of pinning attack you've
called "loophole pinning"[1], which I don't entirely understand, so I'll
do my best to describe it below and hopefully you can correct me on any
errors:

- Mallory guesses that, for the next 144 blocks, transactions in the
   mempool with a feerate of _x_ sats/vb will neither be confirmed nor
   evicted.  If Mallory guesses wrong, the attack will fail.

- Mallory controls a confirmed UTXO that she will spend in 10 different
   fee bumping transactions, making all of those transactions conflict.

- Mallory has 10 channels.  It doesn't matter whether these are all with
   the same counterparty, different counterparties, or a mix of
   counterparties.

- In each channel:

   - Mallory causes the channel to contain the maximum number of
     in-flight HTLCs the counterparty will allow, creating state _A_.
     Each in-flight HTLC inflates the size of the commitment transaction
     about ~40 vbytes.

     The specification maximum for in-flight HTLCs is 2*483, but many
     implementations default to a lower value due to risks from other
     known attacks.

   - Mallory causes all of the in-flight HTLCs to be settled honestly,
     revoking state _A_ that contained them.

   - Mallory causes a single HTLC to be sent through the channel.  Its
     satoshi value is chosen to be roughly equal to: x * (vbytes(A) +
     1000), where _x_ is Mallory non-confirming-non-expiring feerate,
     vsize(A) is the size of the revoked commitment transaction, and
     1,000 is the maximum size of a TRUC fee-bumping child.

     For example, if _x_ is 20 sat/vbyte and vbytes(A) is 2,000, the HTLC
     value is 60,000 sat.

   - Although Mallory knows the preimage necessary to resolve the HTLC,
     she doesn't send it to her counterparty offchain.  This will
     eventually force the counterparty to go onchain.

   - Mallory goes onchain first by broadcasting a package that consists
     of the revoked state _A_ and a CPFP fee bump 1,000 vbytes in size
     that pays a total fee equal to the pending HTLC value (e.g. 60,000
     sat).

- Notably, Mallory is doing this in 10 channels simultaneously with the
   fee bump for each spending the same UTXO, so all of those fee bumps
   conflict with each other.  If Mallory broadcasts each package of
   revoked commitment transaction and fee bump to different nodes across
   the network, each particular package will only exist in the mempools
   of about 10% of nodes.

   - In some cases, Mallory's channel counterparty will receive the 
revoked
     commitment transaction via their own mempool monitoring code.

     - If they realize the feerate is below the amount necessary to get 
the
       transaction confirmed within the next 144 blocks, they will be 
able
       to CPFP fee bump the transaction themselves---but they will need
       to pay more than the 60,000 sat in fees that Mallory is offering.
       However, the pending HTLC is only worth 60,000 sat to them, so it
       may not make sense for them to fee bump.

   - In other cases, Mallory's channel counterparty will receive one of 
the
     conflicting packages.  They will not know that a revoked commitment
     transaction has been broadcast.

     - When Mallory hasn't settled the HTLC fast enough, they will
       broadcast a package of their own commitment transaction and their
       own CPFP fee bump child.  This will pay a higher feerate than
       Mallory paid (which is possible to do under the 60,000 sat budget
       because they're using much smaller transactions).

     - Their high feerate package will propagate until it encounters 
relay
       nodes that have their channel's revoked commitment transaction.
       Although the counterparty's transaction pays a higher feerate, it
       pays less absolute fees than Mallory's transaction and will be
       rejected by that relay node.

- In any cases where the pinning prevents confirmation within 144
   blocks, the HTLC's upstream node can claim a refund and Mallory can
   then use her preimage to steal the HTLC value from her counterparty,
   completing the attack successfully.

   - To settle the HTLC with its preimage, Mallory needs to pay more
     absolute fees to remove her pin, but because she pinned 10 channels
     with a single UTXO, paying to remove the pin from one channel and
     getting that spend confirmed will automatically remove the pin from
     all other channels.  In other words, her cost per channel is roughly
     10% what her honest counterparties would've had to pay to remove the
     pin.

     - However, once Mallory's pin is removed, all the counterparties
       should still broadcast spends of the HTLC-Failure transaction
       paying the HTLC's full value to fees in order to deprive Mallory
       of any profit.

Given the first point and the last point, I'm not sure how viable the
attack is (but, as I said, I'm not sure I understand it).  Estimating or
manipulating feerates correctly for over 144 blocks in a row sounds
difficult.  Counterparties being able to deprive Mallory of profit seems
like a major weakness.

Looking at other proposed improvements: one-shot RBFR with its
requirement that fee bumps enter the top portion of the mempool may
avoid this type of pinning; ideas for expanded versions of TRUC that
also require entering the top portion of the mempool may also avoid this
type of pinning, e.g. "TRUC v3.0.5".[2]

> About replace-by-feerate, I think it's a solution that have downside
> on its own, especially for second-layers like lightning.

If it looked like RBFR was going to be widely deployed, I think its
effect on LN would definitely warrant more research.

> And as I observed on one of the V3 PR threads and corresponding
> conversations, the CPFP carve-out do not provide
> security to lightning implementation
> [...]
> So unless someone argued to the contrary, saying TRUC was needed to
> then deploy cluster mempool is an intellectual fallacy

You described several attacks against anchor outputs using CPFP-CO, some
of which sound quite plausible to me, but none of them is certain to
succeed in any particular instance.  By comparison, disabling CPFP-CO
would leave all users of anchor outputs immediately vulnerable to the
original pinning attack that has an expected ~100% success rate and
barely any cost if executed against multiple channels simultaneously.

Given that, it makes no sense to disable CPFP-CO until a successor is
available.

> On my personal perspective, and after careful considerations of all
> the technical points you've raised. I still think TRUC has a lot of
> problems. RBRFr too has technical problems. About TRUC I think it's an
> acceptable temporary solution to minimize the pinning surface of
> lightning implementations, pending for the design of a better solution
> (more likely at the consensus-level [...])

Thank you for your opinion.  I too think TRUC is a good solution until
we find something better, and any significant improvements may indeed
require consensus changes.

-Dave

[1] 
https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1888377830
[2] https://delvingbitcoin.org/t/v3-and-some-possible-futures/523

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/4e959cdbe70b1a3b9f1adb37fe3b986e%40dtrt.org.

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]

On Mon, Jul 29, 2024 at 06:57:17PM -1000, David A. Harding wrote:
> Given the first point and the last point, I'm not sure how viable the
> attack is (but, as I said, I'm not sure I understand it).  Estimating or
> manipulating feerates correctly for over 144 blocks in a row sounds
> difficult.  Counterparties being able to deprive Mallory of profit seems
> like a major weakness.

It is not.

I've actually *accidentally* exploited this type of pinning vector a few times
in Lighting channels by simply force closing them at times when fee-rates were
high. I've even twice managed to delay the force close of a channel by testing
out justice transactions by broadcasting a low fee-rate, revoked commitment,
which the counterparty node did not notice.  Instead, the channel just stayed
in limbo for a few days until the node finally got in a normal force-close
using the non-revoked state after fees reduced. In both cases, both endpoints
were LND using compact block filters (I was running both nodes in these tests).
IIUC the LND compat block filter implementation does not track mempool
transactions, so it only notices revoked commitment transactions when they
appear in blocks (notice how this means that the lack of package relay will
render LND's fee-bumping code potentially useless if the conflicting commitment
transaction is equal or greater fee/fee-rate).

I haven't tried fully exploiting this particular scenario by maximizing the
number of HTLCs in flight; I was just trying out stuff manually. Someone
should.

It should be relatively easy to automate this class type of attack by simply
picking opportunities for it based on fee rates. It's quite common for fee
spikes to cause conditions where you can easily predict that fees won't go
below certain levels for many blocks in the future, multiple days even. Your
claim that "estimating feerates correctly for over 144 blocks in a row sounds
difficult" is very wrong.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZqlBKVXBKKIurBPk%40petertodd.org.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoindev] Re: A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Garlo Nicon]

[-- Attachment #1.1: Type: text/plain, Size: 10415 bytes --]

> Here is a last resort solution by launching this attack in production.

I hope you will pick some testnet, for example testnet3 or testnet4, or 
even signet, instead of launching it on mainnet. Also because test networks 
are better suited for file sharing scenarios, because if coins are 
worthless, and there are no real transactions, then pushing data is the 
only purpose of such network. Probably, doing it on testnet4 is the easiest 
target, because of 50 tBTC reward (which means: 5 GB spamming ability per 
block, if you use 1 sat/vB).

poniedziałek, 22 lipca 2024 o 14:07:41 UTC+2 Anonymous User napisał(a):

> I came from some twitter discussion so I think this thread is trending. I 
> think we need to figure a way out onward. 
>
> Here is a last resort solution by launching this attack in production. We 
> should avoid making this last resort solution, but from what Peter Todd 
> said, below seems completely practical.
> Please treat it as story reading and do not overthink that this is the way 
> to go.
>
> - a few people in the list form a group and fork bitcoin core and apply 
> the patch from Peter Todd
> - work with a few miners to massively perform the free relay attacks and 
> other mempool related attacks in an effort to force mining pools and miners 
> to switch from bitcoin core into the fork in order for their nodes to 
> continue running in a healthy manner
> - build a free service for file transfer or VPN taking advantage of rbf in 
> the Bitcoin network and make it a public good that millions of users can 
> use, causing most of the mempool transactions to be conflicting (due to 
> different implementations of rbf) and therefore wallets have to eventually 
> stop broadcasting transactions to bitcoin core nodes (which could be using 
> a completely new list of seed nodes, disabling the existing seed node 
> list), and non-bitcoin-core nodes, in order to have more healthy 
> transaction flows and mempool data sharing, would start node-shopping by 
> disconnecting themselves from bitcoin core nodes and refusing to be their 
> peers 
> - core is forced to find a way onward, or the core gives up and archives 
> the bitcoin core repo
>
> The damage is probably just a few days of slower transaction processing, 
> much smaller than the price spike caused by ordinals last year. 
>
> Democracy starts with people having different opinions that DO NOT need to 
> reconcile. So, it is not about how we get different people in this mail 
> list, or the non-public security list, to achieve the same opinions, like 
> whether full RBF is needed. It is about how Bitcoin can allow two groups of 
> people that have fundamentally different opinions and are unwilling and 
> impossible to reconcile. We can have 5-10 security disclosure mail lists by 
> different groups of people, and good-faith vulnerability reporters can 
> choose to exclusively report the bugs to some groups that the reporters 
> feel to be knowledgeable and responsive and, importantly, have the capacity 
> and the motivation to work on it. 
>
> I feel bad for Peter Todd. If I were him, I wouldn't report the bug. I 
> would sell the bug because I got nothing in return, but probably more 
> jealousy or more retaliation for being the only person serious about an 
> issue. 
> Btw, Peter already has a fork. 
>
> Ethereum has great software development process as well as its ecosystem. 
> Smart contracts get heavily audited not because people care about security. 
> It is because North Korea has successfully stolen probably hundreds of 
> millions of dollars from different projects and even causing some projects 
> to fall apart. This is in essence similar to, if one day Bitcoin has a 
> memory exploit issue that causes a massive amount of miners to lose coins 
> that they own, and the network again needs to decide whether to do a hard 
> fork, that is the time when we will be discussing if stopping development 
> in C/C++ and limiting Bitcoin core development to Rust and Rust only are 
> the way forward.
>
> Thanks,
> Anonymous user, as the floppy disk guy recommends this might be the best 
> way to engage in the mailing list onward
>
> I strongly encourage people to try engaging in this email list 
> anonymously. It feels great to say things out loud without worrying about 
> retaliation on unrelated matters. Also, this should be permitted. We still 
> don't know who Satoshi is. If I were Satoshi, I probably also wouldn't 
> report a bug I know. 
>
> On Sunday, July 21, 2024 at 1:49:10 PM UTC-7 Ava Chow wrote:
>
>> On 07/20/2024 10:06 PM, Antoine Riard wrote: 
>> > "Naive", as saying this is the _Bitcoin Core_ project list only can 
>> only 
>> > provoke blind 
>> > spot among the list members if the security issues are either affecting 
>> > old part of 
>> > the codebases that younger members have less experiences with (some 
>> > parts like consensus 
>> > or block-relay are modified only every 5 years) or novel factors from 
>> > upstream or downstream 
>> > (e.g the internet networking stack or implications on deployed contract 
>> > protocols like 
>> > lightning). On both the former and latter criterias, I think Peter 
>> > overly meets the bar. 
>>
>> Peter was not the only "senior" person on the security list. Obviously I 
>> will not disclose non-public information, but certainly there are people 
>> on the security list who are just as, if not more, senior than Peter. 
>>
>> Furthermore, the "old parts" still do get changed, and someone who no 
>> longer actively contributes to the project is more likely to be unaware 
>> of how the code actually works today, even if they are familiar with 
>> components that change infrequently. 
>>
>> > When you've big sh*t hitting the fan like inflation bugs or level DB 
>> > 2013 unexpected fork you 
>> > prefer have experts with a decade of experience to collaborate with, 
>> and 
>> > sharing the same cultural 
>> > and ethical norms of the active contributors evaluated by numbers on 
>> > commits on the last single-digit 
>> > years. 
>>
>> Not being on the list does not preclude him from being consulted if the 
>> need arises. 
>>
>> With the two examples you provide, I am not aware of Peter being 
>> actively involved in the resolution of both of those, whereas there are 
>> current members of the list who were. 
>>
>>
>> In general though, it is not clear to me how it was beneficial to have 
>> Peter on the security list, nor how not having him is directly harmful. 
>> In the 2 years that I have been on the security list, I was unaware that 
>> Peter was a recipient until shortly before he was removed. My 
>> understanding is that others who have been on the list longer than me 
>> were also unaware. 
>>
>> Ava 
>>
>> > 
>> > I'll repropose Peter admission on the security list mailing list in the 
>> > coming weeks by opening an 
>> > issue on the bitcoin-meta repository, once this current mailing list 
>> > thread has slowed down a bit, 
>> > or at least the technical analysis has been dissociated from the 
>> > proceedings which have all been 
>> > bundle in a big message. In my very personal opinion, I still trust 
>> more 
>> > Peter competence and experience 
>> > than some other people I know who are on the security mailing list. 
>> > 
>> > All that said I appreciate your answer and I'm satisfied from the 
>> > personal role you've have played 
>> > in the matter with, and be reassured I'll keep you among the recipient 
>> > of future security issues with 
>> > a potential impact on bitcoin core that I might find or be aware off. 
>> > 
>> > Best, 
>> > Antoine 
>> > ots hash: 
>> db441b51684ad3a6897f67d42c74ccfcb9a4ffed40d4bdbe30a2edd867ccdd54 
>> > 
>> > Le samedi 20 juillet 2024 à 01:50:25 UTC+1, Ava Chow a écrit : 
>> > 
>> > On 07/19/2024 07:58 PM, Antoine Riard wrote: 
>> > > As said in one my previous email, I'm still curious about achow101 
>> > > explaining publicly 
>> > > why you have been kicked-out of the bitcoin-security mailing 
>> > list, when 
>> > > you were certainly 
>> > > more senior than achow101 in matters of base-layer security 
>> > issues or 
>> > > even hard technical 
>> > > issues like consensus interactions (e.g bip65). I'll re-iterate my 
>> > > respect towards achow101 
>> > > as a maintainer from years of collaboration, though this is a topic 
>> > > worthy of an answer. 
>> > 
>> > I am not the one that removed Peter from the mailing list, nor do I 
>> > even 
>> > have the login(s) to do so. 
>> > 
>> > There was a discussion amongst several members of the security list 
>> > about who was on the list, and who should be on the list. Given that 
>> > the 
>> > security list is the _Bitcoin Core_ security list, we determined that 
>> > the people who should be on the list are people who still actively 
>> > contribute to the project. As Peter Todd no longer actively contribute 
>> > code nor code review to the project, we decided that it didn't make 
>> > sense to continue to have him on the list. 
>> > 
>> > My recollection is that multiple other people were removed from the 
>> > list 
>> > for the same reason at the same time. 
>> > 
>> > Ava 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> > Groups "Bitcoin Development Mailing List" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> > an email to bitcoindev+...@googlegroups.com 
>> > <mailto:bitcoindev+...@googlegroups.com>. 
>> > To view this discussion on the web visit 
>> > 
>> https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com 
>> <
>> https://groups.google.com/d/msgid/bitcoindev/2aa2d6fa-ae72-4aef-9fda-49e2f7c657abn%40googlegroups.com?utm_medium=email&utm_source=footer>. 
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/24cd7816-1912-41f9-a6ef-f740801245e2n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 12552 bytes --]

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 30910 bytes --]

Hi Dave,

Apologies for the late answer, I was hiking in nature over the past few 
days.

> Before I address your full point, I think there are two separate things
> we want to reason about when considering a proposal like TRUC:
> 
> - How does it affect operators of full nodes, including miners and
> volunteer relay node operators?
> 
> - How does it affect existing and future protocol users?
> 
> By "easy to reason about", I'm mainly referring to how TRUC will affect
> operators of full nodes. IMO, it's critical to get that part right. In
> comparing TRUC to RBFR, it seems to me that it's much easier to reason
> about TRUC's effect on relay behavior and mining profitability.

I think it's a correct categorization, with the observation that it can be 
more
interesting to dissociate miners from volunteer relay node operators in the 
analysis
of a proposal like TRUC. Miners have the ability to discretely mine 
non-standard
transactions in their block template, contrary of relay nodes. This 
observation
matters practically e.g w.r.t dust HTLC exposure where miners have an edge 
to
launch that type of attacks.

> When it comes to reasoning about pinning attacks against LN, this is
> almost fundamentally difficult owing to the difficulty of reasoning
> about any complex state protocol, especially one that interacts with
> multiple layers of multiple other protocol (e.g., TCP/IP, Bitcoin P2P,
> Bitcoin consensus). Whether we're talking about CPFP, CPFP-CO, opt-in
> RBF, full-RBF, pure-RBFR, one-shot RBFR, APO, CTV, CAT, TRUC, or
> anything else, reasoning about the full implications of a change for LN
> users will be difficult.

I don't deny it, with the addition that you have to reason on how the LN
game-theory incentives can play out, in a system where all the balances
are denominated in satoshis, a scarce ressource under the max money 
consensus
limit. And I'll keep the conversation simple, as there is always the risk
when you're designing second-layers protocol extensions to have backfire
coupling effects on the base-layer (-- one of the main technical reason
we never actually rolled out forward the proof-of-UTXO ownership designed
with naumenkogs as a channel jamming mitigation is the base-layer spam
risks introduced to bypass it).

> IMO, when Bitcoin Core developers ship an opt-in feature like BIP431
> TRUC, it is not their responsibility to ensure that it is perfectly safe
> for downstream projects. That onus falls on the downstream developers
> (e.g., LN devs). Of course, Bitcoin Core devs want to produce useful
> tools and that incentivizes them to produce actual safety improvements;
> however, it's unreasonable IMO to expect Bitcoin Core devs to understand
> a downstream protocol as well as the devs who work directly on that
> protocol.

This is where we have a strong divergence, with all my appreciation of your 
viewpoint.

In my opinion this shall be the responsibility of the Bitcoin Core 
developers
to ensure there is a reasonable safety of the design and implemented 
mechanism
for downstream projects.

Experience of the last years, most notably the half of dozen of security 
weakness
loss of funds found in the design or implementation of anchor outputs (the 
lack of
carve out support at first, the revocation escape, the new pinning vector 
due to
legacy merging of second-stage transactions, the parsing error of core 
lightning /
lnd...) can only point out to seasoned technical observers that weakness 
arises because
of the poor understanding of protocols operational inter-dependency.

That practical bitcoin experience is matching some observations documented 
by the IETF
in decades of design and development of the TCP / IP stack (RFC 3439) [0]. 
Under the coupling
principle, that as things gets larger, they often exhibit increased 
inter-dependence between
components, and with unforseen feature interaction. In the bitcoin space a 
good incarnation
is all the bip125 rule 3 based economical pinnings, that I don't believe 
were clearly expected
by their bip authors.

[0] https://www.rfc-editor.org/rfc/rfc3439

Obviously, there is a sense of proportion to guard and that all Bitcoin 
Core devs
shall understand downstream protocols as well as the devs who work directly 
on that
protocol does not appear realistic, given the wider variety of other 
subsystems
such as builds, graphic interface or p2p block-relay protocol.

_However_, I strongly believe that Bitcoin Core devs working in the 
subsystem
interfacing with downstream protocols such as the mempool or the 
transaction-relay
protocol should have an understood as good as the downstream devs of said 
protocol
inner workings. Otherwise, by designing, implementing and deploying weak 
proposals
such as TRUC in its earlier versions they might cause more harms than good, 
on the
_long term_.

One cannot said there was technical consensus with the merge of TRUC, in 
the sense
of lack of standing grounded objections, be it by the RBFR author, or 
myself directly
on the PR / issues implementing this design in Bitcoin Core.

> For something like imbued TRUC, it probably shouldn't be used to replace
> an existing mechanism that downstream devs depend on (see subsequent
> arguments) unless the downstream devs agree (or there's another very
> compelling reason). Again, the onus falls on the downstream developers
> to audit the mechanism's safety because they're the ones with
> theoretical and operational experience using the downstream protocol.

One should not forget that downstream protocol devs and contributors e.g 
for lightning
are mostly working for commercial companies, with for some on short 
business timelines.
This is very likely to induce them to pick up an expedient mechanism, 
without fully
auditing it, more than jeopardizing the end-users funds safety (and the 
crypto space
at large does not miss spectacular vulnerabilities exploitation).

Sadly, one cannot expect that Bitcoin Core devs contributors to be immune 
of short-term
external factors in the design of better mempool mechanism as in 2020 while 
I was advocating
to build a better understanding of cross-layers security among contributors 
[1]. Yet,
at the very same time the current author of TRUC and bip331 was doing a 
round of the
medias to "sell" the idea and correspondingly attract open-source funding 
before there
was even the lineaments of a technical consensus among contributors to the 
Bitcoin Core project,
or what you call the downstream devs like lightning [2].

[1] 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002856.html
[2] 
https://bitcoinmagazine.com/technical/gloria-zhao-and-brink-are-set-to-give-bitcoin-mempools-an-upgrade

(It's not like there has been a precedent in bitcoin development with the 
extension
block bip idea from joseph poon...which was proposed in 2017 in a fashion 
less than usual
w.r.t traditional communication channels...)

So yes, I think there should be a cultural change in terms of design and 
deployment
of p2p or mempool policy mechanisms supporting downstream protocols. In my 
opinion,
which is backed by my first code review of the imbuance mechanism, current 
development
process is still on the same pace, heading us in nurturing more cross-layer 
vectors
of attacks like pinning due to complex misinterfacing or mempoolfullrbf 
default-like
difficult campaigns of deprecation.

> If you or anoyone think TRUC as an alternative to the CPFP as a
> transsction pinning mitigation as argued in its merged BIP is easy to
> reason on, thanks to communicate your lightning node pubkey, with TRUC
> patch applied and a GPG-signed message authorizing me to demonstrate
> the security properties of this solutions have not been submitted to a
> fully contradictory evaluation.

> How would that work? AFAIK, there's no LN software using TRUC, very few
> relay nodes are using it (since it isn't yet enabled by default in a
> release version), and no miners are using it (again, since it hasn't
> been released). I'm willing to put money at stake to settle a
> disagreement that can't be settled with words, but I want to at least
> learn something from the process.

Thank you for the offer of setting up a demo infrastructure for pinning 
attacks experiment.
I'll describe more what is the minimal setup needed in another public email 
thread
or on delving bitcoin. Less than the funds in the channel, it's interesting 
to have
a full vanilla configuration on mainnet to avoid running in the myriad of 
cases with
policy standardss and the mempool congestion roallcoaster on whatever is 
the testnet /
signet of the day. I can even put the satosis for funding the channnels if 
it's really
needed.

It's correct that TRUC is not implemented in LN in where commitments 
transactions
are nVersion field updated to be pre-signed with TRUC semantics... I can 
always
write a patch in C or rust to have test code ? Though here I would play 
both the
attacker and defender role in the experiment. At least, I think it would be 
worthwile
on its own to test current bip125 rule 3-based economic pinnings, without 
TRUC usage.

> My guess is that you're referring to the type of pinning attack you've
> called "loophole pinning"[1], which I don't entirely understand, so I'll
> do my best to describe it below and hopefully you can correct me on any
> errors:
> 
> - Mallory guesses that, for the next 144 blocks, transactions in the
> mempool with a feerate of _x_ sats/vb will neither be confirmed nor
> evicted. If Mallory guesses wrong, the attack will fail.
> 
> - Mallory controls a confirmed UTXO that she will spend in 10 different
> fee bumping transactions, making all of those transactions conflict.
> 
> - Mallory has 10 channels. It doesn't matter whether these are all with
> the same counterparty, different counterparties, or a mix of
> counterparties.
> 
> - In each channel:
> 
> - Mallory causes the channel to contain the maximum number of
> in-flight HTLCs the counterparty will allow, creating state _A_.
> Each in-flight HTLC inflates the size of the commitment transaction
> about ~40 vbytes.
> 
> The specification maximum for in-flight HTLCs is 2*483, but many
> implementations default to a lower value due to risks from other
> known attacks.
> 
> - Mallory causes all of the in-flight HTLCs to be settled honestly,
> revoking state _A_ that contained them.
> 
> - Mallory causes a single HTLC to be sent through the channel. Its
> satoshi value is chosen to be roughly equal to: x * (vbytes(A) +
> 1000), where _x_ is Mallory non-confirming-non-expiring feerate,
> vsize(A) is the size of the revoked commitment transaction, and
> 1,000 is the maximum size of a TRUC fee-bumping child.
> 
> For example, if _x_ is 20 sat/vbyte and vbytes(A) is 2,000, the HTLC
> value is 60,000 sat.
> 
> - Although Mallory knows the preimage necessary to resolve the HTLC,
> she doesn't send it to her counterparty offchain. This will
> eventually force the counterparty to go onchain.
> 
> - Mallory goes onchain first by broadcasting a package that consists
> of the revoked state _A_ and a CPFP fee bump 1,000 vbytes in size
> that pays a total fee equal to the pending HTLC value (e.g. 60,000
> sat).
> 
> - Notably, Mallory is doing this in 10 channels simultaneously with the
> fee bump for each spending the same UTXO, so all of those fee bumps
> conflict with each other. If Mallory broadcasts each package of
> revoked commitment transaction and fee bump to different nodes across
> the network, each particular package will only exist in the mempools
> of about 10% of nodes.
> 
> - In some cases, Mallory's channel counterparty will receive the
> revoked
> commitment transaction via their own mempool monitoring code.
> 
> - If they realize the feerate is below the amount necessary to get
> the
> transaction confirmed within the next 144 blocks, they will be
> able
> to CPFP fee bump the transaction themselves---but they will need
> to pay more than the 60,000 sat in fees that Mallory is offering.
> However, the pending HTLC is only worth 60,000 sat to them, so it
> may not make sense for them to fee bump.
> 
> - In other cases, Mallory's channel counterparty will receive one of
> the
> conflicting packages. They will not know that a revoked commitment
> transaction has been broadcast.
> 
> - When Mallory hasn't settled the HTLC fast enough, they will
> broadcast a package of their own commitment transaction and their
> own CPFP fee bump child. This will pay a higher feerate than
> Mallory paid (which is possible to do under the 60,000 sat budget
> because they're using much smaller transactions).
> 
> - Their high feerate package will propagate until it encounters
> relay
> nodes that have their channel's revoked commitment transaction.
> Although the counterparty's transaction pays a higher feerate, it
> pays less absolute fees than Mallory's transaction and will be
> rejected by that relay node.
> - In any cases where the pinning prevents confirmation within 144
> blocks, the HTLC's upstream node can claim a refund and Mallory can
> then use her preimage to steal the HTLC value from her counterparty,
> completing the attack successfully.
> 
> - To settle the HTLC with its preimage, Mallory needs to pay more
> absolute fees to remove her pin, but because she pinned 10 channels
> with a single UTXO, paying to remove the pin from one channel and
> getting that spend confirmed will automatically remove the pin from
> all other channels. In other words, her cost per channel is roughly
> 10% what her honest counterparties would've had to pay to remove the
> pin.
> 
> - However, once Mallory's pin is removed, all the counterparties
> should still broadcast spends of the HTLC-Failure transaction
> paying the HTLC's full value to fees in order to deprive Mallory
> of any profit.

The assumption is correct that Mallory makes a prediction on a level of
mempool congestion for a target feerate group, and this is a factor or
success or not of the attack.

It should be noted, there is no need to revoke the state or not in this
pinning, one can use the non-revoked consensus valid transaction, I think
this is the main difference with my scenario where non-revoked transactions
are used to do the "staggering" package (i.e the one at 60,000 sat in your
example), before to be "unstagged" by the same absolute fee, higher feerate,
penalty-paying package.

The parallelization can allow the attacker to not pay the cost, there is
no necessity that it is happening on parallel channels, as one can 
double-spend
from the CPFP of a "batching transaction, whatever else it is doing.

> Given the first point and the last point, I'm not sure how viable the 
> attack is (but, as I said, I'm not sure I understand it). Estimating or 
> manipulating feerates correctly for over 144 blocks in a row sounds 
> difficult. Counterparties being able to deprive Mallory of profit seems 
> like a major weakness. 

On the first point, if I'm understanding correctly it's about predicting
mempool congestion as a factor of success of the attack. It's not a perfect
art though it's quite practical for an attacker as it is what mempool fee
estimation algorithms are all about.

On the last point, i.e the HTLC-Failure transaction paying the full value
to the fees, this HTLC-Failure confirmation should happen only after the
double-spend of the inbound HTLC by a puppet of Mallory. Until this on-chain
confirmation of the malicious inbound HTLC-failure, the Alice's outbound
HTLC-failure is blocked by the pinning.

Note, this is _not_ a replacement cycling attack, as it's all relying on the
Mallory's package being on an absolute fee / feerate too high to be replaced
by a Alice's package.

I understand it's hard to understand, and it sounds your attack layout could
benefit from adding lightning topology on the left / right side of Alice as
the attack victim. Note, how mempool congestion could play as a pinning 
vector
was slightly surveyed in the discussion of package relay design in 2020, 
though
no more fleshed-out write-up or blog post has been made available since 
then until
my comment on the Bitcoin Core PR, to the best of my knowledge [4].

[4] https://github.com/bitcoin/bitcoin/issues/14895#issuecomment-665907792

> Looking at other proposed improvements: one-shot RBFR with its 
> requirement that fee bumps enter the top portion of the mempool may 
> avoid this type of pinning; ideas for expanded versions of TRUC that 
> also require entering the top portion of the mempool may also avoid this 
> type of pinning, e.g. "TRUC v3.0.5".[2].

I have not yet analyzed one-shot RBFR in more detailed, though I believe
a better long-term fix is actually _not_ to entangle the mempool states with
transaction-relay propagation rules. A full-node mempoool is a stateful
cache with public write allowed.

> If it looked like RBFR was going to be widely deployed, I think its
> effect on LN would definitely warrant more research.

If mempool acceptance was more modular in Bitcoin Core, we could have
more fine-grained transaction acceptance policy module embedded in
the `AcceptToMemoryPool` flow and easier to experiment the effects of
alternative policy like RBFR on LN.

> You described several attacks against anchor outputs using CPFP-CO, some
> of which sound quite plausible to me, but none of them is certain to
> succeed in any particular instance. By comparison, disabling CPFP-CO
> would leave all users of anchor outputs immediately vulnerable to the
> original pinning attack that has an expected ~100% success rate and
> barely any cost if executed against multiple channels simultaneously.
> 
> Given that, it makes no sense to disable CPFP-CO until a successor is
> available.

In a world where revoked lightning transactions are still consensus-valid
and where any of them can be used to blind the lightning node of the correct
CPFP to proceed with, the carve-out is ineffective.

I'll let you indicate me where in the bolt spec it is indicated how 
lightning
software should implement correctly CPFP of the carve-out, as it is 
implemented
and deployed in Bitcoin Core since circa 2019.

I won't say the carve-out mechanism has been "fast" shipped in 2019 and that
its authors might really not know how lightnning was working at the time.
However, I believe there has never been a bip or other document informing 
how it
should be used by downtream protocols.

> Thank you for your opinion. I too think TRUC is a good solution until
> we find something better, and any significant improvements may indeed
> require consensus changes.

Thank too for your opinion. I think TRUC is an acceptable temporary solution
to minimize lightning pinning surface, however I'm still worried on the 
long-term
it can have undesirable side-effect, in a world where miners are running 
"heretic"
transaction acceptance policy.

And it's making a false security guarantee for lightning nodes, as uniform 
policy
is not a network reality, and an associated full-node could be paired with 
peers
not respecting TRUC semantics -- I know I've advocated uniform policy w.r.t 
package relay
to improve lightning safety in the past, though after finding vulnerability 
vectors arising
from a policy rule like opt-in RBF and asymmetrically affecting use-cases 
(0conf vs LN), I'm
far more skeptical in grounding downstream protocols safety on mechanism 
like TRUC.

Best,
Antoine
ots hash: 42407994c5e58123bf2535ba420517f83b95977052b4bde4ff9e115b91e2b598

Le mardi 30 juillet 2024 à 06:48:19 UTC+1, David A. Harding a écrit :

> On 2024-07-20 16:10, Antoine Riard wrote:
> > If you or anoyone think TRUC as an alternative to the CPFP as a
> > transaction pinning mitigation as argued in its merged BIP is easy to
> > reason on [...]
>
> Before I address your full point, I think there are two separate things
> we want to reason about when considering a proposal like TRUC:
>
> - How does it affect operators of full nodes, including miners and
> volunteer relay node operators?
>
> - How does it affect existing and future protocol users?
>
> By "easy to reason about", I'm mainly referring to how TRUC will affect
> operators of full nodes. IMO, it's critical to get that part right. In
> comparing TRUC to RBFR, it seems to me that it's much easier to reason
> about TRUC's effect on relay behavior and mining profitability.
>
> When it comes to reasoning about pinning attacks against LN, this is
> almost fundamentally difficult owing to the difficulty of reasoning
> about any complex state protocol, especially one that interacts with
> multiple layers of multiple other protocol (e.g., TCP/IP, Bitcoin P2P,
> Bitcoin consensus). Whether we're talking about CPFP, CPFP-CO, opt-in
> RBF, full-RBF, pure-RBFR, one-shot RBFR, APO, CTV, CAT, TRUC, or
> anything else, reasoning about the full implications of a change for LN
> users will be difficult.
>
> IMO, when Bitcoin Core developers ship an opt-in feature like BIP431
> TRUC, it is not their responsibility to ensure that it is perfectly safe
> for downstream projects. That onus falls on the downstream developers
> (e.g., LN devs). Of course, Bitcoin Core devs want to produce useful
> tools and that incentivizes them to produce actual safety improvements;
> however, it's unreasonable IMO to expect Bitcoin Core devs to understand
> a downstream protocol as well as the devs who work directly on that
> protocol.
>
> For something like imbued TRUC, it probably shouldn't be used to replace
> an existing mechanism that downstream devs depend on (see subsequent
> arguments) unless the downstream devs agree (or there's another very
> compelling reason). Again, the onus falls on the downstream developers
> to audit the mechanism's safety because they're the ones with
> theoretical and operational experience using the downstream protocol.
>
> Now on to your full point:
>
> > If you or anoyone think TRUC as an alternative to the CPFP as a
> > transsction pinning mitigation as argued in its merged BIP is easy to
> > reason on, thanks to communicate your lightning node pubkey, with TRUC
> > patch applied and a GPG-signed message authorizing me to demonstrate
> > the security properties of this solutions have not been submitted to a
> > fully contradictory evaluation.
>
> How would that work? AFAIK, there's no LN software using TRUC, very few
> relay nodes are using it (since it isn't yet enabled by default in a
> release version), and no miners are using it (again, since it hasn't
> been released). I'm willing to put money at stake to settle a
> disagreement that can't be settled with words, but I want to at least
> learn something from the process.
>
> My guess is that you're referring to the type of pinning attack you've
> called "loophole pinning"[1], which I don't entirely understand, so I'll
> do my best to describe it below and hopefully you can correct me on any
> errors:
>
> - Mallory guesses that, for the next 144 blocks, transactions in the
> mempool with a feerate of _x_ sats/vb will neither be confirmed nor
> evicted. If Mallory guesses wrong, the attack will fail.
>
> - Mallory controls a confirmed UTXO that she will spend in 10 different
> fee bumping transactions, making all of those transactions conflict.
>
> - Mallory has 10 channels. It doesn't matter whether these are all with
> the same counterparty, different counterparties, or a mix of
> counterparties.
>
> - In each channel:
>
> - Mallory causes the channel to contain the maximum number of
> in-flight HTLCs the counterparty will allow, creating state _A_.
> Each in-flight HTLC inflates the size of the commitment transaction
> about ~40 vbytes.
>
> The specification maximum for in-flight HTLCs is 2*483, but many
> implementations default to a lower value due to risks from other
> known attacks.
>
> - Mallory causes all of the in-flight HTLCs to be settled honestly,
> revoking state _A_ that contained them.
>
> - Mallory causes a single HTLC to be sent through the channel. Its
> satoshi value is chosen to be roughly equal to: x * (vbytes(A) +
> 1000), where _x_ is Mallory non-confirming-non-expiring feerate,
> vsize(A) is the size of the revoked commitment transaction, and
> 1,000 is the maximum size of a TRUC fee-bumping child.
>
> For example, if _x_ is 20 sat/vbyte and vbytes(A) is 2,000, the HTLC
> value is 60,000 sat.
>
> - Although Mallory knows the preimage necessary to resolve the HTLC,
> she doesn't send it to her counterparty offchain. This will
> eventually force the counterparty to go onchain.
>
> - Mallory goes onchain first by broadcasting a package that consists
> of the revoked state _A_ and a CPFP fee bump 1,000 vbytes in size
> that pays a total fee equal to the pending HTLC value (e.g. 60,000
> sat).
>
> - Notably, Mallory is doing this in 10 channels simultaneously with the
> fee bump for each spending the same UTXO, so all of those fee bumps
> conflict with each other. If Mallory broadcasts each package of
> revoked commitment transaction and fee bump to different nodes across
> the network, each particular package will only exist in the mempools
> of about 10% of nodes.
>
> - In some cases, Mallory's channel counterparty will receive the 
> revoked
> commitment transaction via their own mempool monitoring code.
>
> - If they realize the feerate is below the amount necessary to get 
> the
> transaction confirmed within the next 144 blocks, they will be 
> able
> to CPFP fee bump the transaction themselves---but they will need
> to pay more than the 60,000 sat in fees that Mallory is offering.
> However, the pending HTLC is only worth 60,000 sat to them, so it
> may not make sense for them to fee bump.
>
> - In other cases, Mallory's channel counterparty will receive one of 
> the
> conflicting packages. They will not know that a revoked commitment
> transaction has been broadcast.
>
> - When Mallory hasn't settled the HTLC fast enough, they will
> broadcast a package of their own commitment transaction and their
> own CPFP fee bump child. This will pay a higher feerate than
> Mallory paid (which is possible to do under the 60,000 sat budget
> because they're using much smaller transactions).
>
> - Their high feerate package will propagate until it encounters 
> relay
> nodes that have their channel's revoked commitment transaction.
> Although the counterparty's transaction pays a higher feerate, it
> pays less absolute fees than Mallory's transaction and will be
> rejected by that relay node.
>
> - In any cases where the pinning prevents confirmation within 144
> blocks, the HTLC's upstream node can claim a refund and Mallory can
> then use her preimage to steal the HTLC value from her counterparty,
> completing the attack successfully.
>
> - To settle the HTLC with its preimage, Mallory needs to pay more
> absolute fees to remove her pin, but because she pinned 10 channels
> with a single UTXO, paying to remove the pin from one channel and
> getting that spend confirmed will automatically remove the pin from
> all other channels. In other words, her cost per channel is roughly
> 10% what her honest counterparties would've had to pay to remove the
> pin.
>
> - However, once Mallory's pin is removed, all the counterparties
> should still broadcast spends of the HTLC-Failure transaction
> paying the HTLC's full value to fees in order to deprive Mallory
> of any profit.
>
> Given the first point and the last point, I'm not sure how viable the
> attack is (but, as I said, I'm not sure I understand it). Estimating or
> manipulating feerates correctly for over 144 blocks in a row sounds
> difficult. Counterparties being able to deprive Mallory of profit seems
> like a major weakness.
>
> Looking at other proposed improvements: one-shot RBFR with its
> requirement that fee bumps enter the top portion of the mempool may
> avoid this type of pinning; ideas for expanded versions of TRUC that
> also require entering the top portion of the mempool may also avoid this
> type of pinning, e.g. "TRUC v3.0.5".[2]
>
> > About replace-by-feerate, I think it's a solution that have downside
> > on its own, especially for second-layers like lightning.
>
> If it looked like RBFR was going to be widely deployed, I think its
> effect on LN would definitely warrant more research.
>
> > And as I observed on one of the V3 PR threads and corresponding
> > conversations, the CPFP carve-out do not provide
> > security to lightning implementation
> > [...]
> > So unless someone argued to the contrary, saying TRUC was needed to
> > then deploy cluster mempool is an intellectual fallacy
>
> You described several attacks against anchor outputs using CPFP-CO, some
> of which sound quite plausible to me, but none of them is certain to
> succeed in any particular instance. By comparison, disabling CPFP-CO
> would leave all users of anchor outputs immediately vulnerable to the
> original pinning attack that has an expected ~100% success rate and
> barely any cost if executed against multiple channels simultaneously.
>
> Given that, it makes no sense to disable CPFP-CO until a successor is
> available.
>
> > On my personal perspective, and after careful considerations of all
> > the technical points you've raised. I still think TRUC has a lot of
> > problems. RBRFr too has technical problems. About TRUC I think it's an
> > acceptable temporary solution to minimize the pinning surface of
> > lightning implementations, pending for the design of a better solution
> > (more likely at the consensus-level [...])
>
> Thank you for your opinion. I too think TRUC is a good solution until
> we find something better, and any significant improvements may indeed
> require consensus changes.
>
> -Dave
>
> [1] 
> https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1888377830
> [2] https://delvingbitcoin.org/t/v3-and-some-possible-futures/523
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/11b7ba56-04f1-4ebe-a434-e8478b5efe70n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 34907 bytes --]

Re: [bitcoindev] A "Free" Relay Attack Taking Advantage of The Lack of Full-RBF In Core

[Antoine Riard]

[-- Attachment #1.1: Type: text/plain, Size: 5602 bytes --]

Hi Peter,

> It is not.
> 
> I've actually *accidentally* exploited this type of pinning vector a few 
times
> in Lighting channels by simply force closing them at times when fee-rates 
were
> high. I've even twice managed to delay the force close of a channel by 
testing
> out justice transactions by broadcasting a low fee-rate, revoked 
commitment,
> which the counterparty node did not notice. Instead, the channel just 
stayed
> in limbo for a few days until the node finally got in a normal force-close
> using the non-revoked state after fees reduced. In both cases, both 
endpoints
> were LND using compact block filters (I was running both nodes in these 
tests).
> IIUC the LND compat block filter implementation does not track mempool
> transactions, so it only notices revoked commitment transactions when they
> appear in blocks (notice how this means that the lack of package relay 
will
> render LND's fee-bumping code potentially useless if the conflicting 
commitment
> transaction is equal or greater fee/fee-rate).
> 
> I haven't tried fully exploiting this particular scenario by maximizing 
the
> number of HTLCs in flight; I was just trying out stuff manually. Someone
> should.
> 
> It should be relatively easy to automate this class type of attack by 
simply
> picking opportunities for it based on fee rates. It's quite common for fee
> spikes to cause conditions where you can easily predict that fees won't go
> below certain levels for many blocks in the future, multiple days even. 
Your
> claim that "estimating feerates correctly for over 144 blocks in a row 
sounds
> difficult" is very wrong.

After reading Dave description of the "loophole pinning" attack, which is a
re-formalization of my gitub comment on one of the TRUC PR, I'm not entirely
sure, we're describing the same exploitation scenario. Finely evaluating the
viability of an attack, before the attack scheme and attacker capabilities 
are
fleshed out is a bit premature...

Especially, when you're saying few more lines after that you have tried to
fully exploit this scenario with HTLCs in flights, and all other attempts
were more accidental and without being sure the LND software correctly
implements RBF, including the rule 5 penalty computation at all time (you're
observing yourself the limitations of LND's fee-bumping code).

If there is a lightning node on mainnet of yours that your formally 
authorize
me to test some pinning attacks, I could try a demo. Alternatively, I can
setup a LN node + full-node on some long-running infrastructure, if you wish
to try the scenario on your side. Though, as observed by Dave there is no
lightning code written yet to opt-in into TRUC transactions.

On the last observation, I agree with you that is a class type of attack 
that
one could automate by leveraging fee-estimation algorithms.

Best,
Antoine
ots hash: a958c5bf1a5af3f3fd2b3788b201b95707621cfecc9b1478075a0da4d8c5c0a5

Le mardi 30 juillet 2024 à 20:58:08 UTC+1, Peter Todd a écrit :

> On Mon, Jul 29, 2024 at 06:57:17PM -1000, David A. Harding wrote:
> > Given the first point and the last point, I'm not sure how viable the
> > attack is (but, as I said, I'm not sure I understand it). Estimating or
> > manipulating feerates correctly for over 144 blocks in a row sounds
> > difficult. Counterparties being able to deprive Mallory of profit seems
> > like a major weakness.
>
> It is not.
>
> I've actually *accidentally* exploited this type of pinning vector a few 
> times
> in Lighting channels by simply force closing them at times when fee-rates 
> were
> high. I've even twice managed to delay the force close of a channel by 
> testing
> out justice transactions by broadcasting a low fee-rate, revoked 
> commitment,
> which the counterparty node did not notice. Instead, the channel just 
> stayed
> in limbo for a few days until the node finally got in a normal force-close
> using the non-revoked state after fees reduced. In both cases, both 
> endpoints
> were LND using compact block filters (I was running both nodes in these 
> tests).
> IIUC the LND compat block filter implementation does not track mempool
> transactions, so it only notices revoked commitment transactions when they
> appear in blocks (notice how this means that the lack of package relay will
> render LND's fee-bumping code potentially useless if the conflicting 
> commitment
> transaction is equal or greater fee/fee-rate).
>
> I haven't tried fully exploiting this particular scenario by maximizing the
> number of HTLCs in flight; I was just trying out stuff manually. Someone
> should.
>
> It should be relatively easy to automate this class type of attack by 
> simply
> picking opportunities for it based on fee rates. It's quite common for fee
> spikes to cause conditions where you can easily predict that fees won't go
> below certain levels for many blocks in the future, multiple days even. 
> Your
> claim that "estimating feerates correctly for over 144 blocks in a row 
> sounds
> difficult" is very wrong.
>
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/04a22956-b722-4f6c-b8d5-0f8905359721n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 6889 bytes --]