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).
Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
