path: root/8d/bbdb7d61111c7abd5d2d57912fe25ae662d248

Delivery-date: Thu, 12 Jun 2025 12:40:37 -0700
Received: from mail-yb1-f191.google.com ([209.85.219.191])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBKO2VTBAMGQEOBGJ4NQ@googlegroups.com>)
	id 1uPnmt-0000fk-4z
	for bitcoindev@gnusha.org; Thu, 12 Jun 2025 12:40:37 -0700
Received: by mail-yb1-f191.google.com with SMTP id 3f1490d57ef6-e819aa98d59sf1822083276.2
        for <bitcoindev@gnusha.org>; Thu, 12 Jun 2025 12:40:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1749757229; x=1750362029; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=o/7yF8A7/BMcvdErWvXmilXGgOmZyo1tSyhRn+oSKZM=;
        b=gZU2GkcabMLNPTpj6M+SHIQ8/5vW+hlTDDjZcp/CrctO2c3yq0TuD4RADtrNjb0DQT
         VtYFdpnEEigjjAb4XFv3b3OBS1Jhqc0aLIUEpx0aPn4z6hqWDTA+c7YbeoUp636jlBfS
         I/6YbK4O4ZfqzLsoHUuNNskKasrjJ05x3cv0jDXer6ElAYAibt6Z/bp6M0Eu7XmpvVda
         BSzkWy0uiEVZBX0LRA5ApxhvnzoRdRibh7yn25tQ3CRDMzkaK+oqMAqEdFSbPQN+K8bu
         nuaZKTgvIWRX6rEtlQCe4cvVtiDCDUWOid5kZkz7YpmW+/GY1KxsTS01bp4Ct0FHehjW
         K9Xw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1749757229; x=1750362029; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:from:to:cc:subject:date:message-id
         :reply-to;
        bh=o/7yF8A7/BMcvdErWvXmilXGgOmZyo1tSyhRn+oSKZM=;
        b=G1Ba1GNknKw8I94NOd+TjJUhSGD5p5RjgFeWbCxsBSErxVrPIsn70o5hia7QEEG7qJ
         rW1TpGx5CI0fqGnK6sHwcX9M2A8gbECans8kEKXzKITNNrZuvqcs1LqsU5YhXsm9ryw5
         V2t5eCmXvZP/UExBgDDs6XWW+kgn8bMO1CHTiX6xX6Dhxf/TD92PQkiOQtKtjfmdlurh
         f9Ffi6etifcmKEsH9LS8bo1uxNSiK8u6L4BeK4ceG2EFwMgwOP2Y87PIfkngJmC5AHCV
         kncLiCBmsVysYoaqIu158oCd1adH8U30T7xNh9r3YSdPreB85aXIaVolD3U9o2VYF8Vw
         Z3Ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1749757229; x=1750362029;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=o/7yF8A7/BMcvdErWvXmilXGgOmZyo1tSyhRn+oSKZM=;
        b=pVp2ndc9qQRi9Cv8ReaC+tsU4IqVdMxmWQmDO9QYCKf2BogMH8rcALCPDuBnMx4t1Q
         WYmXtU/vxzkLhTFTZkEM+juKyeMCAmkI3HGrfEQTSTgL4DPNmTLmzAg+WbfUVQdh4h6c
         8Nr6/qVDcYAoK502pow91DMSdYq/Km8daSQ3+pEh+/cEQ1vouENBjYHVQH495GI3AD5P
         wgYFpnO4n8kl0qXyKRoK8SZn59N8S1pqb00qBzfIbar/XGWHYEMzMNLOMZ2+J0yL0H5w
         K5or41ZWo/YziPQj0pGzm9asEh3u+TrN8PpJ01Rcw4KijaZNtMlixtMLHW5a9xtl3GD2
         E40Q==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWjTEAIwHTTwWiprj2rN/7Qb/KlNr9tokIXUnVDvhdOhi/oRsVW/kntugZTFUns6X5IXJ5paWhjExRp@gnusha.org
X-Gm-Message-State: AOJu0YwDpkAnuAfoVqcYjEYMWotENy7o8MmqAe4CLQiGLBJpivOuCA32
	L2qyofJLyMmzuR+7wf6QOoA0eVsMJll5zACYoFynW/GSqBs9vJtcX5JH
X-Google-Smtp-Source: AGHT+IG20rVpJTWzjdrgWWZ7D2eefU2zwhZ68EnUCW/lZEUaX80om9fc0u++T07CuaSsy1m0ftaVmQ==
X-Received: by 2002:a05:6902:2584:b0:e81:ffff:b76a with SMTP id 3f1490d57ef6-e821c1ef44amr358069276.35.1749757228827;
        Thu, 12 Jun 2025 12:40:28 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZf//BjqX0HK7mk8hOYK59byYRl3fZ5r+v7T7cNnxV+G8g==
