From rusty at rustcorp.com.au Fri Sep 4 05:35:37 2015 From: rusty at rustcorp.com.au (Rusty Russell) Date: Fri, 04 Sep 2015 15:05:37 +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> <87twrd1i1r.fsf@rustcorp.com.au> Message-ID: <87fv2un3va.fsf@rustcorp.com.au> Jasper Hugunin writes: > 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. We could, but it makes things more complex. We might eventually want to batch updates for performance (which we certainly can do), which would also solve this problem. The duplicated state is really an artifact of the artificial and exhaustive way I coded state.c. I did that because I wanted as much state to be expressed in the "enum state" for simpler testing. In practice, it's a one-liner. Cheers, Rusty.