ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-02-15 📝 Original message: Good morning Cezary, I ...
📅 Original date posted:2019-02-15
📝 Original message:
Good morning Cezary,
I have alluded to this issue before: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001826.html
See "Withdrawing funds from a service".
>From my point-of-view, the proper solution would involve the payee providing one or more complete paths from the payer to the payee node.
These will be provided as fully encrypted onions to the payer, providing the following benefits:
1. The payee knows exactly how much it will lose in fees, since it is the one providing the path.
2. The payer cannot correlate a particular user with its LN node, improving privacy.
3. The payer cannot bias the route towards other nodes it controls that happen, completely for no good reason, to charge high LN fees; the payee generates the route and controls its fees.
The use-case is where the payer is a publicly-useable service (an exchange as you gave example to).
In this case, the payer provides its node address to the user, but the user never provides its node address to the service.
There is no spec yet, and I am too busy with other considerations to actually work on anything Lightning-related, but perhaps you can pick up this, and continue its development.
We need:
1. Some standard of transporting multiple *encrypted* onions from the user (payee) to the service (payer).
2. Some implementation must provide some method of generating multiple routes from the user (payee) to the service (payer).
Importantly, this must compute "forwards", i.e. a constant amount will be released by the payer, and the payee will take whatever value remains after fees.
This is more difficult than it seems due to how LN fees are computed, unfortunately (it is based on the outgoing amount; while mathematically it is possible to just manipulate the equations, in practice roundoffs will be different in some edge cases between the "backwards" and "forwards" methods).
In addition, the implementation needs to have some heuristic, i.e. if it finds a route that loses more than 1% of the value being paid (overrideable by the user), then it probably should reject that route and not provide it to the service (payer).
In essence, this issue shows the "other side" of merchants, which is exchanges.
Current LN is biased towards merchants: the merchant exposes its node ID (on the invoice it provides to the user).
For exchanges, we need to perform a dual transformation, where the exchange exposes its node ID somehow (via a mechanism that does not yet exist).
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, February 14, 2019 10:06 PM, Cezary Dziemian <cezary.dziemian at gmail.com> wrote:
> Hi,
> Not sure if this topic was mentioned, but is there any plan to provide payment solution in witch Payee pay fee instead of payer?
>
> The issue I found is on our exchange, when user can withdraw funds using LN. If we don't know fee in advance, he can't just withdraw everything what he has. We can assume, that he can withdraw up to 99,5% of his funds, but it would be nice, if he can just withdraw everything and what he receives is just his funds minus fee.
> Did you discussed this before?
> Best Regards,
> Cezary Dziemian
📝 Original message:
Good morning Cezary,
I have alluded to this issue before: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001826.html
See "Withdrawing funds from a service".
>From my point-of-view, the proper solution would involve the payee providing one or more complete paths from the payer to the payee node.
These will be provided as fully encrypted onions to the payer, providing the following benefits:
1. The payee knows exactly how much it will lose in fees, since it is the one providing the path.
2. The payer cannot correlate a particular user with its LN node, improving privacy.
3. The payer cannot bias the route towards other nodes it controls that happen, completely for no good reason, to charge high LN fees; the payee generates the route and controls its fees.
The use-case is where the payer is a publicly-useable service (an exchange as you gave example to).
In this case, the payer provides its node address to the user, but the user never provides its node address to the service.
There is no spec yet, and I am too busy with other considerations to actually work on anything Lightning-related, but perhaps you can pick up this, and continue its development.
We need:
1. Some standard of transporting multiple *encrypted* onions from the user (payee) to the service (payer).
2. Some implementation must provide some method of generating multiple routes from the user (payee) to the service (payer).
Importantly, this must compute "forwards", i.e. a constant amount will be released by the payer, and the payee will take whatever value remains after fees.
This is more difficult than it seems due to how LN fees are computed, unfortunately (it is based on the outgoing amount; while mathematically it is possible to just manipulate the equations, in practice roundoffs will be different in some edge cases between the "backwards" and "forwards" methods).
In addition, the implementation needs to have some heuristic, i.e. if it finds a route that loses more than 1% of the value being paid (overrideable by the user), then it probably should reject that route and not provide it to the service (payer).
In essence, this issue shows the "other side" of merchants, which is exchanges.
Current LN is biased towards merchants: the merchant exposes its node ID (on the invoice it provides to the user).
For exchanges, we need to perform a dual transformation, where the exchange exposes its node ID somehow (via a mechanism that does not yet exist).
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, February 14, 2019 10:06 PM, Cezary Dziemian <cezary.dziemian at gmail.com> wrote:
> Hi,
> Not sure if this topic was mentioned, but is there any plan to provide payment solution in witch Payee pay fee instead of payer?
>
> The issue I found is on our exchange, when user can withdraw funds using LN. If we don't know fee in advance, he can't just withdraw everything what he has. We can assume, that he can withdraw up to 99,5% of his funds, but it would be nice, if he can just withdraw everything and what he receives is just his funds minus fee.
> Did you discussed this before?
> Best Regards,
> Cezary Dziemian