đź“… Original date posted:2015-09-02
đź“ť Original message:
I had an idea regarding an alternative to the high/low priority. My
understanding is that the problem is this case:
Alice sends PKT_UPDATE and transitions to WAIT_FOR_UPDATE_ACCEPT.
Bob sends PKT_UPDATE, and also transitions to WAIT_FOR_UPDATE_ACCEPT.
Then Bob receives Alice's PKT_UPDATE. Since he is waiting for his own
update, he doesn't know which *single* update is the official one. Same for
Alice.
What if Bob and Alice agree on a new update that combines both updates. The
protocol can only handle one update at a time, but the update doesn't have
to happen one-way.
This would be similar to TCP Simultaneous Open/Close.
So Alice and Bob would exchange PKT_SIMULTANEOUS_ACCEPT containing
signatures, and then exchange PKT_SIMULTANEOUS_COMPLETE containing revoking
pre-images.
Continuing my example above, Bob would receive PKT_UPDATE, send
PKT_SIMULTANEOUS_ACCEPT and transition to WAIT_FOR_SIMULTANEOUS_ACCEPT.
Alice would receive Bob's PKT_UPDATE, send PKT_SIMULTANEOUS_ACCEPT and
transition to WAIT_FOR_SIMULTANEOUS_ACCEPT.
Bob would recieve Alice's PKT_SIMULTANEOUS_ACCEPT, send
PKT_SIMULTANEOUS_COMPLETE, and transition to NORMAL.
Same for Alice.
I think that avoids either deadlock or livelock, and does not require
duplicating states for priority.
- Jasper
On Tue, Sep 1, 2015 at 10:55 PM, Rusty Russell <rusty at rustcorp.com.au>
wrote:
> 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.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150902/e41ada10/attachment.html>;
Jasper Hugunin [ARCHIVE] /
npub134…sek9k
2023-06-09 12:44:20
in reply to nevent1q…reck
Author Public Key
npub134ll68t2ukngtmn23v2zam3d5c7gj0jqzkqhte8h2pxv25lgr8eqgsek9kSeen on
wss://relay.nostr.bandPublished at
2023-06-09 12:44:20Event JSON
{
"id": "caa28a0b7123f6755a0aaab8b0c682cd8e9474b735d2ebfefb4d3bfde735589c",
"pubkey": "8d7ffd1d6ae5a685ee6a8b142eee2da63c893e40158175e4f7504cc553e819f2",
"created_at": 1686314660,
"kind": 1,
"tags": [
[
"e",
"7cb446ab5c4fbaa2742daa23601e2632ee497d75e0b39629952a69f13b297936",
"",
"root"
],
[
"e",
"a818499876ed291610509981bce9f42344ee1cb5670870d9bab500ff16b379db",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-09-02\n📝 Original message:\nI had an idea regarding an alternative to the high/low priority. My\nunderstanding is that the problem is this case:\nAlice sends PKT_UPDATE and transitions to WAIT_FOR_UPDATE_ACCEPT.\nBob sends PKT_UPDATE, and also transitions to WAIT_FOR_UPDATE_ACCEPT.\nThen Bob receives Alice's PKT_UPDATE. Since he is waiting for his own\nupdate, he doesn't know which *single* update is the official one. Same for\nAlice.\n\nWhat if Bob and Alice agree on a new update that combines both updates. The\nprotocol can only handle one update at a time, but the update doesn't have\nto happen one-way.\nThis would be similar to TCP Simultaneous Open/Close.\nSo Alice and Bob would exchange PKT_SIMULTANEOUS_ACCEPT containing\nsignatures, and then exchange PKT_SIMULTANEOUS_COMPLETE containing revoking\npre-images.\nContinuing my example above, Bob would receive PKT_UPDATE, send\nPKT_SIMULTANEOUS_ACCEPT and transition to WAIT_FOR_SIMULTANEOUS_ACCEPT.\nAlice would receive Bob's PKT_UPDATE, send PKT_SIMULTANEOUS_ACCEPT and\ntransition to WAIT_FOR_SIMULTANEOUS_ACCEPT.\nBob would recieve Alice's PKT_SIMULTANEOUS_ACCEPT, send\nPKT_SIMULTANEOUS_COMPLETE, and transition to NORMAL.\nSame for Alice.\n\nI think that avoids either deadlock or livelock, and does not require\nduplicating states for priority.\n\n- Jasper\n\nOn Tue, Sep 1, 2015 at 10:55 PM, Rusty Russell \u003crusty at rustcorp.com.au\u003e\nwrote:\n\n\u003e Anthony Towns \u003caj at erisian.com.au\u003e writes:\n\u003e \u003e On 1 September 2015 at 17:32, Rusty Russell \u003crusty at rustcorp.com.au\u003e\n\u003e wrote:\n\u003e \u003e\n\u003e \u003e\u003e Looking at that git tree (I've done some work since then)...\n\u003e \u003e\n\u003e \u003e ​Oh, github hasn't been updated since Aug 20? That's forever ago!​\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\u003e Ah, you\n\u003e \u003e\u003e can't send a command while processing an existing command. Seems a\n\u003e \u003e\u003e logical simplification.\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003e I'm thinking of CMD_CLOSE like \"Ctrl-C\"; why wouldn't you want it to work\n\u003e \u003e anytime?​\n\u003e\n\u003e Yes, I think you do. And the other side can CMD_CLOSE during an HTLC\n\u003e negotiation (for example), so this should be allowed.\n\u003e\n\u003e I will update it to allow CMD_CLOSE at any time (except when already\n\u003e closing).\n\u003e\n\u003e \u003e\u003e \u003e\u003e This makes the constraints clearer, eg. you can't DECLINE_HTLC\n\u003e anything\n\u003e \u003e\u003e \u003e\u003e but an ADD_HTLC.\n\u003e \u003e\u003e \u003e ​Your states currently allow declining those though:\n\u003e \u003e\u003e Not at all (or if it does, it's a bug).\n\u003e \u003e\n\u003e \u003e ​Right, it's a bug as of ​52cda01 then :)\n\u003e\n\u003e Weird, my tester should have found that (every tested-for input must be\n\u003e given).\n\u003e\n\u003e Ah, yes, it did, once I enhanced the tester to actually track htlcs.\n\u003e And I've fixed it :)\n\u003e\n\u003e (Those should be going to STATE_WAIT_FOR_UPDATE_ACCEPT).\n\u003e\n\u003e \u003e\u003e The simplest (and safest) system is always to error and close when they\n\u003e \u003e\u003e break protocol. There's some game theory involved in whether you should\n\u003e \u003e\u003e wait or not, but in the end, they're broken and there's not much you can\n\u003e \u003e\u003e do.\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003e ​Well, you can ignore some errors -- time sync problems might resolve\n\u003e \u003e themselves, eg. And the \"error\" might be because of an error on your side\n\u003e \u003e (your admin ran the wrong date command, there's a bug in your code), that\n\u003e \u003e might well be fixable. I guess what I'm thinking is that closing a\n\u003e channel\n\u003e \u003e is a real cost; if they're not actively cheating -- by not completing an\n\u003e \u003e HTLC update once they agree to it eg -- I'd probably rather it stay open\n\u003e \u003e (in degraded mode perhaps) than automatically close.\n\u003e\n\u003e We could add such things later, but it's really hard to know in advance\n\u003e what bugs will lose money and which can be ignored.\n\u003e\n\u003e \u003e\u003e I also wonder if\n\u003e \u003e\u003e \u003e A: TIMEDOUT_HTLC -\u003e B: DECLINE (err_time_sync_lost)\n\u003e \u003e\u003e \u003e might be useful.\n\u003e \u003e\u003e I don't think it's useful, though if you disagree on time you might get\n\u003e \u003e\u003e an error packet. (What else can you do?)\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003e ​How is \"an error packet\" different to a decline packet or a channel\n\u003e close?​\n\u003e\n\u003e It carries an ascii message giving you a clue :)\n\u003e\n\u003e \u003e Perhaps we should add a current time field to UPDATE_ADD_HTLC so you can\n\u003e \u003e\u003e defuse clock sync problems earlier?\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003e Or maybe time sync is part of the p2p protocol?​ I guess channel\n\u003e \u003e counterparties are always peers?\n\u003e\n\u003e Yes, that makes sense.\n\u003e\n\u003e \u003e\u003e ​Sorry, I was assuming that one or both implementations were buggy. I\n\u003e \u003e\u003e meant\n\u003e \u003e\u003e \u003e to make that explicit.​ You're talking with strangers on the network,\n\u003e so\n\u003e \u003e\u003e \u003e you can't assume their software is bug free, right?\n\u003e \u003e\u003e That applies to any scheme you come up with, though. Propose something\n\u003e \u003e\u003e simpler, and I'll gladly rewrite.\n\u003e \u003e ​\n\u003e \u003e ​I'll have another look when I can see current code :)​\n\u003e\n\u003e NW, just running the now-glacial state tester. I'm sure there's only 1\n\u003e bug left!\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150902/e41ada10/attachment.html\u003e",
"sig": "d3e253b7179192f56151a7968cbdbf8a420dcbff6f11c78fe51d70032a75ac723bf5578c25ee14b0350bc079c6f9396b850635044261ac5bb55e2b4e9d49872b"
}