From ZmnSCPxj at protonmail.com Fri Oct 12 06:13:49 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Fri, 12 Oct 2018 06:13:49 +0000 Subject: [Lightning-dev] Splicing Proposal: Feedback please! In-Reply-To: <87ftxb7pya.fsf@rustcorp.com.au> References: <878t36a2hk.fsf@rustcorp.com.au> <87ftxb7pya.fsf@rustcorp.com.au> Message-ID: 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