Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-02 📝 Original message: Anthony Towns <aj at ...

📅 Original date posted:2015-09-02
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On 1 September 2015 at 17:32, Rusty Russell <rusty at rustcorp.com.au> wrote:
>
>> Looking at that git tree (I've done some work since then)...
>
> ​Oh, github hasn't been updated since Aug 20? That's forever ago!​
>
>
>> Ah, you
>> can't send a command while processing an existing command. Seems a
>> logical simplification.
>>
>
> I'm thinking of CMD_CLOSE like "Ctrl-C"; why wouldn't you want it to work
> anytime?​

Yes, I think you do. And the other side can CMD_CLOSE during an HTLC
negotiation (for example), so this should be allowed.

I will update it to allow CMD_CLOSE at any time (except when already
closing).

>> >> This makes the constraints clearer, eg. you can't DECLINE_HTLC anything
>> >> but an ADD_HTLC.
>> > ​Your states currently allow declining those though:
>> Not at all (or if it does, it's a bug).
>
> ​Right, it's a bug as of ​52cda01 then :)

Weird, my tester should have found that (every tested-for input must be
given).

Ah, yes, it did, once I enhanced the tester to actually track htlcs.
And I've fixed it :)

(Those should be going to STATE_WAIT_FOR_UPDATE_ACCEPT).

>> The simplest (and safest) system is always to error and close when they
>> break protocol. There's some game theory involved in whether you should
>> wait or not, but in the end, they're broken and there's not much you can
>> do.
>>
>
> ​Well, you can ignore some errors -- time sync problems might resolve
> themselves, eg. And the "error" might be because of an error on your side
> (your admin ran the wrong date command, there's a bug in your code), that
> might well be fixable. I guess what I'm thinking is that closing a channel
> is a real cost; if they're not actively cheating -- by not completing an
> HTLC update once they agree to it eg -- I'd probably rather it stay open
> (in degraded mode perhaps) than automatically close.

We could add such things later, but it's really hard to know in advance
what bugs will lose money and which can be ignored.

>> I also wonder if
>> > A: TIMEDOUT_HTLC -> B: DECLINE (err_time_sync_lost)
>> > might be useful.
>> I don't think it's useful, though if you disagree on time you might get
>> an error packet. (What else can you do?)
>>
>
> ​How is "an error packet" different to a decline packet or a channel close?​

It carries an ascii message giving you a clue :)

> Perhaps we should add a current time field to UPDATE_ADD_HTLC so you can
>> defuse clock sync problems earlier?
>>
>
> Or maybe time sync is part of the p2p protocol?​ I guess channel
> counterparties are always peers?

Yes, that makes sense.

>> ​Sorry, I was assuming that one or both implementations were buggy. I
>> meant
>> > to make that explicit.​ You're talking with strangers on the network, so
>> > you can't assume their software is bug free, right?
>> That applies to any scheme you come up with, though. Propose something
>> simpler, and I'll gladly rewrite.
> ​
> ​I'll have another look when I can see current code :)​

NW, just running the now-glacial state tester. I'm sure there's only 1
bug left!

Cheers,
Rusty.