Why/when/how to change the ChannelId of the spliced channel?

[optout21]

Does the ChannelId change during the splicing process? Yes.

Why? On one hand, channel ID is derived from the funding TX, which will be different, and also, spliced channel will be V2 channel, where the ID is derived from the revocation point. Also, the channel parameters change (capacity), so it makes sense to change the ID as well.

When? TBD, most likely at the same time when the channel funding transaction and channel capacity is changed.

How? TBD how the new channel info is propagated over gossip.

[wpaulino]

It should change when the splice transaction reaches the confirmation depth requested. While the splice transaction is acked but awaiting confirmation, we'll probably track a mapping of new channel_id to old so we can handle incoming messages using the new channel_id.

[optout21]

My unclear points in more concrete terms:

• the implementation details regarding how the Channel has to be removed and added with the new ID to maps
• how to ensure that new gossip info is sent out with the new channel ID

[wpaulino]

the implementation details regarding how the Channel has to be removed and added with the new ID to maps

This is something I aim to brainstorm on over the next two weeks or so. We'll probably want a wrapper struct around the existing Channel struct, in which we move most of the funding info (channel_id, funding_txo, etc.) into the wrapper, and track all pending splices within it. Having a separate Channel struct per splice seems wasteful, but I'll make sure to explore such an approach as well.

how to ensure that new gossip info is sent out with the new channel ID

If we only have one Channel struct as proposed above, it should be pretty simple to ensure the current channel_id is used until a splice confirms, at which point we switch to using the new one.

[optout21]

We'll probably want a wrapper struct around the existing Channel struct, in which we move most of the funding info (channel_id, funding_txo, etc.) into the wrapper, and track all pending splices within it. Having a separate Channel struct per splice seems wasteful, but I'll make sure to explore such an approach as well.

My current approach is kind of the opposite: a struct holding the splice-specific info of a pending splice (relative change, funding tx, etc), and include in Channel such a struct (a vector of them; 0, 1 or more).

[wpaulino]

I think we'll need some kind of "child" Channel struct that is specific per slice since we'll need to handle HTLC updates separately for each splice.