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

📅 Original date posted:2021-05-04
📝 Original message:
Matt Corallo <lf-lists at mattcorallo.com> writes:
> On 4/27/21 01:04, Rusty Russell wrote:
>> Matt Corallo <lf-lists at mattcorallo.com> writes:
>>>> On Apr 24, 2021, at 01:56, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>>>
>>>> Matt Corallo <lf-lists at mattcorallo.com> writes:
>>> I promise it’s much less work than it sounds like, and avoids having to debug these things based on logs, which is a huge pain :). Definitely less work than a new state machine:).
>>
>> But the entire point of this proposal is that it's a subset of the
>> existing state machine?
>
> Compared to today, its a good chunk of additional state machine logic to enforce when a message can or can not be sent,
> and additional logic for when we can (or can not) flush any pending
> changes buffer(s)

Kind of. I mean, we can add a "update_noop" message which simply
requests your turn and has no other effects.

>> The only "twist" is that if it's your turn and you receive an update,
>> you can either reply with a "yield" message, or ignore it.
>
> How do you handle the "no changes to make" case - do you send yields back and forth ever Nms all day long or is there
> some protocol by which you resolve it when both parties try to claim turn at once?

You don't do anything?

If you want to send an update:
1. If it is your turn, send it.
2. If it is not your turn, send it and wait for either a `yield`, or a
different update. In the former case, it's now your turn, in the
latter case it's not and your update was ignored.

If you receive an update when it's your turn:
1. If you've sent an update already, ignore it.
2. Otherwise, send `yield`.

>>> Isn’t that pretty similar? Discard one splice proposal deterministically (ok that’s new) and the loser has to store their proposal in a holding cell for later (which they have to do in turn-based anyway). Logic to check if there’s unsettled things in RAA handling is pretty similar to turn-based, and logic to reject other messages is the same as shutdown handling today.
>>
>> Nope, with the simplified protocol you can `update_splice` at any time
>> instead of your normal update, since both sides are already in sync.
>
> Hmm, I'm somewhat failing to understand why its that different - you can only update_splice if its your turn, which is
> about exactly the same amount of additional logic to check turn conditions as just flag "want to do splice". Either way
> you have the same pending splice buffer.

No, for turn-taking, this case is exactly like any other update.

For non-turn taking, we need an explicit quiescence protocol, and to
handle simultanous splicing.

>>>> - MUST use the higher of the two `funding_feerate_perkw` as the feerate for
>>>> the splice.
>>>
>>> If we like turn based, why not just deterministic throw out one slice? :)
>>
>> Because while I am going to implement turn-based, I'm not sure if anyone
>> else is. I guess we'll see?
>
> My point was more that its similar in logic - if you throw out the splice deterministically and just keep it in some
> "pending slice" buffer on the sending side, you've just done basically what you'd do to implement turns, while keeping
> the non-turn slice protocol a bit easier :).

No, you really haven't. Right now you can have Alice propose a splice
while Bob proposes at the same time, so we have a tiebreak protocol.
And you can have Alice propose a splice while Bob proposes a different
update which needs to be completely resolved before the splice can
continue.

Whereas in turn taking, when someone proposes a splice, that's what
you're doing, as soon as it is received. And when someone wants to
propose a splice, they can do it as soon as it's their turn. If it's
not their turn and the other side proposes a splice, they can jump onto
that (happy days, since the splice proposer pays for 1 input 1 output
and the core of the tx!).

Cheers,
Rusty.