{"type":"rich","version":"1.0","title":"Rusty Russell [ARCHIVE] wrote","author_name":"Rusty Russell [ARCHIVE] (npub1zw…hkhpx)","author_url":"https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-10-12\n📝 Original message:\nHi all,\n\n        Our HTLC state machine is optimal, but complex[1]; the Lightning\nLabs team recently did some excellent work finding another place the spec\nis insufficient[2].  Also, the suggestion for more dynamic changes makes it\nmore difficult, usually requiring forced quiescence.\n\nThe following protocol returns to my earlier thoughts, with cost of\nlatency in some cases.\n\n1. The protocol is half-duplex, with each side taking turns; opener first.\n2. It's still the same form, but it's always one-direction so both sides\n   stay in sync.\n        update+-\u003e commitsig-\u003e \u003c-revocation \u003c-commitsig revocation-\u003e\n3. A new message pair \"turn_request\" and \"turn_reply\" let you request\n   when it's not your turn.\n4. If you get an update in reply to your turn_request, you lost the race\n   and have to defer your own updates until after peer is finished.\n5. On reconnect, you send two flags: send-in-progress (if you have\n   sent the initial commitsig but not the final revocation) and\n   receive-in-progress (if you have received the initial commitsig\n   not not received the final revocation).  If either is set,\n   the sender (as indicated by the flags) retransmits the entire\n   sequence.\n   Otherwise, (arbitrarily) opener goes first again.\n\nPros:\n1. Way simpler.  There is only ever one pair of commitment txs for any\n   given commitment index.\n2. Fee changes are now deterministic.  No worrying about the case where\n   the peer's changes are also in flight.\n3. Dynamic changes can probably happen more simply, since we always\n   negotiate both sides at once.\n\nCons:\n1. If it's not your turn, it adds 1 RTT latency.\n\nUnchanged:\n1. Database accesses are unchanged; you need to commit when you send or\n   receive a commitsig.\n2. You can use the same state machine as before, but one day (when\n   this would be compulsory) you'll be able signficantly simplify;\n   you'll need to record the index at which HTLCs were changed\n   (added/removed) in case peer wants you to rexmit though.\n\nCheers,\nRusty.\n\n[1] This is my fault; I was persuaded early on that optimality was more\n    important than simplicity in a classic nerd-snipe.\n[2] https://github.com/lightningnetwork/lightning-rfc/issues/794"}