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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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,

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

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

This class of attacks d= ubbed "fee-bumping reserves exhaustion attacks" is
tracked at the prot= ocol-level by CVE-2025-27586. As as far as it is understood
it is affe= cting 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 ki= nd 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 (se= e corresponding section). If you're running a
LN node with subsequent = funds at stake and deployed `option_anchor` channels
channels, I uphol= d to reach out to the maintainers of your run LN implementations
for t= ailored recommendations on how to adjust your fee-bumping reserves (someLN implementations are monolothic stacks, some are more modular not ship= ping with
a wallet and here efficient mitigations is very tight with y= our 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 formatti= ng doesn't work well:
https://ariard.github.io/feebumping.html
## Background: Lightning Fee Estimation, Legacy Channel and `option_anc= hor`

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

That msg is forward by th= e channel initiator with a `feerate_per_kw`. If
the recipient estimate= s from its local fee-estimation that the feerate is
good enough for ti= mely processing and not unreasonably large, the feerate is
accepted. T= his feerate is used to build the local and remote's versions
of the co= mmitment transactions and the respective set of second-stage HTLC
tran= sactions (`build_htlc_transaction()` in LDK).

With this legacy m= ode of fee-bumping, all the fee-bumping liquidity is
coming out of th= e channel initator balance (i.e the `to_local` or `to_remote`
output a= ccordingly), of which this balance is theorically the upper limit
to f= ee-bump a version of the commitment tx and its second-stage HTLCs.
As of today, this `update_fee` mechanism is still supported by LN implem= s
and this mechanism is still part of the BOLTs specification (BOLT #2= "Updating
Fees: `update_fee`). However, as it has been well-establish= ed and understood
by the LN community since a long time, this mechanis= m 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 blo= ck at time T + 100. Additionally, there
is no guarantee that the chann= el 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
u= pgrade, i.e adding a pair of dedicated outputs on each version of the commi= tment
transaction (i.e historically `option_anchor_outputs` then `opti= on_anchors_zero_fee_htlc_tx`,
now `option_anchors`). This anchor outpu= t mechanism allows a LN node to attach
unilaterally a child-pay-for-pa= rent on the commitment transaction it has to
include in a block.
=
Making abstraction of any transaction-relay issue, the CPFP can const= itute a
fee-bump of the overall package (the commitment tx + the cpfp = tx), which is
increasing its feerate to increase the odds its block in= clusion. In case of
time-sensitive HTLC outputs to claim (e.g a HTLC-p= reimage to claim a "received"
output or a HTLC-timeout to claim a "off= ered" 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-l= nd.conf),
is the default for Core-Lightning (v.25.02 - lightningd/opti= ons.c). Eclair has
not been checked because it's in Scala.

## Problem: Lack of Fee-Reserves Provisioning for Anchor Outputs Fee-Bumpi= ng

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

The lack of fee-reserves = provisioning exposes a LN node to a fee-bumping
reserve exhaustion att= ack, 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.
<= br />Still, even if Alice has a sufficient level of reserves, if the channe= l'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 Al= ice, 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=3D150, she won't be able = to include her commitment
tx, before an incoming HTLC expires at block= T=3D100.

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 t= hird-party
that can route through a channel opened with the target nod= e, to inflate a LN node
global channel surface:
- opening more in= bound channels
- asks for more outbound channels (e.g by buying Just-i= n-Time channels)
- routing more offered / received HTLCs on an existen= t given channel

This class of attacks is dependent on the level = of networks mempools congestion,
as with more congestions spikes in, m= ore channels are exposed to the attack. The
attack difficulty of execu= tion is deemed as medium, as only direct peering or
indirect peering w= ith the target node is necessary and visibility on the ongoing
network= s 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 chann= el 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 HT= LC's
`amount_msat` is superior to the fee cost.

## Detectin= g a Node Fee-Bumping Reserves from the Outside

There is one main= challenge for an adversary which is worth of awareness, namely
guessi= ng the fee-bumping level of reserves of a target node, before to launch
a fee-bumping reserve attack. Indeed, while LN implementations have pre-c= onfigured
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 w= allets.

A first deanonymization heuristic to bound the fee-bumpi= ng reserves level can be
to trigger a unilateral force close with a "d= ecoy" test. E.g at block inclusion feerate
X, for 2 public channels pr= ovokes 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 c= hannel 1. If yes, the adversary can estimate that the same level of reserve= s holds
for channel 2. If no, the adversary can estimate that public c= hannel is probably
exposed to a FBRE attack.

This deanonymi= zation heuristic can be generalized on long-tend stastical observations
of a LN node by snitching all its unilateral force-closures from the on-c= hain 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 ch= annels 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 walle= t should be sufficently "hot" to be used in the
time span granted by t= he lowest safety timelock for a deployed channel.

## Lightning M= itigations

On the range of mitigations that can be implemented b= y 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) coop= eratively collaboring with LN peers to downcrease its local `max_channel_we= ight_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_surf= ace` * `worst_case_feerate_per_kw` / 1000. For the `worst_case_feerate_per_= kw`,
it's the hardest parameter to select, as while historical worst m= empools network congestion
level are good empirical points, there are = no guarantee of the future worst-case level of
congestion. Over-provis= ioning fee-bumping reserves for a node is coming with a high liquidity
downside.

