CLN currently reuses the existing local funding key when creating a splice.
Both splice_init and splice_ack use the current:
&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.
CLN currently reuses the existing local funding key when creating a splice.
Both
splice_initandsplice_ackuse the current: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_ackis 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_ackand 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
hsmdand 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.