[Lightning-dev] A state machine.

Rusty Russell rusty at rustcorp.com.au
Fri Sep 4 05:35:37 UTC 2015

Jasper Hugunin <jasper at hashplex.com> 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.


More information about the Lightning-dev mailing list