About 2), the idea is to stop accepting inbound chann= els, if the local level of fee-bumping
reserves is falling under imple= menetation-defined or operation-defined threshold. E.g Core-Lighting
h= as a `min-emergency-msat` option field tfor that purpose. This threshold ca= n 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
HTL= C 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 successf= ully among each pair of LN nodes, and a new
option in the `node_announ= cement`, 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 lev= els
of those mitigations. It is an open research question if more type= s of practical
mitigationscan be envisioned, implemented and deployed.=

## Second-Layers Impact

As far as it's understood, t= his class of fee-bumping reserves attacks
is generally affecting any c= ontract protocol or multi-party transactions,
where counterparties hav= e a competing interest in concurrent and exclusive
confirmations of a = set of transactions. In the presence of anchor output,
though in the l= ack 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 outpu= t
upgrades is designed to be a complete overhaul of the dynamic fee-ma= nagement
for lightning channels, in a move way static fees only legacy= channels. Initial
finding of economic pinning against lightning commi= tment and second-stage HTLC
transactions.

End of 2020, in t= he context of implementing a first version of anchor output
in rust-li= ghtning [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 co= uld open the door to a counterparty
inflating the number of opened cha= nnels 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 `opti= on_anchor_outputs` to `option_anchors_zero_fee_htlc_tx`
[4], I only re= ported the finding to a selected group of LN maintainers and devs in
J= uly 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 discl= osure put on ice until anchor output support in LDK
- 2025-02-27: Prop= osal of a full disclosure date in early weeks of June.
- 2025-03-03: C= VE assigned by MITRE
- 2025-06-16: Full disclosure of CVE-2025-27586 a= nd fee-bumping reserve exhaustion attacks

## Conclusion
In this report, a new protocol-level attacks against bitcoin time-sensi= tive contract
protocols, specifically the LN, was introduced by exploi= ting the lack of a fee-reserves
provisioning mechanism to provide on-t= ime sufficient fees amount for fee-bumping CPFP
attached on anchor out= put. This attack appears to be plausible against `option_anchors`
ligh= tning channels funds under real-world scenario, while it deserves indeed mo= re
investigation and experiment.

One challenge is effective= ly exploiting this vector of attacks is roughly guessing
the level of = fee-bumping reserves available to the target LN node. While adequate
p= rovisioning or just-in-time halting of the increase of a LN node all channe= ls'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 tr= ust, 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/a= bs/2007.00764
[4] https://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/lin= uxfoundation-pipermail/lightning-dev/2020-September/002800.txt=C2=A0

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