While working on VLS splicing integration, I came across what looks like a bug in the signer setup path when the peer rotates its funding key.
CLN correctly stores the candidate key in:
but update_hsmd_with_splice() still passes the current channel key to hsmd_setup_channel:
&peer->channel->funding_pubkey[REMOTE]
At that point the channel key is still the old funding key; it is only updated after splice_locked.
I suspect this was easy to miss because CLN currently does not rotate its own funding key during splicing, so CLN-to-CLN tests normally see the same key, and native hsmd does not validate the SetupChannel fields. For an external validating signer like VLS, however, this matters because it can receive the new funding outpoint together with the old remote funding key.
The fix seems to be to pass the candidate key instead:
&inflight->remote_funding
and if possible add a regression test where the peer actually rotates its funding key.
While working on VLS splicing integration, I came across what looks like a bug in the signer setup path when the peer rotates its funding key.
CLN correctly stores the candidate key in:
but
update_hsmd_with_splice()still passes the current channel key tohsmd_setup_channel:At that point the channel key is still the old funding key; it is only updated after
splice_locked.I suspect this was easy to miss because CLN currently does not rotate its own funding key during splicing, so CLN-to-CLN tests normally see the same key, and native
hsmddoes not validate theSetupChannelfields. For an external validating signer like VLS, however, this matters because it can receive the new funding outpoint together with the old remote funding key.The fix seems to be to pass the candidate key instead:
and if possible add a regression test where the peer actually rotates its funding key.