{"type":"rich","version":"1.0","title":"Lloyd Fournier [ARCHIVE] wrote","author_name":"Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)","author_url":"https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-06-07\n📝 Original message:\nHi Z,\n\nI agree with your analysis. This is how I pictured eltoo fast forwards\nworking as well.\n\nAnother interesting thing about this idea is that it could allow a new type\nof custodial LN provider where the custodian is only in charge of receiving\npayments to the channel but cannot spend them.\nWith the non-custodial LN phone apps there is this annoying UX where you\nhave to keep the app open to receive a payment (because the pre-image is on\nmy phone).\nI wouldn't mind letting the provider handle receiving payments on my behalf.\nOf course this means they would be able to steal the money in the FF state\nbut this is a big reduction in risk from a full custodial solution.\nIn other words, you should be able to get the seamless experience of a\nfully custodial wallet while only giving them custody of small amounts of\ncoins for a short time.\n\nOn Wed, 2 Jun 2021 at 13:30, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e\n\u003e Another advantage here is that unlike the Poon-Dryja Fast Forwards, we do\n\u003e *not* build up a long chain of HTLC txes.\n\u003e At the worst case, we have an old update tx that is superseded by a later\n\u003e update tx instead, thus the overhead is expected to be at most 1 extra\n\u003e update tx no matter how many HTLCs are offered while Bob has its privkey\n\u003e offline.\n\u003e\n\nI don't think you need to build up a long chain of HTLC txs for the\nPoon-Dryja fast forward in the \"desync\" approach. Each one just replaces\nthe other.\n\nCheers,\n\nLL\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210607/510d656b/attachment.html\u003e"}