Received: by 2002:a25:abf3:0:b0:e7d:5a87:b47b with SMTP id 3f1490d57ef6-e820d692033ls1121448276.0.-pod-prod-01-us;
 Thu, 12 Jun 2025 12:40:24 -0700 (PDT)
X-Received: by 2002:a05:690c:4901:b0:710:f0fb:dc46 with SMTP id 00721157ae682-7116370c73emr8807837b3.7.1749757224599;
        Thu, 12 Jun 2025 12:40:24 -0700 (PDT)
Received: by 2002:a05:690c:2706:b0:6ef:590d:3213 with SMTP id 00721157ae682-71162a564f0ms7b3;
        Thu, 12 Jun 2025 12:03:32 -0700 (PDT)
X-Received: by 2002:a05:690c:490a:b0:70d:f237:6a6a with SMTP id 00721157ae682-71163738a2emr7946017b3.11.1749755010676;
        Thu, 12 Jun 2025 12:03:30 -0700 (PDT)
Date: Thu, 12 Jun 2025 12:03:30 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <fe76185f-8d9c-41b2-ab15-117d7787a204n@googlegroups.com>
Subject: [bitcoindev] Full-Disclosure: CVE-2025-27586 "No Santa Claus under
 the Lightning Sun"
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_15918_955359903.1749755010295"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_15918_955359903.1749755010295
Content-Type: multipart/alternative; 
	boundary="----=_Part_15919_1022834123.1749755010295"

------=_Part_15919_1022834123.1749755010295
Content-Type: text/plain; charset="UTF-8"

Hi,

This report is to disclose a vector of attack affecting bitcoin 
time-sensitive
contract protocols, specifically the lightning network by exhausting the 
fee-bumping
reserves of anchor-upgraded channels of a lightning node.

This attack vector has been known since the early days of anchor output 
deployment
over the network circa end of 2020 and it has been discussed among LN 
maintainers
since circa mid 2022. While few basic mitigations have been developed and 
shipped
in LN implementations over the last few years, it is believed that more 
robust
mitigations can only be deployed at the protocol-level, thus unlikely to 
happen
with an embargoed process.

This class of attacks dubbed "fee-bumping reserves exhaustion attacks" is
tracked at the protocol-level by CVE-2025-27586. As as far as it is 
understood
it is affecting LN routing nodes (i.e a double-spent of an incoming / 
outgoing 
HTLC) and LN payee (i.e revealing a preimage with `update_fulfill_htlc` and
double-spent with a HTLC-timeout). This is indeed a money stealing kind of 
attacks.

While the attacks have not been tested under real-world configurations, 
they're
deemed as feasible, with the caveat of round guessing the level of 
fee-bumping
reserves for the adversary (see corresponding section). If you're running a
LN node with subsequent funds at stake and deployed `option_anchor` channels
channels, I uphold to reach out to the maintainers of your run LN 
implementations
for tailored recommendations on how to adjust your fee-bumping reserves 
(some
LN implementations are monolothic stacks, some are more modular not 
shipping with
a wallet and here efficient mitigations is very tight with your L1 wallet).

The report is organized in the following fashion:
- background on LN fee-bumping
- explanation of the problem
- the challenge: detecting a node fee-bumping reserves from the outside
- lightning mitigations
- second-layers impact
- discovery
- timeline

A copy of the report is available here if formatting doesn't work well:
https://ariard.github.io/feebumping.html

## Background: Lightning Fee Estimation, Legacy Channel and `option_anchor`

Historically, the responsibility for fees has been on the channel initiator
(i.e the channel forwarding first the `open_channel` msg). The fees feeding
both counterparties commitment transaction is substracted from the initiator
balance (`funding.is_outbound()` in LDK). The feerate determinating the 
level
of absolute fees committed is set by the flow of `update_fee` message.

That msg is forward by the channel initiator with a `feerate_per_kw`. If
the recipient estimates from its local fee-estimation that the feerate is
good enough for timely processing and not unreasonably large, the feerate is
accepted. This feerate is used to build the local and remote's versions
of the commitment transactions and the respective set of second-stage HTLC
transactions (`build_htlc_transaction()` in LDK).

With this legacy mode of fee-bumping, all the fee-bumping liquidity is 
coming out of the channel initator balance (i.e the `to_local` or 
`to_remote`
output accordingly), of which this balance is theorically the upper limit
to fee-bump a version of the commitment tx and its second-stage HTLCs.

