📅 Original date posted:2016-02-02
📝 Original message:
Joseph Poon <joseph at lightning.network> writes:
> Hi Rusty,
>
> For synchronous across-the-wire commit steps, 3 steps is a good idea and
> more secure than 2 steps for the commit transaction.
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?
It's probably simpler to do a three way handshake on every stage, but I
didn't see that in your protocol?
> However, the nice thing about keeping everything asynchronous is it
> simplifies orchestration and no locking across-the-wire. We have a
> preliminary explanation on the git repo in the README.md file.
Yes, but it was a bit dense. Or I am :)
If I receive "add request" "add request" "signed commit", how do I know
what that signatures covers? Both new htlcs? Are you required to wait
for my accept/reject message replies before commiting? Or does the
commit message include a counter?
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...
Thanks!
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:45:40
in reply to nevent1q…y8qc
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:45:40Event JSON
{
"id": "a8897acafc38e984b00633d8e9aeb97ae40e974e9356567c559adeee48ec408d",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314740,
"kind": 1,
"tags": [
[
"e",
"18682649fe79f5a2c54629ca1e6d86742074bd7eba6c99aba4f0188eb011b6a3",
"",
"root"
],
[
"e",
"b1e9b50b617cf32145dfbc20d9a02cf33c2ba552cd76a6e7622e074042c2e5bb",
"",
"reply"
],
[
"p",
"ccb4cc87c455b74febaee5929cfd0726421b2eea64ad2b16440b68e8c7433211"
]
],
"content": "📅 Original date posted:2016-02-02\n📝 Original message:\nJoseph Poon \u003cjoseph at lightning.network\u003e writes:\n\u003e Hi Rusty,\n\u003e\n\u003e For synchronous across-the-wire commit steps, 3 steps is a good idea and\n\u003e more secure than 2 steps for the commit transaction.\n\nI guess it depends how we count steps. Each party needs to receive the\nsignature for the N+1 commit tx before handing over the Nth revocation\npreimage, but that's the only irreducible constraint isn't it?\n\nIt's probably simpler to do a three way handshake on every stage, but I\ndidn't see that in your protocol?\n\n\u003e However, the nice thing about keeping everything asynchronous is it\n\u003e simplifies orchestration and no locking across-the-wire. We have a\n\u003e preliminary explanation on the git repo in the README.md file.\n\nYes, but it was a bit dense. Or I am :)\n\nIf I receive \"add request\" \"add request\" \"signed commit\", how do I know\nwhat that signatures covers? Both new htlcs? Are you required to wait\nfor my accept/reject message replies before commiting? Or does the\ncommit message include a counter?\n\nI guess \"asynchronous\" is a bit nebulous: out-of-order or in-order? I\ncouldn't see a good reason for out-of-order. Whereas letting both sides\noffer updates in parallel makes good sense for throughput...\n\nThanks!\nRusty.",
"sig": "ae83a73e965506717641a255e5803094108ef9da5256579ff16b46b255a887c3beff7176d51ebeb49eb6b7972cbd21f4b4e4b882fba66d7c754c8988bffe8a03"
}