ElementsProject / ElementsProject/lightning
Splicing: signer interface for local funding-key rotation
- 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.