As of today, this `update_fee` mechanism is still supported by LN implems
and this mechanism is still part of the BOLTs specification (BOLT #2 
"Updating
Fees: `update_fee`). However, as it has been well-established and understood
by the LN community since a long time, this mechanism does not work very 
well
in an environment with dynamic fees. Indeed, the pre-signed feerates at time
T might not suffice to get into a block at time T + 100. Additionally, there
is no guarantee that the channel counterparty is online or cooperative at 
time
T + 100 to re-sign a pair of commitment transaction with enhanced feerates.

Therefore, since 2018, the LN community has been working on the anchor 
output
upgrade, i.e adding a pair of dedicated outputs on each version of the 
commitment
transaction (i.e historically `option_anchor_outputs` then 
`option_anchors_zero_fee_htlc_tx`,
now `option_anchors`). This anchor output mechanism allows a LN node to 
attach
unilaterally a child-pay-for-parent on the commitment transaction it has to
include in a block.

Making abstraction of any transaction-relay issue, the CPFP can constitute a
fee-bump of the overall package (the commitment tx + the cpfp tx), which is
increasing its feerate to increase the odds its block inclusion. In case of
time-sensitive HTLC outputs to claim (e.g a HTLC-preimage to claim a 
"received"
output or a HTLC-timeout to claim a "offered" output), timely inclusion in
blocks matters for a LN node.

As of today, the `option_anchor` is not the default for LDK (v0.0.124 -
src/util/config.rs), is the default for LND (v.19.0-beta - sample-lnd.conf),
is the default for Core-Lightning (v.25.02 - lightningd/options.c). Eclair 
has 
not been checked because it's in Scala.

## Problem: Lack of Fee-Reserves Provisioning for Anchor Outputs Fee-Bumping

While the anchor output mechanism allows non-interactive fee-bumping of
a commitment transaction, the original specification of anchor output never
mentions, neither indicates how the now external fee-bumping reserves should
be provisioned LN node and if any reactive actions should be undertake in
face of network mempools congestions or high block inclusion median feerate 
[1].

The lack of fee-reserves provisioning exposes a LN node to a fee-bumping
reserve exhaustion attack, where a malicious counterparty triggers inflation
of the LN node's channel surface to exhaust the limited fee-bumping 
reserves.

E.g if Alice's commitment transaction is pre-signed at 1 sat / vb, the
current size is 2000 bytes and the top block feerates ranks at 10 sat / vb,
Alice should have at least 19000 sats of fee-bumping reserves.

Still, even if Alice has a sufficient level of reserves, if the channel's
`max_accepted_htlcs` is uncapped (i.e up to the protocol limit of 483 HTLCs
one-side), the channel counterparty Bob can inflate the size of the 
commitment
transaction (e.g from 2000 bytes to 4000 bytes) up until Alice's fee-bumping
reserves are exhausted.

E.g if Alice, a routing node, has a pending HTLC of value 30k sats, and she 
has
only 20k satoshis of reserves, if the block feerate is to be over 10 sats / 
vbyte
up until the HTLC expires at block T=150, she won't be able to include her 
commitment
tx, before an incoming HTLC expires at block T=100.

In the lack of a monitored `max_channel_weight_surface` for each opended 
channel
binded with fee-bumping reserves, a LN node is exposed to diverse 
fee-bumping
reserve exhaustion attacks.

Generally, there are 3 injection vectors that a LN counterparty, or a 
third-party
that can route through a channel opened with the target node, to inflate a 
LN node
global channel surface:
- opening more inbound channels
- asks for more outbound channels (e.g by buying Just-in-Time channels)
- routing more offered / received HTLCs on an existent given channel

This class of attacks is dependent on the level of networks mempools 
congestion,
as with more congestions spikes in, more channels are exposed to the 
attack. The
attack difficulty of execution is deemed as medium, as only direct peering 
or
indirect peering with the target node is necessary and visibility on the 
ongoing
networks mempools congestion.

For what is concerning, the adversy cost, it is limited as the on-chain fees
to open more inbound channels, out-of-band fees to open more outbound 
channels.
It is unfairly cheap if the attack vector of routing HTLCs to inflate the 
size
of the LN channel is leveraged, as off-chain fees are only currently paid in
case of success for LN. An adversary only has to overbid at the current 
block
inclusion feerate and the break even threshold is reached as long as the 
HTLC's
`amount_msat` is superior to the fee cost.

## Detecting a Node Fee-Bumping Reserves from the Outside

There is one main challenge for an adversary which is worth of awareness, 
namely
guessing the fee-bumping level of reserves of a target node, before to 
launch
a fee-bumping reserve attack. Indeed, while LN implementations have 
pre-configured
level of fee-bumping reserves automatically allocated which can be observed 
from
the code source of the diverse LN implementations, a LN node could have 
consequential
UTXO reserves in one or more L1 wallets.

