Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-24 📝 Original message: Matt Corallo <lf-lists at ...

📅 Original date posted:2021-04-24
📝 Original message:
Matt Corallo <lf-lists at 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.