AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 31 Bitcoin

Allow `KeysManager` to opt-into the new `remote_key` derivation

Public commit record

What the developer wrote

Authored by Matt Corallo

90/100 · Strong
Allow `KeysManager` to opt-into the new `remote_key` derivation

The `remote_key` derived by default in `KeysManager` depends on the
chanel's `channel_keys_id`, which generally has sufficient entropy
that without it the `remote_key` cannot be re-derived. In disaster
case where there is no remaining state except the `KeysManager`'s
`seed`, this results in lost funds, even if the counterparty
force-closes the channel.

Luckily, because of the `static_remote_key` feature, there's no
need for this. If the `remote_key` we derive is one of a countable
set, we can simply scan the chain for outputs to our `remote_key`s.

Here we finally allow users to opt into the new derivation scheme,
using the new derivation scheme for `remote_key`s for new and
spliced channels if a new `KeysManager::new` argument is set to
`true`.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds an opt-in feature to LDK's key manager that changes how on-chain backup addresses are derived when a channel is force-closed by the other party. The new derivation makes these addresses come from a small, predictable set, so a user who loses all channel state but still has their seed can scan the blockchain and recover funds. Without this, the old derivation required per-channel secrets that might be lost, making funds unrecoverable in a disaster scenario. It is a safety/recovery improvement, not a fix for an active exploit.

Recommended action

No immediate action is required; this is a defensive recovery feature. Node operators who value disaster recovery should opt into `v2_remote_key_derivation` when creating new `KeysManager` instances, understanding that enabling it for new channels prevents downgrades to LDK versions before 0.2. Operators should ensure backups of channel state remain the primary protection, with this feature as a safety net.

Security signals we found

01

New key derivation flag added to `KeysManager::new` and `PhantomKeysManager::new`

02

Old `remote_key` derivation depended on `channel_keys_id`, making funds unrecoverable if channel state is lost

03

New derivation uses a static set of keys, enabling blockchain scanning for disaster recovery

04

Spliced channels are forced onto the new derivation because downgrades are already broken by splicing

05

Documentation warns users must not downgrade to LDK < 0.2 if the flag is enabled

Risk score

Why this scored 31/100

Our methodology →
Potential impact 8/30
Exploitability 3/25
Stealth signal 2/15
Affected reach 7/15
Confidence 7/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.