splice: signer must be informed of splice params

[vincenzopalazzo]

The signer needs to know when the splice operation starts and the splice parameters for each splice transaction candidate.

The channel establishment v2 (dual funding) code path already notifies the signer via the hsmd API hsmd_ready_channel calls However, the splicing code path does not.

Fixes: #6723

Suggested-by: @devrandom
Co-Developed-by: @devrandom
Co-Developed-by: Ken Sedgwick ken@bonsai.com

[vincenzopalazzo]

We discuss the semantics of the push_value with the VLS team, and we conclude that the push_value may be used as a control value. This mean with splice that the push value is the funded relative amount that the remote node is pushing inside the channel after the tx_complete message exchange.

P.S: This semantics can change in the future iirc @devrandom and @ksedgwic are still thinking about all the design possibility

[devrandom]

[deleted - attached message to wrong PR]

[devrandom]

this generally looks fine, but I didn't check all the call sites in detail

[vincenzopalazzo]

but I didn't check all the call sites in detail

I follow the @ksedgwic call here, but we call the hsmd function in two places:

• splice_accepter, after the tx_complete is exchanged
• splice_initiator_user_finalized: after the tx_complete is exchanged

and we set the push_value as described before and the channel_value to the total channel amount including splice values and inflight update.

Let me know if this needs some more love somewhere :)

[ksedgwic]

The assertion in libhsmd.c:

	/* Fail fast if any values are uninitialized or obviously wrong. */
	...
	assert(amount_msat_less_eq(push_value, value_msat));
	...

may not make sense if we change the meaning of push_value to be relative, especially since negative values appear as large positive?

I recommend striking that assertion; I don't think there is any useful assertion to replace it with.

[ksedgwic]

This looks good to me.

[ksedgwic]

I still think we need to strike (remove) the assertion in libhsmd.c as described above #6746 (comment)

[vincenzopalazzo]

I still think we need to strike (remove) the assertion in libhsmd.c as described above #6746 (comment)

Thanks @ksedgwic, I missed this.

I pushed it on d10f33b because I think it deserves a proper commit explanation

[ksedgwic]

ACK a8e9cd6b

[rustyrussell]

Ack a8e9cd6