From rusty at rustcorp.com.au Wed Sep 2 05:55:44 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 02 Sep 2015 15:25:44 +0930 Subject: [Lightning-dev] A state machine. In-Reply-To: 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> Message-ID: <87twrd1i1r.fsf@rustcorp.com.au> 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.