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