📅 Original date posted:2016-02-03
📝 Original message:
On Wed, Feb 03, 2016 at 03:05:33PM +1030, Rusty Russell wrote:
> Right, so "this signature covers you up to X me up to Y". That resolves
> the in-flight issue.
>
> But isn't that more a request ID rather than an HTLC ID? Since requests
> can include removing HTLCs as well? And doesn't that simply degrade to
> a counter?
Yeah, it's more like a request "staging" ID. The "counter" aspect
requires two counters (one for each originator of the request). Two IDs
sent in the commitment message allow for simultaneous action on
accept/reject/etc, whereas only one would require a lock on
accepting/rejecting modifications.
Minor note which has the potential to be overlooked: It's a hard
requirement that all messages sent are in order, and if the replyer
skips the requester's Add Requests when replying, the skipped are
assumed to be request rejections (or an outright channel closeout) since
it should never happen -- this is to enforce accept/reject order, as we
need to know which modifications are included in the
signature/transaction and not have that change after-the-fact.
--
Joseph Poon
Joseph Poon [ARCHIVE] /
npub1ej…p9cq8
2023-06-09 12:45:41
in reply to nevent1q…9pys
Author Public Key
npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8Published at
2023-06-09 12:45:41Event JSON
{
"id": "319f6dffcd2e65abc792ebf60318159b84533752309eee21dc8bee869e3d6caa",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686314741,
"kind": 1,
"tags": [
[
"e",
"18682649fe79f5a2c54629ca1e6d86742074bd7eba6c99aba4f0188eb011b6a3",
"",
"root"
],
[
"e",
"15ea3287f056764d89dbb0906fc31adb0c57c84566756ec87fddeeee8ddfd3c0",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2016-02-03\n📝 Original message:\nOn Wed, Feb 03, 2016 at 03:05:33PM +1030, Rusty Russell wrote:\n\u003e Right, so \"this signature covers you up to X me up to Y\". That resolves\n\u003e the in-flight issue.\n\u003e \n\u003e But isn't that more a request ID rather than an HTLC ID? Since requests\n\u003e can include removing HTLCs as well? And doesn't that simply degrade to\n\u003e a counter?\n\nYeah, it's more like a request \"staging\" ID. The \"counter\" aspect\nrequires two counters (one for each originator of the request). Two IDs\nsent in the commitment message allow for simultaneous action on\naccept/reject/etc, whereas only one would require a lock on\naccepting/rejecting modifications.\n\nMinor note which has the potential to be overlooked: It's a hard\nrequirement that all messages sent are in order, and if the replyer\nskips the requester's Add Requests when replying, the skipped are\nassumed to be request rejections (or an outright channel closeout) since\nit should never happen -- this is to enforce accept/reject order, as we\nneed to know which modifications are included in the\nsignature/transaction and not have that change after-the-fact.\n\n-- \nJoseph Poon",
"sig": "903e7206286bf8d50694fc3cf471788d4bdc62d9ae11d7dbd4641de16c2e8a5ccf1663565d6895bb5ccd3c9d3004a1633ed4162415ab87f94c22e274c09850fb"
}