ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-12 📝 Original message: Good morning Rusty and ...
📅 Original date posted:2018-10-12
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181012/ad5e2132/attachment.html>;
📝 Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181012/ad5e2132/attachment.html>;