> On Apr 20, 2021, at 17:19, Rusty Russell <ru...@rustcorp.com.au> wrote: > > After consideration, I prefer alternation. It fits better with the > existing implementations, and it is more optimal than reflection for > optimized implementations. > > In particular, you have a rule that says you can send updates and > commitment_signed when it's not your turn, and the leader either > responds with a "giving way" message, or ignores your changes and sends > its own. > > A simple implementation *never* sends a commitment_signed until it > receives "giving way" so it doesn't have to deal with orphaned > commitments. A more complex implementation sends opportunistically and > then has to remember that it's committed if it loses the race. Such an > implementation is only slower than the current system if that race > happens.
Somehow I missed this thread, but I did note in a previous meeting - these issues are great fodder for fuzzing. We’ve had a fuzzer which aggressively tests for precisely these types of message-non-delivery-and-resending production desync bugs for several years. When it initially landed it forced several rewrites of parts of the state machine, but quickly exhausted the bug fruit (though catches other classes of bugs occasionally as well). The state machine here is really not that big - while I agree simplifying it where possible is nice, ripping things out to replace them with fresh code (which would need similar testing) is probably not the most obvious decrease in complexity. > I've been revisiting this because it makes things like splicing easier: > the current draft requires stopping changes while splicing is being > negotiated, which is not entirely trivial. With the simplified method, > you don't have to wait at all. Hmm, what’s nontrivial about this? How much more complicated is this than having an alternation to updates and pausing HTLC updates for a cycle or two while splicing is negotiated (I assume it would still need a similar requirement, as otherwise you have the same complexity)? We already have a similar update-stopping process for shutdown, though of course it doesn’t include restarting. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
