From rusty at rustcorp.com.au Wed Sep 30 01:41:09 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Wed, 30 Sep 2015 11:11:09 +0930 Subject: [Lightning-dev] Minor protocol revisions. In-Reply-To: <20150929064740.GA9432@navy> References: <87r3lo2wsi.fsf@rustcorp.com.au> <20150929064740.GA9432@navy> Message-ID: <877fn8hefe.fsf@rustcorp.com.au> Anthony Towns writes: > On Thu, Sep 24, 2015 at 12:25:11PM +0200, Pierre wrote: >> > 1) Close now has an second ACK stage, which means you know the close ack >> Argh, I already have trouble understanding the rationale behind all >> the existing closing flows and states :-s Would it be possible to >> publish an updated version of the svg ? aj, any chance you could do >> the same with your 'flat' version ? > > Yeah. I've updated state.py so the following flow works: > > $ test/test_state_coverage --dump-states | tee STATES > $ ./state.py > update.dot > $ dot -Tsvg update.dot > update.svg > > state.py is at https://github.com/ajtowns/lightning/blob/state/state.py > > Updated svg is viewable at > > http://azure.erisian.com.au/~aj/tmp/lightstate/simplified-states-20150929.svg > > Note that some transitions are still missing, notably > PKT_UPDATE_DECLINE_HTLC. > > (I'm not following why the state coverage testing doesn't do something > more like: > > states = [] > path_to_state = {} > for s in init_states: > path_to_states[s] = [s] > states.append(s) > > i = 0 > while i < len(states): > tst_state = states[i] > p = path_to_states[tst_state] > > for in_pkt in all_packets: > # enter test state > simulation_init(p[0]) > for setup_pkt in p[1:]: > simulation_send_pkt(setup_pkt) > > # send packet > new_state, response_pkt = simulation_send_pkt(in_pkt) > > # document result > dump_transition(tst_state, in_pkt, new_state, response_pkt) > > # if new state, add it to list to test > if new_state not in states: > path_to_state[new_state] = p + [in_pkt] > states.append(new_state) > > ie, for every state, throw every packet at it and record what happens; > assuming that any given state behaves the same no matter how you get > into it) Sure, but that's not even close to exhaustive testing (drawing diagrams was just a side-effect for me). Unfortunately the state doesn't quite encapsulate everything. For example, it captures whether you have HTLCs or not, but not whether you have more than one. You also want to simulate a pair, and make sure you cover all combinations of states between the two. You also need to take into account what non-packet events are possible (eg. timeouts, bitcoin watch events). Finally, you want to inject errors. Anyway, the final result (requiring about 14.5GB of memory to run, though it should be fairly swap-friendly) has now been pushed. Cheers, Rusty.