{"type":"rich","version":"1.0","author_name":"npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","author_url":"https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-10-12\n📝 Original message:\nGood morning Rusty and Christian and list,\n\n\u003e This is one of the cases where a simpler solution (relatively\n\u003e speaking ^^) is to be preferred imho, allowing for future\n\u003e iterations.\n\nI would basically agree here, with the further proviso that I think splice is not quite as priority as AMP, decorrelation, or watchtowers.\n\nThe 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).\n\nOf course, the same course of thought is what lead to onchain transaction bloat in the first place.\n\nSplicing 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).\n\nRegards,\nZmnSCPxj\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181012/ad5e2132/attachment.html\u003e"}