Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2021-06-01 📝 Original message: Hi Z, I just went through ...
📅 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>;
📝 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>;