📅 Original date posted:2021-06-01
📝 Original message:
Hi Z,
I just went through the presentation which made your thinking very clear.
Thanks.
I will not be able to match this effort so please bear with me as I try and
explain my own thinking.
I don't see why fast forwards (FF) need "symmetrically encumbered outputs"?
To me the protocol should be asymmetric.
This is what I think happens when offering a FF HTLC:
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.
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).
The HTLC is now irrevocably committed from the perspective of the receiver.
Now the receiver presents the pre-image and the offerer then:
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.
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.
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.
The on-chain cost is about the same as before for an uncooperative close.
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.
Am I missing something?
Cheers,
LL
On Mon, 31 May 2021 at 19:47, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning list,
>
> > It may be difficult to understand this, so maybe I will make a
> convenient presentation of some sort.
>
> As promised: https://zmnscpxj.github.io/offchain/2021-06-fast-forwards.odp
>
> The presentation is intended to be seen by semi-technical and technical
> people, particular those that have not read (or managed to fully read and
> understand) the original writeup in 2019.
> Simply "run" the presentation (F5 in LibreOffice), as the presentation
> uses callouts extensively for explication.
>
> Regards,
> ZmnSCPxj
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210602/d72b5993/attachment.html>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 13:02:31
in reply to nevent1q…33n4
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 13:02:31Event JSON
{
"id": "e15265ce44ee54e4aceb5f1ae40b7cdcdd64bea867c2a40e4a080a8f3015ea09",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315751,
"kind": 1,
"tags": [
[
"e",
"7ab4fa35e6b278d8bea1b5efdcbc58ea834d6522b2d39ad439fcb5fecb4d4b54",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 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",
"sig": "bafd19a3133a2675532c343240df99b4ca8ffa7f2398efcaa9bcdc7f0164aba23b78722136790224604320b25d605470fcdb99410ccf7f034706332812550ff2"
}