[Lightning-dev] Minor protocol revisions.

Anthony Towns aj at erisian.com.au
Wed Sep 30 04:07:59 UTC 2015


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?

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.

That would mean CLOSE should start tracking HTLCs (and spending when
timeouts hit or R's become known) just like when a commitment is
published; so I guess that's CLOSE_WAIT_HTLCs?

Cheers,
aj


More information about the Lightning-dev mailing list