ElementsProject / ElementsProject/lightning

Splicing: signer interface for local funding-key rotation

Open
#9,500 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
3.1k
Forks
1k
Avg merge
4d 10h
Merged PRs (30d)
13

Description

CLN currently reuses the existing local funding key when creating a splice.

Both `splice_init` and `splice_ack` use the current:

```c
&peer->channel->funding_pubkey[LOCAL]
```

and the replacement funding output is built using that same local key.

Local key reuse itself does not block the current VLS integration, since VLS can follow the existing CLN behavior and reuse the current funding key.

**Possible improvement**

If local funding-key rotation is something we want to support, the signer would need to provide the funding pubkey before `splice_init` / `splice_ack` is sent, so CLN and the signer agree on the key used for the new funding generation.

One possible model would be a per-channel funding-key generation or identifier. CLN could request the funding pubkey for the new generation from the signer before sending `splice_init` / `splice_ack` and persist enough information with the splice state to later associate signer operations with the correct funding generation.

That association does not necessarily need to be a new identifier on every signing request; it could potentially be derived from information already present, such as the funding outpoint or candidate state.

Restart and repeated requests should resolve to the same key, and RBF attempts belonging to the same splice should continue using the same funding generation. We would also need to define what happens to an allocated generation if a splice is abandoned.

The existing funding output would continue using its existing funding key while the replacement generation is pending.

This could use the same signer-facing flow for native `hsmd` and external signers, while leaving the actual key derivation/storage as an implementation detail of the signer.

I haven't proposed a specific wire-format change yet since I mainly wanted to check whether the current key reuse is intentional and whether there is already a preferred direction for supporting rotation.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.