Bitcoin Lightning fix blocks a probe linking private channels to onchain funding

Lightning Development Kit (LDK), software used to build Bitcoin Lightning applications, has a privacy fix that blocks a documented probe linking an unannounced channel to the Bitcoin output backing it. The probe exploited how LDK forwarded onion messages, turning a guessed channel identifier into confirmation of a connection between two suspected nodes.

Bitcoin Optech highlighted the change on October 30. An unannounced channel stays out of the public network map, but that alone did not prevent LDK’s message-forwarding lookup from confirming its funding link.

A real short-channel ID, or SCID, works like blockchain coordinates. The Lightning specification defines it using the block height, the transaction’s position within that block and the output’s position within that transaction. Together, those identify the particular Bitcoin output funding a channel.

An attacker can derive a candidate ID from an output’s location without yet knowing whether it belongs to a channel between the suspected nodes. The documented probe supplies that missing confirmation. It requires the attacker to connect to both endpoints and construct an onion-message path through them that returns to the attacker.

Before the fix, LDK’s channel lookup could resolve a real SCID even for an unannounced channel once its funding confirmed. If the message returned successfully, the attacker could confirm that the guessed output and the channel between those nodes matched.

Where the probe stops

A returned message confirms the candidate funding-output link under the documented probe conditions.

LDK blocks the unannounced channel’s real-ID lookup; valid aliases remain usable.

Requires attacker connections to both suspected endpoints and a candidate real SCID. Rejection excepts a value equal to the outbound alias. The merge does not establish release inclusion or deployed wallet coverage.

Sources and evidence

Sources

1. LDK PR 5314: mechanism and fix
2. BOLT 7: real short-channel ID definition
3. Bitcoin Optech: documented privacy probe
4. Official changelog: release-scope context

Supporting facts

• In the documented probe, an unrelated peer connected to both suspected channel endpoints can use a guessed real short-channel ID in an onion-message path through those nodes back to itself; successful receipt confirms the candidate channel’s funding-output link. [1] [3]
• A real short-channel ID encodes the funding output’s blockchain location: the block height, the transaction’s position inside that block, and the output’s position inside the transaction. [2]
• Before the fix, LDK’s ChannelManager lookup could resolve real IDs of unannounced channels after their funding confirmed, so omitting a channel from public gossip did not prevent this onion-message lookup from confirming its onchain location. [1] [3]
• The fix rejects a real short-channel ID for an unannounced channel during onion-message next-node lookup unless that value is the channel’s outbound alias, while leaving valid aliases usable. [1] [3]
• This fix concerns onion-message forwarding; the PR explicitly makes the lookup stricter than an HTLC payment-relay path that can permit real IDs for some private channels under configuration. [1] [3]
• The reviewed PR and technical summary demonstrate a funding-output link to suspected channel endpoints; they provide no evidence of stolen bitcoin, compromised private keys, unrelated wallet holdings being revealed, or exposure of every Lightning channel. [1] [3]
• The October 25 merge establishes a source-code fix; the reviewed official changelog does not establish a release or deployed wallet version containing it. [1] [4]

Method

Schematic of the documented lookup and message path. Arrows represent onion messages, not bitcoin transfers. Before/after panels describe code behavior; positions and lengths are not measurements.

Scope

Requires attacker connections to both suspected endpoints and a candidate real SCID. Rejection excepts a value equal to the outbound alias. The merge does not establish release inclusion or deployed wallet coverage.

Infographic by CryptoSlate

The demonstrated leak therefore joins two pieces of information: a Bitcoin funding output and the Lightning nodes using it.

What the fix changes

LDK now refuses to resolve an unannounced channel’s real SCID for onion-message forwarding. Valid aliases remain usable as alternative identifiers, so a sender can address the channel without using its real blockchain coordinates. The change closes this lookup route while preserving forwarding that uses an allowed alias.

The change is described in the pull request. Under BOLT 4’s onion-routing rules, an onion-message SCID must correspond to an announced identifier or a local alias.

The fix’s inclusion in installed wallet versions remains unverified. Users need confirmation from their wallet provider before assuming installed software has this protection.