[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.

Cheers,
Rusty.


More information about the Lightning-dev mailing list