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

Convert `ChannelSigner::pubkeys` to only fetch *new* pubkeys

Public commit record

What the developer wrote

Authored by Matt Corallo

90/100 · Strong
Convert `ChannelSigner::pubkeys` to only fetch *new* pubkeys

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.

In the next commit, we'll start using different `remote_key`s based
on a config knob the user sets, but with the current
`ChannelSigner::pubkeys` API this would be invalid - we can't
return a different set of keys for a re-derived `ChannelSigner`.
Luckily, this isn't actually how LDK uses `ChannelSigner::pubkeys`,
it actually only calls it when it wants a new set of pubkeys,
either for a new channel or a splice.

Thus, here, we rename `ChannelSigner::pubkeys` to
`ChannelSigner::new_pubkeys` and update documentation to match.
✓ 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 is a preparatory refactor in LDK's key-handling code. It renames a trait method from `pubkeys` to `new_pubkeys` and changes the default signer so it no longer caches a fixed set of holder public keys. The stated goal is to allow future code to return different keys for newly created channels or splices while still being able to sign for any keys ever returned. The commit message explicitly frames this as avoiding a potential fund-loss scenario in disaster recovery, but the actual diff is an API and internal-state change, not a complete fix. It does not by itself introduce or fully patch a vulnerability.

Recommended action

Treat this as a design-level refactor rather than an immediate security patch. Review the subsequent commit that adds the configurable `remote_key` derivation and chain-scanning logic to assess the actual security improvement. Ensure downstream signers implementing `ChannelSigner` correctly honor the new contract: `new_pubkeys` may return varying keys, but all signing methods must remain valid for every key set ever returned.

Security signals we found

01

API rename from `pubkeys` to `new_pubkeys` with semantic contract change

02

Removal of cached `holder_channel_pubkeys` from `InMemorySigner`

03

Documentation now allows `new_pubkeys` to return different keys per call

04

Commit message describes potential lost-funds scenario if `channel_keys_id` is lost

05

References future commit that will add configurable `remote_key` derivation

06

No new input validation, bounds checking, or cryptographic hardening in diff

Risk score

Why this scored 24/100

Our methodology →
Potential impact 5/30
Exploitability 2/25
Stealth signal 3/15
Affected reach 4/15
Confidence 7/10
Evidence quality 3/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.