Matt Corallo <lf-li...@mattcorallo.com> writes: > 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.
It's historically had more bugs than anything else in the protocol. We literally found another one in feerate negotiation since the last c-lightning release :( I'd rather not have bugs than try to catch them all. >> 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. You could propose a splice (or update to anchors, or whatever) any time when it's your turn, as long as you haven't proposed any other updates. That's simple! Instead, *both* sides have to send a splice message to synchronize, and they can only do so once all in-flight changes have cleared. You have to resolve simultaneous splice attempts (we use "highest feerate" tiebreak by node_id), and keep track of this stage while you clear in-flight changes. Here's the subset of requirements from the draft which relate to this: The sender: - MUST NOT send another splice message while a splice is being negotiated. - MUST NOT send a splice message after sending uncommitted changes. - MUST NOT send other channel updates until splice negotiation has completed. The receiver: - MUST respond with a `splice` message of its own if it has not already. - MUST NOT reply with `splice` until all commitment updates are resolved by both peers. - MUST use the higher of the two `funding_feerate_perkw` as the feerate for the splice. - MUST NOT send other channel updates until splice negotiation has completed. Similar requirements exist for other major channel changes. Cheers, Rusty. _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
