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.

Lightning-dev mailing list

Reply via email to