📅 Original date posted:2016-02-02
📝 Original message:
On Wed, Feb 03, 2016 at 11:02:50AM +1030, Rusty Russell wrote:
> I guess it depends how we count steps. Each party needs to receive the
> signature for the N+1 commit tx before handing over the Nth revocation
> preimage, but that's the only irreducible constraint isn't it?
Correct, that is a necessity for a secure implementation.
> It's probably simpler to do a three way handshake on every stage, but I
> didn't see that in your protocol?
Unlike a 3-step synchronous commitment, it doesn't wait for the other
party to send their sigantures/revocations and can happen
simultaneously.
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.
> 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.
> 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.
> 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.)
--
Joseph Poon
Joseph Poon [ARCHIVE] /
npub1ej…p9cq8
2023-06-09 12:45:40
in reply to nevent1q…wyzh
Author Public Key
npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8Published at
2023-06-09 12:45:40Event JSON
{
"id": "6e59eaf23ec39cfe50c4ab8dda4e2f33ef1a96b259895714cc286da1fcac815c",
"pubkey": "ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211",
"created_at": 1686314740,
"kind": 1,
"tags": [
[
"e",
"18682649fe79f5a2c54629ca1e6d86742074bd7eba6c99aba4f0188eb011b6a3",
"",
"root"
],
[
"e",
"a8897acafc38e984b00633d8e9aeb97ae40e974e9356567c559adeee48ec408d",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2016-02-02\n📝 Original message:\nOn Wed, Feb 03, 2016 at 11:02:50AM +1030, Rusty Russell wrote:\n\u003e I guess it depends how we count steps. Each party needs to receive the\n\u003e signature for the N+1 commit tx before handing over the Nth revocation\n\u003e preimage, but that's the only irreducible constraint isn't it?\n\nCorrect, that is a necessity for a secure implementation.\n\n\u003e It's probably simpler to do a three way handshake on every stage, but I\n\u003e didn't see that in your protocol?\n\nUnlike a 3-step synchronous commitment, it doesn't wait for the other\nparty to send their sigantures/revocations and can happen\nsimultaneously.\n\nBob's broadcastable Commitment: Alice sends a Signature to Bob. Bob\nsends the Revocation of the previous Commitment to Alice.\n\nAlice's broadcastable Commitment: Bob sends a Signature to Alice. Alice\nsends to Revocation of the previous Commitment to Bob.\n\nIt's that simple. If the HTLC is reflected in both and the previous\ncommitment(s) is/are revoked, then it's complete.\n\n\u003e If I receive \"add request\" \"add request\" \"signed commit\", how do I know\n\u003e what that signatures covers? \n\nThe protocol is still being optimized (deprecating the even/odd\nstructure, etc.), but the structure is both parties have a list of HTLC\nmodifications which they want to update. When the modification is\nacknowledged by the other party, the HTLC modifcation request is staged\ninto the next Commitment signature. The inclusion of modifications are\nenumerated by including both parties' higest HTLC ID (two of them) in\neach Commitment signature message.\n\n\u003e Are you required to wait for my accept/reject message replies before\n\u003e commiting? Or does the commit message include a counter?\n\nAny which is accepted by the other party is included. Two IDs, one for\neach party, is included. Two are necessary to allow for timing issues\nwith HTLC Add responses in-flight not being fully synced up.\n\n\u003e I guess \"asynchronous\" is a bit nebulous: out-of-order or in-order? I\n\u003e couldn't see a good reason for out-of-order. Whereas letting both\n\u003e sides offer updates in parallel makes good sense for throughput...\n\nIn-order. I should have an update in the coming days for lnstate if that\nhelps (various protocol updates, e.g. fixing exchanging of revocation\nhashes, etc.)\n\n-- \nJoseph Poon",
"sig": "7115523e70ca4e61da6b37a10679d23e7101cea4530723f9864fa7962fd586741330ea44044272b42bd068eb91802b6f84c355f661068b21bd532601b408b559"
}