📅 Original date posted:2020-10-14
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
> I wonder if we should just go the tried-and-tested leader-based
> mechanism:
>
> 1. The node with the lexicographically lower node_id is determined to
> be the leader.
> 2. The leader receives proposals for changes from itself and the peer
> and orders them into a logical sequence of changes
> 3. The leader applies the changes locally and streams them to the peer.
> 4. Either node can initiate a commitment by proposing a `flush` change.
> 5. Upon receiving a `flush` the nodes compute the commitment
> transaction and exchange signatures.
>
> This is similar to your proposal, but does away with turn changes (it's
> always the leader's turn), and therefore reduces the state we need to
> keep track of (and re-negotiate on reconnect).
But now you need to be able to propose two kinds of things, which is
actually harder to implement; update-from-you and update-from-me. This
is a deeper protocol change.
And you don't get the benefit of the turn-taking approach, which is that
you can have a known state for fee changes. Even if you change it to
have opener always the leader, it still has to handle the case where
incoming changes are not allowed under the new fee regime (and similar
issues for other dynamic updates).
> The downside is that we add a constant overhead to one side's
> operations, but since we pipeline changes, and are mostly synchronous
> during the signing of the commitment tx today anyway, this comes out to
> 1 RTT for each commitment.
Yeah, it adds 1RTT to every hop on the network, vs my proposal which
adds just over 1/2 RTT on average.
> On the other hand a token-passing approach (which I think is what you
> propose) require a synchronous token handover whenever a the direction
> of the updates changes. This is assuming I didn't misunderstand the turn
> mechanics of your proposal :-)
Yes, but it alternates because that's optimal for a non-busy channel
(since it's usually "Alice adds htlc, Bob completes the htlc").
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 13:01:21
in reply to nevent1q…p2gy
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 13:01:21Event JSON
{
"id": "1961d100f1b41d55a379c9acce8060e86f6eab23c9818166f7f2d0c37b00f25d",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315681,
"kind": 1,
"tags": [
[
"e",
"979ba1732a5bff6ecbedadd53fb6514308c996861998729f33c9b71e23f85e90",
"",
"root"
],
[
"e",
"3cea7b6f081618b72a2b7d154491b4edefe246a8445ecb26393fe566e7d7a368",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2020-10-14\n📝 Original message:\nChristian Decker \u003cdecker.christian at gmail.com\u003e writes:\n\u003e I wonder if we should just go the tried-and-tested leader-based\n\u003e mechanism:\n\u003e\n\u003e 1. The node with the lexicographically lower node_id is determined to\n\u003e be the leader.\n\u003e 2. The leader receives proposals for changes from itself and the peer\n\u003e and orders them into a logical sequence of changes\n\u003e 3. The leader applies the changes locally and streams them to the peer.\n\u003e 4. Either node can initiate a commitment by proposing a `flush` change.\n\u003e 5. Upon receiving a `flush` the nodes compute the commitment\n\u003e transaction and exchange signatures.\n\u003e\n\u003e This is similar to your proposal, but does away with turn changes (it's\n\u003e always the leader's turn), and therefore reduces the state we need to\n\u003e keep track of (and re-negotiate on reconnect).\n\nBut now you need to be able to propose two kinds of things, which is\nactually harder to implement; update-from-you and update-from-me. This\nis a deeper protocol change.\n\nAnd you don't get the benefit of the turn-taking approach, which is that\nyou can have a known state for fee changes. Even if you change it to\nhave opener always the leader, it still has to handle the case where\nincoming changes are not allowed under the new fee regime (and similar\nissues for other dynamic updates).\n\n\u003e The downside is that we add a constant overhead to one side's\n\u003e operations, but since we pipeline changes, and are mostly synchronous\n\u003e during the signing of the commitment tx today anyway, this comes out to\n\u003e 1 RTT for each commitment.\n\nYeah, it adds 1RTT to every hop on the network, vs my proposal which\nadds just over 1/2 RTT on average.\n\n\u003e On the other hand a token-passing approach (which I think is what you\n\u003e propose) require a synchronous token handover whenever a the direction\n\u003e of the updates changes. This is assuming I didn't misunderstand the turn\n\u003e mechanics of your proposal :-)\n\nYes, but it alternates because that's optimal for a non-busy channel\n(since it's usually \"Alice adds htlc, Bob completes the htlc\").\n\nCheers,\nRusty.",
"sig": "960ab966b8460357040236ff3ccad50f6642631382cbe8913bb3ab5dfeff3779afbcc5b62e449c1607ad257525a4db4e3269ef6b68a75a72ce8035e307afb6be"
}