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.

How a guessed ID can expose a hidden funding link

Compare the documented onion-message probe before and after LDK's October 25 code fix.
A real channel ID encodes a funding output's location THE ID IS A SET OF BLOCKCHAIN COORDINATESBlock heightTransaction indexOutput indexReal SCIDFunding locationThe probe asks: does this output fund a channel between these nodes?
Block, transaction and output identify the real SCID THE FUNDING LOCATIONBlockTransactionOutputReal short-channel IDDoes this output fund a channelbetween the suspected nodes?

Where the probe stops

Where the probe stopsBefore the fixAfter the fix
A returned message confirms the candidate funding-output link under the documented probe conditions.
Before fix: returned message confirms funding link CONDITION: THE ATTACKER CONNECTS TO BOTH ENDPOINTSAttackerNode ANode BGuessed real SCIDUnannounced channelMessage forwardedOnion message returns to the attackerSuccessful return confirms the candidate funding link.
Before fix: message goes through A and B back to attacker Connected to both endpointsAttackerNode ANode BGuessed real SCIDUnannouncedchannel: A to BReturn confirms funding link
LDK rejects the unannounced channel's real SCID unless it is the outbound alias. Valid aliases remain usable.
After fix: real-ID lookup rejected CONDITION: THE ATTACKER CONNECTS TO BOTH ENDPOINTSAttackerNode ANode BGuessed real SCIDUnannounced channelNode A rejects real-ID lookupUnless that value is the outbound aliasValid aliases remain usable.
After fix: guessed real-ID lookup stops at node A Connected to both endpointsAttackerNode ANode BGuessed real SCIDChannelA to BNode A rejectsreal-ID lookupException: value is outbound aliasValid aliases still work

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.

This content is provided for general informational purposes only and doesn't constitute financial, investment, legal, or tax advice. Any events, rewards, online promotions, or related information mentioned herein should not be considered a recommendation, solicitation, or invitation to purchase, sell, trade, or otherwise deal in any crypto assets. Crypto assets are highly volatile and may result in loss. The availability of WEEX services, products, and related events may vary by region. You are responsible for ensuring that your participation is in accordance with applicable local laws and regulations.