{"type":"rich","version":"1.0","author_name":"npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","author_url":"https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-10-12\n📝 Original message:\nGood morning Rusty,\n\n\u003e\n\u003e \u003e 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.\n\u003e\n\u003e Agreed, but we're now debating two fairly different methods for\n\u003e splicing. Once we've decided on that, we can try to design the\n\u003e proposals themselves.\n\nI 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.\n\nRegards,\nZmnSCPxj"}