From aj at erisian.com.au Wed Sep 30 04:07:59 2015 From: aj at erisian.com.au (Anthony Towns) Date: Wed, 30 Sep 2015 14:07:59 +1000 Subject: [Lightning-dev] Minor protocol revisions. In-Reply-To: <877fn8hefe.fsf@rustcorp.com.au> References: <87r3lo2wsi.fsf@rustcorp.com.au> <20150929064740.GA9432@navy> <877fn8hefe.fsf@rustcorp.com.au> Message-ID: <20150930040759.GA2130@navy> 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