From rusty at rustcorp.com.au Tue May 4 05:03:35 2021 From: rusty at rustcorp.com.au (Rusty Russell) Date: Tue, 04 May 2021 14:33:35 +0930 Subject: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation In-Reply-To: <2da1a5de-40e7-2cda-c914-0632db1dff34@mattcorallo.com> References: <87zgxocjkk.fsf@rustcorp.com.au> <87mttkco8p.fsf@rustcorp.com.au> <2da1a5de-40e7-2cda-c914-0632db1dff34@mattcorallo.com> Message-ID: <87y2cv6qfs.fsf@rustcorp.com.au> Matt Corallo writes: > On 4/27/21 01:04, Rusty Russell wrote: >> Matt Corallo writes: >>>> On Apr 24, 2021, at 01:56, Rusty Russell wrote: >>>> >>>> ?Matt Corallo 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.