A first deanonymization heuristic to bound the fee-bumping reserves level 
can be
to trigger a unilateral force close with a "decoy" test. E.g at block 
inclusion feerate
X, for 2 public channels provokes a force-close of channel 1 and observe if 
the
target node Y is going to match the inclusion feerate for X with its CPFP 
attached
to channel 1. If yes, the adversary can estimate that the same level of 
reserves holds
for channel 2. If no, the adversary can estimate that public channel is 
probably
exposed to a FBRE attack.

This deanonymization heuristic can be generalized on long-tend stastical 
observations
of a LN node by snitching all its unilateral force-closures from the 
on-chain txn logs.

A second tupe deanonymization heuristic can be to observe the interactions 
with
the base-layer and the UTXO management, e.g based on which BTC addresses 
are consumed
to feed the outbound channels opening, or the dual-funding channel opening 
by the
target node (i.e all the operations of replenishment, funding, payment, 
settlement
or collection) [2].

One should make the observations that for L1 wallets coins to be leveraged 
as
fee-bumping reserves, the L1 wallet should be sufficently "hot" to be used 
in the
time span granted by the lowest safety timelock for a deployed channel.

## Lightning Mitigations

On the range of mitigations that can be implemented by a LN implementation
there are 3 complementary plausible lines:
- 1) over-provisioning fee-bumping reserves
- 2) halting the increase of the LN node's all-channels's 
`max_channel_weight_surface`
- 3) cooperatively collaboring with LN peers to downcrease its local 
`max_channel_weight_surface`.

About the 1), which is the more obvious, the idea is for a LN node to 
over-provision
the fee-bumping reserves with the following formula: 
`current_opened_channel` *
`max_channel_weight_surface` * `worst_case_feerate_per_kw` / 1000. For the 
`worst_case_feerate_per_kw`,
it's the hardest parameter to select, as while historical worst mempools 
network congestion
level are good empirical points, there are no guarantee of the future 
worst-case level of
congestion. Over-provisioning fee-bumping reserves for a node is coming 
with a high liquidity
downside.

About 2), the idea is to stop accepting inbound channels, if the local 
level of fee-bumping
reserves is falling under implemenetation-defined or operation-defined 
threshold. E.g Core-Lighting
has a `min-emergency-msat` option field tfor that purpose. This threshold 
can be extended for
outbound channel reserve and the addition / removal of HTLCs outputs on a 
commitment transactions,
i.e to reject HTLCs if the local fee-bumping reserves is too low.

About 3), the idea is along a payment path, the LN node partaking in the 
routing of the
HTLC could collaborate to unlash the locked HTLC on each hop, starting by 
the end to
allow each local node to compress their commitments transaction size. This 
would assume
some kind of interactivity happening successfully among each pair of LN 
nodes, and a new
option in the `node_announcement`, e.g `option_unlock_htlc`. It can be 
especially valuable 
for long-term HTLC kind of traffics (e.g the ones for swaps).

The LN implementations (LDK, LND, Core-Lighting, Eclair) implements 
different levels
of those mitigations. It is an open research question if more types of 
practical
mitigationscan be envisioned, implemented and deployed.

## Second-Layers Impact

As far as it's understood, this class of fee-bumping reserves attacks
is generally affecting any contract protocol or multi-party transactions,
where counterparties have a competing interest in concurrent and exclusive
confirmations of a set of transactions. In the presence of anchor output,
though in the lack of dynamic fee-bumping reserves management carefully
implemented, all lead to think use-cases described following the "contract
protocol" pattern can be more or less affected.

## Discovery

In 2020, a draft for anchor output submitted to the bolts. The anchor output
upgrades is designed to be a complete overhaul of the dynamic fee-management
for lightning channels, in a move way static fees only legacy channels. 
Initial
finding of economic pinning against lightning commitment and second-stage 
HTLC
transactions.

End of 2020, in the context of implementing a first version of anchor output
in rust-lightning [0], I realize that **spoiler alert** (a) Santa Clause 
does not
exist, as such (b) there will be no one to magically fulfill a lightning 
node
fee-bumping reserves for `option_anchor_outputs` just on time in case of 
unilateral
force-closure of a channel. This state of things could open the door to a 
counterparty
inflating the number of opened channels and their weight units sizes to 
induce
adversarial exploitations.

Being already busy with numerous other vulnerabilities at the time in 2020, 
including
the one that lead to the transition from `option_anchor_outputs` to 
`option_anchors_zero_fee_htlc_tx`
[4], I only reported the finding to a selected group of LN maintainers and 
devs in
July 2022. From then on, attacks vectors and ideas of efficient mitigations 
have been
discussed.


## Timeline

