📅 Original date posted:2016-02-03
📝 Original message:
Joseph Poon <joseph at lightning.network> writes:
> Bob's broadcastable Commitment: Alice sends a Signature to Bob. Bob
> sends the Revocation of the previous Commitment to Alice.
>
> Alice's broadcastable Commitment: Bob sends a Signature to Alice. Alice
> sends to Revocation of the previous Commitment to Bob.
>
> It's that simple. If the HTLC is reflected in both and the previous
> commitment(s) is/are revoked, then it's complete.
Ah, I think I finally understand! I was artificially linking the two
sides' commit transactions, but there's really no reason to. As you
say, once you've included an HTLC in both sides in any form, it's
locked in.
>> If I receive "add request" "add request" "signed commit", how do I know
>> what that signatures covers?
>
> The protocol is still being optimized (deprecating the even/odd
> structure, etc.), but the structure is both parties have a list of HTLC
> modifications which they want to update. When the modification is
> acknowledged by the other party, the HTLC modifcation request is staged
> into the next Commitment signature. The inclusion of modifications are
> enumerated by including both parties' higest HTLC ID (two of them) in
> each Commitment signature message.
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?
>> Are you required to wait for my accept/reject message replies before
>> commiting? Or does the commit message include a counter?
>
> Any which is accepted by the other party is included. Two IDs, one for
> each party, is included. Two are necessary to allow for timing issues
> with HTLC Add responses in-flight not being fully synced up.
Right.
>> I guess "asynchronous" is a bit nebulous: out-of-order or in-order? I
>> couldn't see a good reason for out-of-order. Whereas letting both
>> sides offer updates in parallel makes good sense for throughput...
>
> In-order. I should have an update in the coming days for lnstate if that
> helps (various protocol updates, e.g. fixing exchanging of revocation
> hashes, etc.)
Thanks, I feel smarter now! :)
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:45:40
in reply to nevent1q…vv0j
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:45:40Event JSON
{
"id": "15ea3287f056764d89dbb0906fc31adb0c57c84566756ec87fddeeee8ddfd3c0",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314740,
"kind": 1,
"tags": [
[
"e",
"18682649fe79f5a2c54629ca1e6d86742074bd7eba6c99aba4f0188eb011b6a3",
"",
"root"
],
[
"e",
"6e59eaf23ec39cfe50c4ab8dda4e2f33ef1a96b259895714cc286da1fcac815c",
"",
"reply"
],
[
"p",
"ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211"
]
],
"content": "📅 Original date posted:2016-02-03\n📝 Original message:\nJoseph Poon \u003cjoseph at lightning.network\u003e writes:\n\u003e Bob's broadcastable Commitment: Alice sends a Signature to Bob. Bob\n\u003e sends the Revocation of the previous Commitment to Alice.\n\u003e\n\u003e Alice's broadcastable Commitment: Bob sends a Signature to Alice. Alice\n\u003e sends to Revocation of the previous Commitment to Bob.\n\u003e\n\u003e It's that simple. If the HTLC is reflected in both and the previous\n\u003e commitment(s) is/are revoked, then it's complete.\n\nAh, I think I finally understand! I was artificially linking the two\nsides' commit transactions, but there's really no reason to. As you\nsay, once you've included an HTLC in both sides in any form, it's\nlocked in.\n\n\u003e\u003e If I receive \"add request\" \"add request\" \"signed commit\", how do I know\n\u003e\u003e what that signatures covers? \n\u003e\n\u003e The protocol is still being optimized (deprecating the even/odd\n\u003e structure, etc.), but the structure is both parties have a list of HTLC\n\u003e modifications which they want to update. When the modification is\n\u003e acknowledged by the other party, the HTLC modifcation request is staged\n\u003e into the next Commitment signature. The inclusion of modifications are\n\u003e enumerated by including both parties' higest HTLC ID (two of them) in\n\u003e each Commitment signature message.\n\nRight, so \"this signature covers you up to X me up to Y\". That resolves\nthe in-flight issue.\n\nBut isn't that more a request ID rather than an HTLC ID? Since requests\ncan include removing HTLCs as well? And doesn't that simply degrade to\na counter?\n\n\u003e\u003e Are you required to wait for my accept/reject message replies before\n\u003e\u003e commiting? Or does the commit message include a counter?\n\u003e\n\u003e Any which is accepted by the other party is included. Two IDs, one for\n\u003e each party, is included. Two are necessary to allow for timing issues\n\u003e with HTLC Add responses in-flight not being fully synced up.\n\nRight.\n\n\u003e\u003e I guess \"asynchronous\" is a bit nebulous: out-of-order or in-order? I\n\u003e\u003e couldn't see a good reason for out-of-order. Whereas letting both\n\u003e\u003e sides offer updates in parallel makes good sense for throughput...\n\u003e\n\u003e In-order. I should have an update in the coming days for lnstate if that\n\u003e helps (various protocol updates, e.g. fixing exchanging of revocation\n\u003e hashes, etc.)\n\nThanks, I feel smarter now! :)\n\nCheers,\nRusty.",
"sig": "da97e03a5087e53a74ab52553324504674bb6757a94f9753aec6efb21a5ac79aa536a1666bb5e9b049d133b7d1132dc594a9d3d43a9ed407d3994186e8d33360"
}