[Lightning-dev] Minor protocol revisions.

Rusty Russell rusty at rustcorp.com.au
Wed Sep 30 04:16:24 UTC 2015

Anthony Towns <aj at erisian.com.au> writes:
> On Wed, Sep 30, 2015 at 11:11:09AM +0930, Rusty Russell wrote:
>> > (I'm not following why the state coverage testing doesn't do something
>> > more like: [...]
>> Sure, but that's not even close to exhaustive testing (drawing diagrams
>> was just a side-effect for me).
> Absolutely. But... I'm not seeing what the code actually /does/ with the
> exhaustive testing? There's a lot of asserts; but I'm not sure that's
> actually testing things "make sense" or just "don't crash". Maybe having
> some optional output of traces for successful test cases would make it
> more obvious?

More comments and more testing would be nice, but at some point I have
to stop writing tests :)

Tests are (with varying degrees of thoroughness):

1) State machine never gets into an invalid state.
2) State machine never sends a packet other side doesn't expect.
3) State machine terminates if not on main loop.
4) State machine does not deadlock (both sides waiting, none sending).
5) State machine cleans up.

> eg, (and I haven't tried pulling the code apart to really understand
> it or anything) I can't tell if you're testing agreeing on two HTLCs then
> having the first one time out, versus the second one time out first.
> Hmm:
>           report_trail(&t, "CLOSED with htlc in progress?");
> I figured that was expected and normal protocol behaviour? Not ideal,
> but if you're still communicating at all, if someone decides the channel
> has to be closed, it's still always better to do a mutual close to
> avoid the CSV delays and any unnecessarily elevated fees, even with
> outstanding HTLCs.

STATE_CLOSED here means "completely finished".

But also, we don't support mutual close with outstanding HTLCs.  We
could, but the protocol is complex enough already.


More information about the Lightning-dev mailing list