{"type":"rich","version":"1.0","title":"Lloyd Fournier [ARCHIVE] wrote","author_name":"Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)","author_url":"https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-06-01\n📝 Original message:\nHi Z,\n\nI just went through the presentation which made your thinking very clear.\nThanks.\nI will not be able to match this effort so please bear with me as I try and\nexplain my own thinking.\nI don't see why fast forwards (FF) need \"symmetrically encumbered outputs\"?\nTo me the protocol should be asymmetric.\n\nThis is what I think happens when offering a FF HTLC:\n1. The offerer creates and signs a new commitment tx as normal with the\nHTLC except it has the same revocation key as the last one.\n2. The offerer patches their balance output by sending a tx spending from\nit to a new tx which has the HTLC output and their balance output\n(unencumbered).\n\nThe HTLC is now irrevocably committed from the perspective of the receiver.\nNow the receiver presents the pre-image and the offerer then:\n\n1. The offerer creates and signs a new commitment tx as normal\nconsolidating the funds into the receiver's balance output except once\nagain it has the same revocation key as the last one.\n2. The offerer patches their commitment tx balance output again by sending\na tx spending from it to a new tx which splits into the receiver's balance\n(the value of the claimed HTLC) and the offerer's remaining balance.\n\nYou can repeat the above process without having the receiver's revocation\nkeys online or their commitment tx keys for many HTLCs while the offerer\nstill has balance towards the receiver.\nThe on-chain cost is about the same as before for an uncooperative close.\n\nOnce the receiver brings their keys on line they can consolidate the FF\nstate into a new commitment txs on both sides and with a proper revocation\noperate the channel normally. What has been the receiver up until now can\nfinally send funds.\n\nAm I missing something?\n\nCheers,\n\nLL\n\nOn Mon, 31 May 2021 at 19:47, ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning list,\n\u003e\n\u003e \u003e It may be difficult to understand this, so maybe I will make a\n\u003e convenient presentation of some sort.\n\u003e\n\u003e As promised: https://zmnscpxj.github.io/offchain/2021-06-fast-forwards.odp\n\u003e\n\u003e The presentation is intended to be seen by semi-technical and technical\n\u003e people, particular those that have not read (or managed to fully read and\n\u003e understand) the original writeup in 2019.\n\u003e Simply \"run\" the presentation (F5 in LibreOffice), as the presentation\n\u003e uses callouts extensively for explication.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210602/d72b5993/attachment.html\u003e"}