- 2022-07-11: Report of the finding to XXX, Bastien Teinturier (Eclair), 
Lisa Neigut
(C-lightning), YYY and Eugene Siegel (LND)
- 2022-07-17: Sharing to Olaoluwa Osuntunkun (LND)
- 2023-05-25: Sharing to Rusty Russell (C-Lightning), Fabrice Drouin 
(Eclair) and ZZZ
- 2023-07-25: Full disclosure put on ice until anchor output support in LDK
- 2025-02-27: Proposal of a full disclosure date in early weeks of June.
- 2025-03-03: CVE assigned by MITRE
- 2025-06-16: Full disclosure of CVE-2025-27586 and fee-bumping reserve 
exhaustion attacks

## Conclusion 

In this report, a new protocol-level attacks against bitcoin time-sensitive 
contract
protocols, specifically the LN, was introduced by exploiting the lack of a 
fee-reserves
provisioning mechanism to provide on-time sufficient fees amount for 
fee-bumping CPFP
attached on anchor output. This attack appears to be plausible against 
`option_anchors`
lightning channels funds under real-world scenario, while it deserves 
indeed more
investigation and experiment.

One challenge is effectively exploiting this vector of attacks is roughly 
guessing
the level of fee-bumping reserves available to the target LN node. While 
adequate
provisioning or just-in-time halting of the increase of a LN node all 
channels's
`max_channel_weight_surface` consistute a robust mitigation, more 
mitigations at
the protocol-level might alleviate the stuck liquidity burden coming as a 
downside
of such mitigations.

Do not trust, verify. All mistakes and opinions are my own.

Antoine

[0] https://github.com/lightningdevkit/rust-lightning/pull/642
[1] https://github.com/lightning/bolts/pull/688
[2] https://arxiv.org/abs/2007.00764
[4] 
https://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/linuxfoundation-pipermail/lightning-dev/2020-September/002800.txt 

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/fe76185f-8d9c-41b2-ab15-117d7787a204n%40googlegroups.com.

------=_Part_15919_1022834123.1749755010295
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,<br /><br />This report is to disclose a vector of attack affecting bitc=
oin time-sensitive<br />contract protocols, specifically the lightning netw=
ork by exhausting the fee-bumping<br />reserves of anchor-upgraded channels=
 of a lightning node.<br /><br />This attack vector has been known since th=
e early days of anchor output deployment<br />over the network circa end of=
 2020 and it has been discussed among LN maintainers<br />since circa mid 2=
022. While few basic mitigations have been developed and shipped<br />in LN=
 implementations over the last few years, it is believed that more robust<b=
r />mitigations can only be deployed at the protocol-level, thus unlikely t=
o happen<br />with an embargoed process.<br /><br />This class of attacks d=
ubbed "fee-bumping reserves exhaustion attacks" is<br />tracked at the prot=
ocol-level by CVE-2025-27586. As as far as it is understood<br />it is affe=
cting LN routing nodes (i.e a double-spent of an incoming / outgoing <br />=
HTLC) and LN payee (i.e revealing a preimage with `update_fulfill_htlc` and=
<br />double-spent with a HTLC-timeout). This is indeed a money stealing ki=
nd of attacks.<br /><br />While the attacks have not been tested under real=
-world configurations, they're<br />deemed as feasible, with the caveat of =
round guessing the level of fee-bumping<br />reserves for the adversary (se=
e corresponding section). If you're running a<br />LN node with subsequent =
funds at stake and deployed `option_anchor` channels<br />channels, I uphol=
d to reach out to the maintainers of your run LN implementations<br />for t=
ailored recommendations on how to adjust your fee-bumping reserves (some<br=
 />LN implementations are monolothic stacks, some are more modular not ship=
ping with<br />a wallet and here efficient mitigations is very tight with y=
our L1 wallet).<br /><br />The report is organized in the following fashion=
:<br />- background on LN fee-bumping<br />- explanation of the problem<br =
/>- the challenge: detecting a node fee-bumping reserves from the outside<b=
r />- lightning mitigations<br />- second-layers impact<br />- discovery<br=
 />- timeline<br /><br />A copy of the report is available here if formatti=
