📅 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>;
Lloyd Fournier [ARCHIVE] /
npub1kh…y05yp
2023-06-09 13:02:31
in reply to nevent1q…9a69
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypPublished at
2023-06-09 13:02:31Event JSON
{
"id": "c7bf78ad6a242f94b1f104b40625b064514ea03d879c2a3736ce156aa087f7b9",
"pubkey": "b5ff7c704f90e4eebfa414c0a017a84544c32586a1bd2fc86c74c2914d03c25e",
"created_at": 1686315751,
"kind": 1,
"tags": [
[
"e",
"7ab4fa35e6b278d8bea1b5efdcbc58ea834d6522b2d39ad439fcb5fecb4d4b54",
"",
"root"
],
[
"e",
"ed8393944b2b5eeddba0dee803992a18edccd2f9fb267791e4295f9d276b4ba8",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 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",
"sig": "36fb2d8e7f277274a37144af3ac3233b8828df5875f132dfae3187b5c1436549b447655cb4907a437e2e02edd8b7bbf1178c6e01fef9be8b5013679ece018fd9"
}