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

[Peter Todd]

# 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

[Antoine Riard]

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

[Peter Todd]

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.

[Antoine Riard]

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

[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

[/dev /fd0]

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

[Peter Todd]

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.

[Antoine Riard]

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

[Antoine Riard]

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

[Ava Chow]

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

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

[/dev /fd0]

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

[Peter Todd]

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!

[Peter Todd]

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?

[Peter Todd]

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.

[Peter Todd]

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.

[Antoine Riard]

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

[Antoine Riard]

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

[/dev /fd0]

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

[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

[Antoine Riard]

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

[Antoine Riard]

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

[Peter Todd]

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.

[Ava Chow]

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

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

[Peter Todd]

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

[Anonymous User]

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. 

[Peter Todd]

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.

[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

[Peter Todd]

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!

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.

[Peter Todd]

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

[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

[Peter Todd]

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.

[Antoine Riard]

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

[Antoine Riard]

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 

[Antoine Riard]

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

[Antoine Riard]

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

[Antoine Riard]

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

[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

[Peter Todd]

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.

[Garlo Nicon]

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

[Antoine Riard]

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.

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

[Antoine Riard]

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