Anthony Towns [ARCHIVE] on Nostr: đź“… Original date posted:2015-09-01 đź“ť Original message: On 1 September 2015 at ...
đź“… Original date posted:2015-09-01
đź“ť Original message:
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?​
> >> 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 :)
​​
> 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.
> 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?​
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?
> ​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 :)​
​
​Cheers,
aj​
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150902/447c3f60/attachment-0001.html>;
đź“ť Original message:
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?​
> >> 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 :)
​​
> 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.
> 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?​
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?
> ​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 :)​
​
​Cheers,
aj​
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150902/447c3f60/attachment-0001.html>;