đź“… Original date posted:2022-08-31
đź“ť Original message:
Hi folks,
I think I've seen wallets supporting "send max" when a zero-amount invoice
was used. So isn't it a problem with the custodial service not supporting
it?
Whatever idea we figure out they can just refuse to implement it so we
can't force them into improving and being custodial they could steal
already, so that shouldn't be an issue.
Have a nice day!
Martin
On Sat, 27 Aug 2022 at 04:06, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Rene,
>
> > Dear fellow Lightning Developers,
> >
> > I was recently on an event where the visitors have been gifted 10k sats
> on a custodial wallet. They could spend those sats via some web interface
> and an NFC card. During the event I was contacted by several plebs who were
> confused about one particular thing:
> > It was impossible for them to withdraw the full amount from the service.
> >
> > Pasting an invoice for 10k sats would not work as the custodial service
> required a fee budget of 1%. However if people submitted an invoice for
> 9900 sats the remaining 100 sats were usually not fully required for the
> fees. Thus the users may have had a leftover of for example 67 sats. Now
> the problem repeated on the residual amount. While some services seem to
> have a drain feature for such a situation I find this frustrating and was
> wondering if we could help directly on a protocol level.
> >
> > Here is my proposal for a simple solution to this specific problem:
> `option_recipient_pays_routing_fees`
> >
> > This would be a new flag in invoices signaling that the recipient is
> willing to pay for the routing fees by releasing the preimage even if the
> full amount has not been arrived in htlcs at the recipient.
> >
> > So the workflow would be the following:
> >
> > 1. Alice creates an invoice for 10k sats setting the
> `option_recipient_pays_routing_fees` flag in the invoice and passes it
> either to custodial user Bob or to her own custodial account.
> > 2. The payer parses the invoice and searches for a payment path or
> payment flow to Alice.
> > 3. Because `option_recipient_pays_routing_fee` is set, the onion is not
> constructed in a way that the final HTLC will be for the amount of 10k sats
> but rather in a way that the first htlc will be for 10k sats and the
> following HTLCs will be of decreasing value so that routing nodes are
> compensated properly.
> > 4. When the HTLC(s) arrive at Alice she will release the preimage if and
> only if not too many sats (e.g. 1% of the amount) are missing. Of course it
> would be good if the 1% was not hard coded in the protocol / software but
> configurable by Alice at the time of invoice creation.
> >
> > I think the main issue with this proposal is that instead of confusing
> users who wish to drain an account we may now have to educate users about
> two different invoice types. On the other hand I think this can probably
> easily be achieved via the current wide spread user interfaces. Of course
> it may be nice to have folks from the Bitcoin Design community to join this
> specific part of the discussion.
>
> In theory, trampoline routes / whatever-the-cool-name-is-now should fix
> this problem as well.
> I am referring to that scheme where the invoice contains an onion and a
> "trampoline" node that is the only node that can decrypt the first layer of
> the onion.
> The sender then has to route to the trampoline node, and the trampoline
> node then receives the rest of the onion.
>
> In this scheme, the receiver provides an encrypted route from some node to
> itself.
> As the receiver provides the route in order to gain privacy from the
> sender, the onus is on the receiver to deduct the fees from its received
> funds.
> i.e. the sender is only responsible for paying for fees up to the entry
> point of the trampoline.
>
> Thus, such a drain requirement simply means that the custodial service has
> to give its node ID.
> Then the receiver finds a route from the custodial service to itself, and
> encodes that in the trampoline onion, with a direct neighbor of the
> custodial service node as the trampoline.
> The custodial service then does not care about any fees as the receiver
> decided the route; the receiver knows exactly how much to expect (since it
> calculated the route).
>
>
> Of course, it is also possible as you propose, but any level-1-selfish
> custodial service will then always keep the remaining fee budget and always
> ensure that the receiver gets 99% of the value (or 100% -
> whatever_setting_they_chose), paying fees, and keeping the remaining 1% for
> itself.
> The receiver in this case cannot audit the route anyway, and thus cannot
> determine how much the true fees are; whereas in the trampoline case the
> route is specifically selected by the receiver.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220831/26c6eb67/attachment.html>;
Martin Habovštiak [ARCHIVE] /
npub186…y2s83
2023-06-09 13:06:43
in reply to nevent1q…eywd
Author Public Key
npub186h7xm74e8dqvz64kzhx8aq3j47lwf3emlxl7w8j0d0thrth65vs9y2s83Published at
2023-06-09 13:06:43Event JSON
{
"id": "909f3845d1e592ae6cc95f22ba526dfcf0e5604657a568a41763fd1f0004b602",
"pubkey": "3eafe36fd5c9da060b55b0ae63f411957df72639dfcdff38f27b5ebb8d77d519",
"created_at": 1686316003,
"kind": 1,
"tags": [
[
"e",
"6a5589f16920b8050a7e35ab8671473050911a7e03b9f3eb8c97a8055ee89443",
"",
"root"
],
[
"e",
"e2fa58680846decedc485defa578410e4adad2ed633c4960e129b0ce00ceaffd",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "đź“… Original date posted:2022-08-31\nđź“ť Original message:\nHi folks,\n\nI think I've seen wallets supporting \"send max\" when a zero-amount invoice\nwas used. So isn't it a problem with the custodial service not supporting\nit?\nWhatever idea we figure out they can just refuse to implement it so we\ncan't force them into improving and being custodial they could steal\nalready, so that shouldn't be an issue.\n\nHave a nice day!\nMartin\n\nOn Sat, 27 Aug 2022 at 04:06, ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good morning Rene,\n\u003e\n\u003e \u003e Dear fellow Lightning Developers,\n\u003e \u003e\n\u003e \u003e I was recently on an event where the visitors have been gifted 10k sats\n\u003e on a custodial wallet. They could spend those sats via some web interface\n\u003e and an NFC card. During the event I was contacted by several plebs who were\n\u003e confused about one particular thing:\n\u003e \u003e It was impossible for them to withdraw the full amount from the service.\n\u003e \u003e\n\u003e \u003e Pasting an invoice for 10k sats would not work as the custodial service\n\u003e required a fee budget of 1%. However if people submitted an invoice for\n\u003e 9900 sats the remaining 100 sats were usually not fully required for the\n\u003e fees. Thus the users may have had a leftover of for example 67 sats. Now\n\u003e the problem repeated on the residual amount. While some services seem to\n\u003e have a drain feature for such a situation I find this frustrating and was\n\u003e wondering if we could help directly on a protocol level.\n\u003e \u003e\n\u003e \u003e Here is my proposal for a simple solution to this specific problem:\n\u003e `option_recipient_pays_routing_fees`\n\u003e \u003e\n\u003e \u003e This would be a new flag in invoices signaling that the recipient is\n\u003e willing to pay for the routing fees by releasing the preimage even if the\n\u003e full amount has not been arrived in htlcs at the recipient.\n\u003e \u003e\n\u003e \u003e So the workflow would be the following:\n\u003e \u003e\n\u003e \u003e 1. Alice creates an invoice for 10k sats setting the\n\u003e `option_recipient_pays_routing_fees` flag in the invoice and passes it\n\u003e either to custodial user Bob or to her own custodial account.\n\u003e \u003e 2. The payer parses the invoice and searches for a payment path or\n\u003e payment flow to Alice.\n\u003e \u003e 3. Because `option_recipient_pays_routing_fee` is set, the onion is not\n\u003e constructed in a way that the final HTLC will be for the amount of 10k sats\n\u003e but rather in a way that the first htlc will be for 10k sats and the\n\u003e following HTLCs will be of decreasing value so that routing nodes are\n\u003e compensated properly.\n\u003e \u003e 4. When the HTLC(s) arrive at Alice she will release the preimage if and\n\u003e only if not too many sats (e.g. 1% of the amount) are missing. Of course it\n\u003e would be good if the 1% was not hard coded in the protocol / software but\n\u003e configurable by Alice at the time of invoice creation.\n\u003e \u003e\n\u003e \u003e I think the main issue with this proposal is that instead of confusing\n\u003e users who wish to drain an account we may now have to educate users about\n\u003e two different invoice types. On the other hand I think this can probably\n\u003e easily be achieved via the current wide spread user interfaces. Of course\n\u003e it may be nice to have folks from the Bitcoin Design community to join this\n\u003e specific part of the discussion.\n\u003e\n\u003e In theory, trampoline routes / whatever-the-cool-name-is-now should fix\n\u003e this problem as well.\n\u003e I am referring to that scheme where the invoice contains an onion and a\n\u003e \"trampoline\" node that is the only node that can decrypt the first layer of\n\u003e the onion.\n\u003e The sender then has to route to the trampoline node, and the trampoline\n\u003e node then receives the rest of the onion.\n\u003e\n\u003e In this scheme, the receiver provides an encrypted route from some node to\n\u003e itself.\n\u003e As the receiver provides the route in order to gain privacy from the\n\u003e sender, the onus is on the receiver to deduct the fees from its received\n\u003e funds.\n\u003e i.e. the sender is only responsible for paying for fees up to the entry\n\u003e point of the trampoline.\n\u003e\n\u003e Thus, such a drain requirement simply means that the custodial service has\n\u003e to give its node ID.\n\u003e Then the receiver finds a route from the custodial service to itself, and\n\u003e encodes that in the trampoline onion, with a direct neighbor of the\n\u003e custodial service node as the trampoline.\n\u003e The custodial service then does not care about any fees as the receiver\n\u003e decided the route; the receiver knows exactly how much to expect (since it\n\u003e calculated the route).\n\u003e\n\u003e\n\u003e Of course, it is also possible as you propose, but any level-1-selfish\n\u003e custodial service will then always keep the remaining fee budget and always\n\u003e ensure that the receiver gets 99% of the value (or 100% -\n\u003e whatever_setting_they_chose), paying fees, and keeping the remaining 1% for\n\u003e itself.\n\u003e The receiver in this case cannot audit the route anyway, and thus cannot\n\u003e determine how much the true fees are; whereas in the trampoline case the\n\u003e route is specifically selected by the receiver.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220831/26c6eb67/attachment.html\u003e",
"sig": "036bfa669e3296e241fbfd49655755093da27e623ef9e2356ce15d75e2c401720c9ca65c5599d4270d92ce68683a5446dc8308c3d49a1b8754d87362cff793bb"
}