đź“… 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>;
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-09 12:44:19
in reply to nevent1q…rre0
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-09 12:44:19Event JSON
{
"id": "aeaa5b4a67ae1fd356d543032f49ae144a650de5f307e618b7db26b708977479",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686314659,
"kind": 1,
"tags": [
[
"e",
"7cb446ab5c4fbaa2742daa23601e2632ee497d75e0b39629952a69f13b297936",
"",
"root"
],
[
"e",
"8cdd82fb9e9247eb304f8ea8cca00a79f4f1eb63aae9f71ad27e4bb5e84a9f18",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-09-01\n📝 Original message:\nOn 1 September 2015 at 17:32, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\n\u003e Looking at that git tree (I've done some work since then)...\n\n\n​Oh, github hasn't been updated since Aug 20? That's forever ago!​\n\n\n\u003e Ah, you\n\u003e can't send a command while processing an existing command. Seems a\n\u003e logical simplification.\n\u003e\n\nI'm thinking of CMD_CLOSE like \"Ctrl-C\"; why wouldn't you want it to work\nanytime?​\n\n\n\u003e \u003e\u003e This makes the constraints clearer, eg. you can't DECLINE_HTLC anything\n\u003e \u003e\u003e but an ADD_HTLC.\n\u003e \u003e ​Your states currently allow declining those though:\n\u003e Not at all (or if it does, it's a bug).\n\n\n​Right, it's a bug as of ​52cda01 then :)\n\n​​\n\u003e The simplest (and safest) system is always to error and close when they\n\u003e break protocol. There's some game theory involved in whether you should\n\u003e wait or not, but in the end, they're broken and there's not much you can\n\u003e do.\n\u003e\n\n​Well, you can ignore some errors -- time sync problems might resolve\nthemselves, eg. And the \"error\" might be because of an error on your side\n(your admin ran the wrong date command, there's a bug in your code), that\nmight well be fixable. I guess what I'm thinking is that closing a channel\nis a real cost; if they're not actively cheating -- by not completing an\nHTLC update once they agree to it eg -- I'd probably rather it stay open\n(in degraded mode perhaps) than automatically close.\n\n\u003e I also wonder if\n\u003e \u003e A: TIMEDOUT_HTLC -\u003e B: DECLINE (err_time_sync_lost)\n\u003e \u003e might be useful.\n\u003e I don't think it's useful, though if you disagree on time you might get\n\u003e an error packet. (What else can you do?)\n\u003e\n\n​How is \"an error packet\" different to a decline packet or a channel close?​\n\nPerhaps we should add a current time field to UPDATE_ADD_HTLC so you can\n\u003e defuse clock sync problems earlier?\n\u003e\n\nOr maybe time sync is part of the p2p protocol?​ I guess channel\ncounterparties are always peers?\n\n\u003e ​Sorry, I was assuming that one or both implementations were buggy. I\n\u003e meant\n\u003e \u003e to make that explicit.​ You're talking with strangers on the network, so\n\u003e \u003e you can't assume their software is bug free, right?\n\u003e That applies to any scheme you come up with, though. Propose something\n\u003e simpler, and I'll gladly rewrite.\n\n​\n​\n​I'll have another look when I can see current code :)​\n​\n\n​Cheers,\naj​\n\n-- \nAnthony Towns \u003caj at erisian.com.au\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150902/447c3f60/attachment-0001.html\u003e",
"sig": "0e871a66ced052c193b248ca073daa7286e31e4f0b8b22710a0e32853128bc966375bb29209dffc2ffb75d43ef5f6f0f67d113ddedd27779b681a234b56c38ff"
}