đź“… Original date posted:2021-04-24
đź“ť Original message:
> On Apr 20, 2021, at 17:19, Rusty Russell <rusty at 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.
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-09 15:02:18
in reply to nevent1q…tw7m
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuPublished at
2023-06-09 15:02:18Event JSON
{
"id": "4d7901f8835bcd2517ef3c6beac21046415e514527aaaa0413e0f1d765d518b1",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686315738,
"kind": 1,
"tags": [
[
"e",
"5553893599fc04c98be25342f54aa462a3c042c383d72c4c91ba0e2e16004f4c",
"",
"root"
],
[
"e",
"2c0e00d0129db8e488e3948a126df3af8527e78b520aaf469de8e5a534523c31",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2021-04-24\n📝 Original message:\n\u003e On Apr 20, 2021, at 17:19, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\u003e \n\u003e After consideration, I prefer alternation. It fits better with the\n\u003e existing implementations, and it is more optimal than reflection for\n\u003e optimized implementations.\n\u003e \n\u003e In particular, you have a rule that says you can send updates and\n\u003e commitment_signed when it's not your turn, and the leader either\n\u003e responds with a \"giving way\" message, or ignores your changes and sends\n\u003e its own.\n\u003e \n\u003e A simple implementation *never* sends a commitment_signed until it\n\u003e receives \"giving way\" so it doesn't have to deal with orphaned\n\u003e commitments. A more complex implementation sends opportunistically and\n\u003e then has to remember that it's committed if it loses the race. Such an\n\u003e implementation is only slower than the current system if that race\n\u003e happens.\n\nSomehow 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.\n\n\u003e I've been revisiting this because it makes things like splicing easier:\n\u003e the current draft requires stopping changes while splicing is being\n\u003e negotiated, which is not entirely trivial. With the simplified method,\n\u003e you don't have to wait at all.\n\nHmm, 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.",
"sig": "7d967020c91b911c913c7dc81fae9b31019497c64e54c215dc862201df374f948558bb32bfd757e132b1b178ade87578502adbba8cd502e9b65a1ceeac6c39de"
}