rich1.0Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypnjumphttps://yabu.me📅 Original date posted:2021-06-07 📝 Original message: 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>