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
<[email protected]> 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
_______________________________________________
Lightning-dev mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
