Good morning Rusty, > > > It may be good to start brainstorming possible failure modes during splice, > > and how to recover, and also to indicate the expected behavior in the > > proposal, as I believe these will be the points where splicing must be > > designed most precisely. What happens when a splice is ongoing and the > > communication gets disconnected? What happens when some channel failure > > occurs during splicing and we are forced to drop onchain? And so on. > > Agreed, but we're now debating two fairly different methods for > splicing. Once we've decided on that, we can try to design the > proposals themselves.
I would suggest more to consider the simpler method, despite its larger onchain footprint (which is galling), but mostly because I do not see splicing as being as important as AMP or watchtowers (and payment decorrelation seems to affect how AMP can be implemented, so its priority also goes up). So I think getting *some* splicing design out would be better even if imperfect. Others may disagree on priority. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
