<oembed><type>rich</type><version>1.0</version><title>Lloyd Fournier [ARCHIVE] wrote</title><author_name>Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)</author_name><author_url>https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp</author_url><provider_name>njump</provider_name><provider_url>https://yabu.me</provider_url><html>📅 Original date posted:2021-06-01&#xA;📝 Original message:&#xA;Hi Z,&#xA;&#xA;I just went through the presentation which made your thinking very clear.&#xA;Thanks.&#xA;I will not be able to match this effort so please bear with me as I try and&#xA;explain my own thinking.&#xA;I don&#39;t see why fast forwards (FF) need &#34;symmetrically encumbered outputs&#34;?&#xA;To me the protocol should be asymmetric.&#xA;&#xA;This is what I think happens when offering a FF HTLC:&#xA;1. The offerer creates and signs a new commitment tx as normal with the&#xA;HTLC except it has the same revocation key as the last one.&#xA;2. The offerer patches their balance output by sending a tx spending from&#xA;it to a new tx which has the HTLC output and their balance output&#xA;(unencumbered).&#xA;&#xA;The HTLC is now irrevocably committed from the perspective of the receiver.&#xA;Now the receiver presents the pre-image and the offerer then:&#xA;&#xA;1. The offerer creates and signs a new commitment tx as normal&#xA;consolidating the funds into the receiver&#39;s balance output except once&#xA;again it has the same revocation key as the last one.&#xA;2. The offerer patches their commitment tx balance output again by sending&#xA;a tx spending from it to a new tx which splits into the receiver&#39;s balance&#xA;(the value of the claimed HTLC) and the offerer&#39;s remaining balance.&#xA;&#xA;You can repeat the above process without having the receiver&#39;s revocation&#xA;keys online or their commitment tx keys for many HTLCs while the offerer&#xA;still has balance towards the receiver.&#xA;The on-chain cost is about the same as before for an uncooperative close.&#xA;&#xA;Once the receiver brings their keys on line they can consolidate the FF&#xA;state into a new commitment txs on both sides and with a proper revocation&#xA;operate the channel normally. What has been the receiver up until now can&#xA;finally send funds.&#xA;&#xA;Am I missing something?&#xA;&#xA;Cheers,&#xA;&#xA;LL&#xA;&#xA;On Mon, 31 May 2021 at 19:47, ZmnSCPxj via Lightning-dev &lt;&#xA;lightning-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&#xA;&gt; Good morning list,&#xA;&gt;&#xA;&gt; &gt; It may be difficult to understand this, so maybe I will make a&#xA;&gt; convenient presentation of some sort.&#xA;&gt;&#xA;&gt; As promised: https://zmnscpxj.github.io/offchain/2021-06-fast-forwards.odp&#xA;&gt;&#xA;&gt; The presentation is intended to be seen by semi-technical and technical&#xA;&gt; people, particular those that have not read (or managed to fully read and&#xA;&gt; understand) the original writeup in 2019.&#xA;&gt; Simply &#34;run&#34; the presentation (F5 in LibreOffice), as the presentation&#xA;&gt; uses callouts extensively for explication.&#xA;&gt;&#xA;&gt; Regards,&#xA;&gt; ZmnSCPxj&#xA;&gt;&#xA;&gt;&#xA;&gt; _______________________________________________&#xA;&gt; Lightning-dev mailing list&#xA;&gt; Lightning-dev at lists.linuxfoundation.org&#xA;&gt; https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev&#xA;&gt;&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210602/d72b5993/attachment.html&gt;</html></oembed>