Good morning Christian,

> The connection the channel factories is not really necessary, as long as
> we have an invalidation scheme that allows us to invalidate a prior
> funding transaction we can reseat without needing a cut-through, just
> invalidate the funding tx of the old channel and add the funding tx for
> the new one in the new state.

Indeed, it is unnecessary at all.

My consideration, was that we could present it as an operation to wallet 
implementers (or advanced users).

In much the same way that it would be sensible to present a `multifundchannel` 
command at c-lightning RPC level, it would be sensible to present a 
`reseatchannel` command at c-lightning RPC level to transfer the remaining 
funds of a channel from one peer to a new channel to another (or possibly to 
splice-out from one and immediately splice-in to another).

Prior to Burchert-Decker-Wattenhofer channel factories being deployed, 
`multifundchannel` and `reseatchannel` would use current operations (multiple  
channel funding txouts from one funding tx for the former, separate 
close-then-open operations for the latter (possibly implemented with 
cut-through if it can be specced)).  Then when the Burchert-Decker-Wattenhofer 
channel factories are deployed we can optimize (`multifundchannel` actually 
creates a new channel factory with this node and all nodes listed in the 
multi-fund operation as members of the factory, with the starting fund only 
happening to come from this node only; `reseatchannel` is an offchain channel 
reorganization request to the factory).

Lightning-dev mailing list

Reply via email to