ng doesn't work well:<br />https://ariard.github.io/feebumping.html<br /><b=
r />## Background: Lightning Fee Estimation, Legacy Channel and `option_anc=
hor`<br /><br />Historically, the responsibility for fees has been on the c=
hannel initiator<br />(i.e the channel forwarding first the `open_channel` =
msg). The fees feeding<br />both counterparties commitment transaction is s=
ubstracted from the initiator<br />balance (`funding.is_outbound()` in LDK)=
. The feerate determinating the level<br />of absolute fees committed is se=
t by the flow of `update_fee` message.<br /><br />That msg is forward by th=
e channel initiator with a `feerate_per_kw`. If<br />the recipient estimate=
s from its local fee-estimation that the feerate is<br />good enough for ti=
mely processing and not unreasonably large, the feerate is<br />accepted. T=
his feerate is used to build the local and remote's versions<br />of the co=
mmitment transactions and the respective set of second-stage HTLC<br />tran=
sactions (`build_htlc_transaction()` in LDK).<br /><br />With this legacy m=
ode of fee-bumping, all the fee-bumping liquidity is <br />coming out of th=
e channel initator balance (i.e the `to_local` or `to_remote`<br />output a=
ccordingly), of which this balance is theorically the upper limit<br />to f=
ee-bump a version of the commitment tx and its second-stage HTLCs.<br /><br=
 />As of today, this `update_fee` mechanism is still supported by LN implem=
s<br />and this mechanism is still part of the BOLTs specification (BOLT #2=
 "Updating<br />Fees: `update_fee`). However, as it has been well-establish=
ed and understood<br />by the LN community since a long time, this mechanis=
m does not work very well<br />in an environment with dynamic fees. Indeed,=
 the pre-signed feerates at time<br />T might not suffice to get into a blo=
ck at time T + 100. Additionally, there<br />is no guarantee that the chann=
el counterparty is online or cooperative at time<br />T + 100 to re-sign a =
pair of commitment transaction with enhanced feerates.<br /><br />Therefore=
, since 2018, the LN community has been working on the anchor output<br />u=
pgrade, i.e adding a pair of dedicated outputs on each version of the commi=
tment<br />transaction (i.e historically `option_anchor_outputs` then `opti=
on_anchors_zero_fee_htlc_tx`,<br />now `option_anchors`). This anchor outpu=
t mechanism allows a LN node to attach<br />unilaterally a child-pay-for-pa=
rent on the commitment transaction it has to<br />include in a block.<br />=
<br />Making abstraction of any transaction-relay issue, the CPFP can const=
itute a<br />fee-bump of the overall package (the commitment tx + the cpfp =
tx), which is<br />increasing its feerate to increase the odds its block in=
clusion. In case of<br />time-sensitive HTLC outputs to claim (e.g a HTLC-p=
reimage to claim a "received"<br />output or a HTLC-timeout to claim a "off=
ered" output), timely inclusion in<br />blocks matters for a LN node.<br />=
<br />As of today, the `option_anchor` is not the default for LDK (v0.0.124=
 -<br />src/util/config.rs), is the default for LND (v.19.0-beta - sample-l=
nd.conf),<br />is the default for Core-Lightning (v.25.02 - lightningd/opti=
ons.c). Eclair has <br />not been checked because it's in Scala.<br /><br /=
>## Problem: Lack of Fee-Reserves Provisioning for Anchor Outputs Fee-Bumpi=
ng<br /><br />While the anchor output mechanism allows non-interactive fee-=
bumping of<br />a commitment transaction, the original specification of anc=
hor output never<br />mentions, neither indicates how the now external fee-=
bumping reserves should<br />be provisioned LN node and if any reactive act=
ions should be undertake in<br />face of network mempools congestions or hi=
gh block inclusion median feerate [1].<br /><br />The lack of fee-reserves =
provisioning exposes a LN node to a fee-bumping<br />reserve exhaustion att=
ack, where a malicious counterparty triggers inflation<br />of the LN node'=
s channel surface to exhaust the limited fee-bumping reserves.<br /><br />E=
.g if Alice's commitment transaction is pre-signed at 1 sat / vb, the<br />=
current size is 2000 bytes and the top block feerates ranks at 10 sat / vb,=
<br />Alice should have at least 19000 sats of fee-bumping reserves.<br /><=
br />Still, even if Alice has a sufficient level of reserves, if the channe=
l's<br />`max_accepted_htlcs` is uncapped (i.e up to the protocol limit of =
483 HTLCs<br />one-side), the channel counterparty Bob can inflate the size=
 of the commitment<br />transaction (e.g from 2000 bytes to 4000 bytes) up =
until Alice's fee-bumping<br />reserves are exhausted.<br /><br />E.g if Al=
ice, a routing node, has a pending HTLC of value 30k sats, and she has<br /=
>only 20k satoshis of reserves, if the block feerate is to be over 10 sats =
/ vbyte<br />up until the HTLC expires at block T=3D150, she won't be able =
to include her commitment<br />tx, before an incoming HTLC expires at block=
 T=3D100.<br /><br />In the lack of a monitored `max_channel_weight_surface=
