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). Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
