{"type":"rich","version":"1.0","title":"Christian Decker [ARCHIVE] wrote","author_name":"Christian Decker [ARCHIVE] (npub1wt…gtuyn)","author_url":"https://yabu.me/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuyn","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-10-13\n📝 Original message:\nI wonder if we should just go the tried-and-tested leader-based\nmechanism:\n\n 1. The node with the lexicographically lower node_id is determined to\n    be the leader.\n 2. The leader receives proposals for changes from itself and the peer\n    and orders them into a logical sequence of changes\n 3. The leader applies the changes locally and streams them to the peer.\n 4. Either node can initiate a commitment by proposing a `flush` change.\n 5. Upon receiving a `flush` the nodes compute the commitment\n    transaction and exchange signatures.\n\nThis is similar to your proposal, but does away with turn changes (it's\nalways the leader's turn), and therefore reduces the state we need to\nkeep track of (and re-negotiate on reconnect).\n\nThe downside is that we add a constant overhead to one side's\noperations, but since we pipeline changes, and are mostly synchronous\nduring the signing of the commitment tx today anyway, this comes out to\n1 RTT for each commitment.\n\nOn the other hand a token-passing approach (which I think is what you\npropose) require a synchronous token handover whenever a the direction\nof the updates changes. This is assuming I didn't misunderstand the turn\nmechanics of your proposal :-)\n\nCheers,\nChristian\n\nRusty Russell \u003crusty at rustcorp.com.au\u003e writes:\n\u003e Hi all,\n\u003e\n\u003e         Our HTLC state machine is optimal, but complex[1]; the Lightning\n\u003e Labs team recently did some excellent work finding another place the spec\n\u003e is insufficient[2].  Also, the suggestion for more dynamic changes makes it\n\u003e more difficult, usually requiring forced quiescence.\n\u003e\n\u003e The following protocol returns to my earlier thoughts, with cost of\n\u003e latency in some cases.\n\u003e\n\u003e 1. The protocol is half-duplex, with each side taking turns; opener first.\n\u003e 2. It's still the same form, but it's always one-direction so both sides\n\u003e    stay in sync.\n\u003e         update+-\u003e commitsig-\u003e \u003c-revocation \u003c-commitsig revocation-\u003e\n\u003e 3. A new message pair \"turn_request\" and \"turn_reply\" let you request\n\u003e    when it's not your turn.\n\u003e 4. If you get an update in reply to your turn_request, you lost the race\n\u003e    and have to defer your own updates until after peer is finished.\n\u003e 5. On reconnect, you send two flags: send-in-progress (if you have\n\u003e    sent the initial commitsig but not the final revocation) and\n\u003e    receive-in-progress (if you have received the initial commitsig\n\u003e    not not received the final revocation).  If either is set,\n\u003e    the sender (as indicated by the flags) retransmits the entire\n\u003e    sequence.\n\u003e    Otherwise, (arbitrarily) opener goes first again.\n\u003e\n\u003e Pros:\n\u003e 1. Way simpler.  There is only ever one pair of commitment txs for any\n\u003e    given commitment index.\n\u003e 2. Fee changes are now deterministic.  No worrying about the case where\n\u003e    the peer's changes are also in flight.\n\u003e 3. Dynamic changes can probably happen more simply, since we always\n\u003e    negotiate both sides at once.\n\u003e\n\u003e Cons:\n\u003e 1. If it's not your turn, it adds 1 RTT latency.\n\u003e\n\u003e Unchanged:\n\u003e 1. Database accesses are unchanged; you need to commit when you send or\n\u003e    receive a commitsig.\n\u003e 2. You can use the same state machine as before, but one day (when\n\u003e    this would be compulsory) you'll be able signficantly simplify;\n\u003e    you'll need to record the index at which HTLCs were changed\n\u003e    (added/removed) in case peer wants you to rexmit though.\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n\u003e\n\u003e [1] This is my fault; I was persuaded early on that optimality was more\n\u003e     important than simplicity in a classic nerd-snipe.\n\u003e [2] https://github.com/lightningnetwork/lightning-rfc/issues/794\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev"}