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 <zmnsc...@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
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev