{"type":"rich","version":"1.0","title":"ZmnSCPxj [ARCHIVE] wrote","author_name":"ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)","author_url":"https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-06-01\n📝 Original message:\nGood morning LL,\n\n\u003e Hi Z,\n\u003e\n\u003e I just went through the presentation which made your thinking very clear. Thanks.\n\u003e I will not be able to match this effort so please bear with me as I try and explain my own thinking.\n\u003e I don't see why fast forwards (FF) need \"symmetrically encumbered outputs\"? To me the protocol should be asymmetric.\n\u003e\n\u003e This is what I think happens when offering a FF HTLC:\n\u003e 1. The offerer creates and signs a new commitment tx as normal with the HTLC except it has the same revocation key as the last one.\n\u003e 2. The offerer patches their balance output by sending a tx spending from it to a new tx which has the HTLC output and their balance output (unencumbered).\n\u003e\n\u003e The HTLC is now irrevocably committed from the perspective of the receiver.\n\u003e Now the receiver presents the pre-image and the offerer then:\n\u003e\n\u003e 1. The offerer creates and signs a new commitment tx as normal consolidating the funds into the receiver's balance output except once again it has the same revocation key as the last one.\n\u003e 2. The offerer patches their commitment tx balance output again by sending a tx spending from it to a new tx which splits into the receiver's balance (the value of the claimed HTLC) and the offerer's remaining balance.\n\u003e\n\u003e You can repeat the above process without having the receiver's revocation keys online or their commitment tx keys for many HTLCs while the offerer still has balance towards the receiver.\n\u003e The on-chain cost is about the same as before for an uncooperative close.\n\u003e\n\u003e Once the receiver brings their keys on line they can consolidate the FF state into a new commitment txs on both sides and with a proper revocation operate the channel normally. What has been the receiver up until now can finally send funds.\n\u003e\n\u003e Am I missing something?\n\nBasically, you are taking advantage of the fact that we **actually** let the commitments on both sides be desynchronized with each other.\nI tend to elide this fact when explaining, and also avoid it when planning protocols.\n\nHowever I believe the idea is correct.\n\nAnyway, as I understood it:\n\nSo suppose we start with this pair of commitment txes:\n\n    +--------------------------+\n    |  Commitment tx 1 of A    |\n    +------------+-------------+\n    |            | (A[0] \u0026\u0026 B) |\n    |            |||(A \u0026\u0026 CSV) |\n    |    SigB    +-------------+\n    |            |      B      |\n    |            |             |\n    +------------+-------------+\n\n    +--------------------------+\n    |  Commitment tx 1 of B    |\n    +------------+-------------+\n    |    SigA    |      A      |\n    |            |             |\n    |            +-------------+\n    |            | (A \u0026\u0026 B[0]) |\n    |            |||(B \u0026\u0026 CSV) |\n    +------------+-------------+\n\nNow Alice wants to offer an HTLC to Bob.\nWhat Alice does is:\n\n* **Retain** the Alice commitment tx and create an HTLC tx spending from it.\n* **Advance** the Bob commitment tx (and letting it desync from the Alice commitment tx), adding the same HTLC.\n\nSo after Alice sends its new signatures, our offchain txes are:\n\n    +--------------------------+    +--------------------------+\n    |  Commitment tx 1 of A    |    |          HTLC Tx         |\n    +------------+-------------+    +------------+-------------+\n    |            | (A[0] \u0026\u0026 B) |---\u003e|  SigA[0]   | (A[0] \u0026\u0026 B) |\n    |            |||(A \u0026\u0026 CSV) |    |            |||(A \u0026\u0026 CSV) |\n    |    SigB    +-------------+    |            +-------------+\n    |            |      B      |    |            |    A-\u003eB     |\n    |            |             |    |            |    HTLC     |\n    +------------+-------------+    +------------+-------------+\n\n    +--------------------------+\n    | Commitment tx *2* of B   |\n    +------------+-------------+\n    |    SigA    |      A      |\n    |            |             |\n    |            +-------------+\n    |            | (A \u0026\u0026 B[1]) |\n    |            |||(B \u0026\u0026 CSV) |\n    |            +-------------+\n    |            |    A-\u003eB     |\n    |            |    HTLC     |\n    +------------+-------------+\n\nNotes:\n\n* Again, for Alice to offer the HTLC to Bob, only Alice has to make new signatures (`SigA[0]` and `SigA` for commitment tx *2* of Bob).\n* If Alice goes offline and Bob decides to drop onchain, Bob only needs to sign the new commitment tx.\n  We can argue that dropping channels *should* be rare enough that requiring privkeys for this operation is not a burden.\n* If Alice decides to drop the channel onchain, Bob only needs to bring in the privkey for the HTLC tx, which we can (at a lower, detailed level) be different from the \"main\" B privkey.\n\nSo yes, I think it seems workable without symmetric encumbrance.\n\nRegards.\nZmnSCPxj"}