Matt Corallo [ARCHIVE] on Nostr: đź“… Original date posted:2021-04-27 đź“ť Original message: On 4/27/21 01:04, Rusty ...
đź“… Original date posted:2021-04-27
đź“ť Original message:
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).
> 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?
>> 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.
>>> - 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 :).
Matt
đź“ť Original message:
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).
> 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?
>> 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.
>>> - 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 :).
Matt