Matt Corallo <[email protected]> writes: > On 4/27/21 01:04, Rusty Russell wrote: >> Matt Corallo <[email protected]> writes: >>>> On Apr 24, 2021, at 01:56, Rusty Russell <[email protected]> wrote: >>>> >>>> Matt Corallo <[email protected]> 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. _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
