[Lightning-dev] Improving Payment Latency by Fast Forwards

[Lloyd Fournier]

Hi Z,

I agree with your analysis. This is how I pictured eltoo fast forwards
working as well.

Another interesting thing about this idea is that it could allow a new type
of custodial LN provider where the custodian is only in charge of receiving
payments to the channel but cannot spend them.
With the non-custodial LN phone apps there is this annoying UX where you
have to keep the app open to receive a payment (because the pre-image is on
my phone).
I wouldn't mind letting the provider handle receiving payments on my behalf.
Of course this means they would be able to steal the money in the FF state
but this is a big reduction in risk from a full custodial solution.
In other words, you should be able to get the seamless experience of a
fully custodial wallet while only giving them custody of small amounts of
coins for a short time.

On Wed, 2 Jun 2021 at 13:30, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

>
> Another advantage here is that unlike the Poon-Dryja Fast Forwards, we do
> *not* build up a long chain of HTLC txes.
> At the worst case, we have an old update tx that is superseded by a later
> update tx instead, thus the overhead is expected to be at most 1 extra
> update tx no matter how many HTLCs are offered while Bob has its privkey
> offline.
>

I don't think you need to build up a long chain of HTLC txs for the
Poon-Dryja fast forward in the "desync" approach. Each one just replaces
the other.

Cheers,

LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210607/510d656b/attachment.html>