From jasper at hashplex.com Wed Sep 2 19:36:44 2015 From: jasper at hashplex.com (Jasper Hugunin) Date: Wed, 2 Sep 2015 12:36:44 -0700 Subject: [Lightning-dev] A state machine. In-Reply-To: <87twrd1i1r.fsf@rustcorp.com.au> References: <87si7eiehg.fsf@rustcorp.com.au> <87h9ntifwf.fsf@rustcorp.com.au> <877fopi4un.fsf@rustcorp.com.au> <20150829074239.GA15643@navy> <874mjgqne2.fsf@rustcorp.com.au> <87si6ybnmm.fsf@rustcorp.com.au> <87twrd1i1r.fsf@rustcorp.com.au> Message-ID: 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 wrote: > Anthony Towns writes: > > On 1 September 2015 at 17:32, Rusty Russell > 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: