Good morning Rusty and Christian and list,

> This is one of the cases where a simpler solution (relatively
> speaking ^^) is to be preferred imho, allowing for future
> iterations.

I would basically agree here, with the further proviso that I think splice is 
not quite as priority as AMP, decorrelation, or watchtowers.

The simpler solution has the drawback of more transactions onchain, but 
massively reduces the complexity of maintaining parallel state updates.  
Parallel updates would increase greatly our need to test the feature in various 
conditions (and specify also in the formal spec what possible failure modes are 
and how they should be recovered, as a basic safety for users of Lightning).

Of course, the same course of thought is what lead to onchain transaction bloat 
in the first place.

Splicing features might be versioned, with the possibility of better splicing 
mechanisms being defined in later BOLT specs.  This can allow us to iterate 
somewhat and start with the simpler-but-more-onchain-txes splicev1 feature, 
possibly getting replaced with a more thought-out-and-planned splicev2 feature 
with parallel updates (and careful analysis of possible failures in parallel 
updates and how we should recover from them).  The drawback is that this is 
further complexity later on by having to possibly support multiple splicing 
mechanisms (but if we assign completely separate feature bits, it may be 
possible for pragmatic implementations to eventually stop signalling the 
ability to splice using older splicing feature versions in favor of newer 
splicing feature versions).

Lightning-dev mailing list

Reply via email to