rich1.0npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lhttps://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://nostr.ae📅 Original date posted:2018-10-12 📝 Original message: 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