[Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation

Rusty Russell rusty at rustcorp.com.au
Tue May 4 05:03:35 UTC 2021

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

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!).


More information about the Lightning-dev mailing list