` for each opended channel<br />binded with fee-bumping reserves, a LN node=
 is exposed to diverse fee-bumping<br />reserve exhaustion attacks.<br /><b=
r />Generally, there are 3 injection vectors that a LN counterparty, or a t=
hird-party<br />that can route through a channel opened with the target nod=
e, to inflate a LN node<br />global channel surface:<br />- opening more in=
bound channels<br />- asks for more outbound channels (e.g by buying Just-i=
n-Time channels)<br />- routing more offered / received HTLCs on an existen=
t given channel<br /><br />This class of attacks is dependent on the level =
of networks mempools congestion,<br />as with more congestions spikes in, m=
ore channels are exposed to the attack. The<br />attack difficulty of execu=
tion is deemed as medium, as only direct peering or<br />indirect peering w=
ith the target node is necessary and visibility on the ongoing<br />network=
s mempools congestion.<br /><br />For what is concerning, the adversy cost,=
 it is limited as the on-chain fees<br />to open more inbound channels, out=
-of-band fees to open more outbound channels.<br />It is unfairly cheap if =
the attack vector of routing HTLCs to inflate the size<br />of the LN chann=
el is leveraged, as off-chain fees are only currently paid in<br />case of =
success for LN. An adversary only has to overbid at the current block<br />=
inclusion feerate and the break even threshold is reached as long as the HT=
LC's<br />`amount_msat` is superior to the fee cost.<br /><br />## Detectin=
g a Node Fee-Bumping Reserves from the Outside<br /><br />There is one main=
 challenge for an adversary which is worth of awareness, namely<br />guessi=
ng the fee-bumping level of reserves of a target node, before to launch<br =
/>a fee-bumping reserve attack. Indeed, while LN implementations have pre-c=
onfigured<br />level of fee-bumping reserves automatically allocated which =
can be observed from<br />the code source of the diverse LN implementations=
, a LN node could have consequential<br />UTXO reserves in one or more L1 w=
allets.<br /><br />A first deanonymization heuristic to bound the fee-bumpi=
ng reserves level can be<br />to trigger a unilateral force close with a "d=
ecoy" test. E.g at block inclusion feerate<br />X, for 2 public channels pr=
ovokes a force-close of channel 1 and observe if the<br />target node Y is =
going to match the inclusion feerate for X with its CPFP attached<br />to c=
hannel 1. If yes, the adversary can estimate that the same level of reserve=
s holds<br />for channel 2. If no, the adversary can estimate that public c=
hannel is probably<br />exposed to a FBRE attack.<br /><br />This deanonymi=
zation heuristic can be generalized on long-tend stastical observations<br =
/>of a LN node by snitching all its unilateral force-closures from the on-c=
hain txn logs.<br /><br />A second tupe deanonymization heuristic can be to=
 observe the interactions with<br />the base-layer and the UTXO management,=
 e.g based on which BTC addresses are consumed<br />to feed the outbound ch=
annels opening, or the dual-funding channel opening by the<br />target node=
 (i.e all the operations of replenishment, funding, payment, settlement<br =
/>or collection) [2].<br /><br />One should make the observations that for =
L1 wallets coins to be leveraged as<br />fee-bumping reserves, the L1 walle=
t should be sufficently "hot" to be used in the<br />time span granted by t=
he lowest safety timelock for a deployed channel.<br /><br />## Lightning M=
itigations<br /><br />On the range of mitigations that can be implemented b=
y a LN implementation<br />there are 3 complementary plausible lines:<br />=
- 1) over-provisioning fee-bumping reserves<br />- 2) halting the increase =
of the LN node's all-channels's `max_channel_weight_surface`<br />- 3) coop=
eratively collaboring with LN peers to downcrease its local `max_channel_we=
ight_surface`.<br /><br />About the 1), which is the more obvious, the idea=
 is for a LN node to over-provision<br />the fee-bumping reserves with the =
following formula: `current_opened_channel` *<br />`max_channel_weight_surf=
ace` * `worst_case_feerate_per_kw` / 1000. For the `worst_case_feerate_per_=
kw`,<br />it's the hardest parameter to select, as while historical worst m=
empools network congestion<br />level are good empirical points, there are =
no guarantee of the future worst-case level of<br />congestion. Over-provis=
ioning fee-bumping reserves for a node is coming with a high liquidity<br /=
>downside.<br /><br />About 2), the idea is to stop accepting inbound chann=
els, if the local level of fee-bumping<br />reserves is falling under imple=
menetation-defined or operation-defined threshold. E.g Core-Lighting<br />h=
as a `min-emergency-msat` option field tfor that purpose. This threshold ca=
n be extended for<br />outbound channel reserve and the addition / removal =
of HTLCs outputs on a commitment transactions,<br />i.e to reject HTLCs if =
the local fee-bumping reserves is too low.<br /><br />About 3), the idea is=
 along a payment path, the LN node partaking in the routing of the<br />HTL=
C could collaborate to unlash the locked HTLC on each hop, starting by the =
end to<br />allow each local node to compress their commitments transaction=
 size. This would assume<br />some kind of interactivity happening successf=
ully among each pair of LN nodes, and a new<br />option in the `node_announ=
cement`, e.g `option_unlock_htlc`. It can be especially valuable <br />for =
long-term HTLC kind of traffics (e.g the ones for swaps).<br /><br />The LN=
 implementations (LDK, LND, Core-Lighting, Eclair) implements different lev=
els<br />of those mitigations. It is an open research question if more type=
s of practical<br />mitigationscan be envisioned, implemented and deployed.=
<br /><br />## Second-Layers Impact<br /><br />As far as it's understood, t=
his class of fee-bumping reserves attacks<br />is generally affecting any c=
ontract protocol or multi-party transactions,<br />where counterparties hav=
e a competing interest in concurrent and exclusive<br />confirmations of a =
set of transactions. In the presence of anchor output,<br />though in the l=
ack of dynamic fee-bumping reserves management carefully<br />implemented, =
all lead to think use-cases described following the "contract<br />protocol=
" pattern can be more or less affected.<br /><br />## Discovery<br /><br />=
In 2020, a draft for anchor output submitted to the bolts. The anchor outpu=
t<br />upgrades is designed to be a complete overhaul of the dynamic fee-ma=
nagement<br />for lightning channels, in a move way static fees only legacy=
 channels. Initial<br />finding of economic pinning against lightning commi=
tment and second-stage HTLC<br />transactions.<br /><br />End of 2020, in t=
he context of implementing a first version of anchor output<br />in rust-li=
ghtning [0], I realize that **spoiler alert** (a) Santa Clause does not<br =
/>exist, as such (b) there will be no one to magically fulfill a lightning =
node<br />fee-bumping reserves for `option_anchor_outputs` just on time in =
case of unilateral<br />force-closure of a channel. This state of things co=
uld open the door to a counterparty<br />inflating the number of opened cha=
nnels and their weight units sizes to induce<br />adversarial exploitations=
.<br /><br />Being already busy with numerous other vulnerabilities at the =
time in 2020, including<br />the one that lead to the transition from `opti=
on_anchor_outputs` to `option_anchors_zero_fee_htlc_tx`<br />[4], I only re=
ported the finding to a selected group of LN maintainers and devs in<br />J=
uly 2022. From then on, attacks vectors and ideas of efficient mitigations =
have been<br />discussed.<br /><br /><br />## Timeline<br /><br />- 2022-07=
-11: Report of the finding to XXX, Bastien Teinturier (Eclair), Lisa Neigut=
<br />(C-lightning), YYY and Eugene Siegel (LND)<br />- 2022-07-17: Sharing=
 to Olaoluwa Osuntunkun (LND)<br />- 2023-05-25: Sharing to Rusty Russell (=
C-Lightning), Fabrice Drouin (Eclair) and ZZZ<br />- 2023-07-25: Full discl=
osure put on ice until anchor output support in LDK<br />- 2025-02-27: Prop=
osal of a full disclosure date in early weeks of June.<br />- 2025-03-03: C=
VE assigned by MITRE<br />- 2025-06-16: Full disclosure of CVE-2025-27586 a=
nd fee-bumping reserve exhaustion attacks<br /><br />## Conclusion <br /><b=
r />In this report, a new protocol-level attacks against bitcoin time-sensi=
tive contract<br />protocols, specifically the LN, was introduced by exploi=
ting the lack of a fee-reserves<br />provisioning mechanism to provide on-t=
ime sufficient fees amount for fee-bumping CPFP<br />attached on anchor out=
put. This attack appears to be plausible against `option_anchors`<br />ligh=
tning channels funds under real-world scenario, while it deserves indeed mo=
re<br />investigation and experiment.<br /><br />One challenge is effective=
ly exploiting this vector of attacks is roughly guessing<br />the level of =
fee-bumping reserves available to the target LN node. While adequate<br />p=
rovisioning or just-in-time halting of the increase of a LN node all channe=
ls's<br />`max_channel_weight_surface` consistute a robust mitigation, more=
 mitigations at<br />the protocol-level might alleviate the stuck liquidity=
 burden coming as a downside<br />of such mitigations.<br /><br />Do not tr=
ust, verify. All mistakes and opinions are my own.<br /><br />Antoine<br />=
<br />[0] https://github.com/lightningdevkit/rust-lightning/pull/642<br />[=
1] https://github.com/lightning/bolts/pull/688<br />[2] https://arxiv.org/a=
bs/2007.00764<br />[4] https://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/lin=
uxfoundation-pipermail/lightning-dev/2020-September/002800.txt=C2=A0

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/fe76185f-8d9c-41b2-ab15-117d7787a204n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/fe76185f-8d9c-41b2-ab15-117d7787a204n%40googlegroups.com</a>.<br />

------=_Part_15919_1022834123.1749755010295--

------=_Part_15918_955359903.1749755010295--