From lloyd.fourn at gmail.com Mon Jun 7 03:21:19 2021 From: lloyd.fourn at gmail.com (Lloyd Fournier) Date: Mon, 7 Jun 2021 13:21:19 +1000 Subject: [Lightning-dev] Improving Payment Latency by Fast Forwards In-Reply-To: References: Message-ID: 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 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: