[Lightning-dev] A state machine.

Jasper Hugunin jasper at hashplex.com
Wed Sep 2 19:36:44 UTC 2015


I had an idea regarding an alternative to the high/low priority. My
understanding is that the problem is this case:
Alice sends PKT_UPDATE and transitions to WAIT_FOR_UPDATE_ACCEPT.
Bob sends PKT_UPDATE, and also transitions to WAIT_FOR_UPDATE_ACCEPT.
Then Bob receives Alice's PKT_UPDATE. Since he is waiting for his own
update, he doesn't know which *single* update is the official one. Same for
Alice.

What if Bob and Alice agree on a new update that combines both updates. The
protocol can only handle one update at a time, but the update doesn't have
to happen one-way.
This would be similar to TCP Simultaneous Open/Close.
So Alice and Bob would exchange PKT_SIMULTANEOUS_ACCEPT containing
signatures, and then exchange PKT_SIMULTANEOUS_COMPLETE containing revoking
pre-images.
Continuing my example above, Bob would receive PKT_UPDATE, send
PKT_SIMULTANEOUS_ACCEPT and transition to WAIT_FOR_SIMULTANEOUS_ACCEPT.
Alice would receive Bob's PKT_UPDATE, send PKT_SIMULTANEOUS_ACCEPT and
transition to WAIT_FOR_SIMULTANEOUS_ACCEPT.
Bob would recieve Alice's PKT_SIMULTANEOUS_ACCEPT, send
PKT_SIMULTANEOUS_COMPLETE, and transition to NORMAL.
Same for Alice.

I think that avoids either deadlock or livelock, and does not require
duplicating states for priority.

- Jasper

On Tue, Sep 1, 2015 at 10:55 PM, Rusty Russell <rusty at rustcorp.com.au>
wrote:

> Anthony Towns <aj at erisian.com.au> writes:
> > On 1 September 2015 at 17:32, Rusty Russell <rusty at rustcorp.com.au>
> wrote:
> >
> >> Looking at that git tree (I've done some work since then)...
> >
> > ​Oh, github hasn't been updated since Aug 20? That's forever ago!​
> >
> >
> >> Ah, you
> >> can't send a command while processing an existing command.  Seems a
> >> logical simplification.
> >>
> >
> > I'm thinking of CMD_CLOSE like "Ctrl-C"; why wouldn't you want it to work
> > anytime?​
>
> Yes, I think you do.  And the other side can CMD_CLOSE during an HTLC
> negotiation (for example), so this should be allowed.
>
> I will update it to allow CMD_CLOSE at any time (except when already
> closing).
>
> >> >> This makes the constraints clearer, eg. you can't DECLINE_HTLC
> anything
> >> >> but an ADD_HTLC.
> >> > ​Your states currently allow declining those though:
> >> Not at all (or if it does, it's a bug).
> >
> > ​Right, it's a bug as of ​52cda01 then :)
>
> Weird, my tester should have found that (every tested-for input must be
> given).
>
> Ah, yes, it did, once I enhanced the tester to actually track htlcs.
> And I've fixed it :)
>
> (Those should be going to STATE_WAIT_FOR_UPDATE_ACCEPT).
>
> >> The simplest (and safest) system is always to error and close when they
> >> break protocol.  There's some game theory involved in whether you should
> >> wait or not, but in the end, they're broken and there's not much you can
> >> do.
> >>
> >
> > ​Well, you can ignore some errors -- time sync problems might resolve
> > themselves, eg. And the "error" might be because of an error on your side
> > (your admin ran the wrong date command, there's a bug in your code), that
> > might well be fixable. I guess what I'm thinking is that closing a
> channel
> > is a real cost; if they're not actively cheating -- by not completing an
> > HTLC update once they agree to it eg -- I'd probably rather it stay open
> > (in degraded mode perhaps) than automatically close.
>
> We could add such things later, but it's really hard to know in advance
> what bugs will lose money and which can be ignored.
>
> >> I also wonder if
> >> >   A: TIMEDOUT_HTLC -> B: DECLINE (err_time_sync_lost)
> >> > might be useful.
> >> I don't think it's useful, though if you disagree on time you might get
> >> an error packet.  (What else can you do?)
> >>
> >
> > ​How is "an error packet" different to a decline packet or a channel
> close?​
>
> It carries an ascii message giving you a clue :)
>
> > Perhaps we should add a current time field to UPDATE_ADD_HTLC so you can
> >> defuse clock sync problems earlier?
> >>
> >
> > Or maybe time sync is part of the p2p protocol?​ I guess channel
> > counterparties are always peers?
>
> Yes, that makes sense.
>
> >> ​Sorry, I was assuming that one or both implementations were buggy. I
> >> meant
> >> > to make that explicit.​ You're talking with strangers on the network,
> so
> >> > you can't assume their software is bug free, right?
> >> That applies to any scheme you come up with, though.  Propose something
> >> simpler, and I'll gladly rewrite.
> > ​
> > ​I'll have another look when I can see current code :)​
>
> NW, just running the now-glacial state tester.  I'm sure there's only 1
> bug left!
>
> Cheers,
> Rusty.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150902/e41ada10/attachment.html>


More information about the Lightning-dev mailing list