<div dir="ltr">Thanks for answer ZMNSCPxj,<br><br>Sad to hear that you have anything non LN-related to do that has higher priority.<br><br>What, can't this this be done in easier way? For example:<br><br>1. Payee provides fee limit along with with Invoice. This can be amount percentage or absolute value in msats. <br>2. Payer in order to pay just finds route, that do not exceed limit from invoice<br>3. Payer just pays invoice<br><br>Solution above do not solve all issues, but at least it is easy to implement and can be provided quite fast. I think, this is quite important, because right now I see a lot of services that just cover fee costs, what makes it easy to steal. I'm afraid that sooner or later someone will use this method to steal some funds, what undermines LN confidence.<br><br>Best regards,<br>Cezary Dziemian<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">pt., 15 lut 2019 o 06:40 ZmnSCPxj <<a href="mailto:ZmnSCPxj@protonmail.com">ZmnSCPxj@protonmail.com</a>> napisał(a):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Good morning Cezary,<br>
<br>
I have alluded to this issue before: <a href="https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001826.html" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-January/001826.html</a><br>
See "Withdrawing funds from a service".<br>
<br>
>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.<br>
These will be provided as fully encrypted onions to the payer, providing the following benefits:<br>
<br>
1. The payee knows exactly how much it will lose in fees, since it is the one providing the path.<br>
2. The payer cannot correlate a particular user with its LN node, improving privacy.<br>
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.<br>
<br>
The use-case is where the payer is a publicly-useable service (an exchange as you gave example to).<br>
In this case, the payer provides its node address to the user, but the user never provides its node address to the service.<br>
<br>
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.<br>
<br>
We need:<br>
<br>
1. Some standard of transporting multiple *encrypted* onions from the user (payee) to the service (payer).<br>
2. Some implementation must provide some method of generating multiple routes from the user (payee) to the service (payer).<br>
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.<br>
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).<br>
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).<br>
<br>
In essence, this issue shows the "other side" of merchants, which is exchanges.<br>
Current LN is biased towards merchants: the merchant exposes its node ID (on the invoice it provides to the user).<br>
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).<br>
<br>
Regards,<br>
ZmnSCPxj<br>
<br>
<br>
Sent with ProtonMail Secure Email.<br>
<br>
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br>
On Thursday, February 14, 2019 10:06 PM, Cezary Dziemian <<a href="mailto:cezary.dziemian@gmail.com" target="_blank">cezary.dziemian@gmail.com</a>> wrote:<br>
<br>
> Hi,<br>
> Not sure if this topic was mentioned, but is there any plan to provide payment solution in witch Payee pay fee instead of payer?<br>
><br>
> 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.<br>
> Did you discussed this before?<br>
> Best Regards,<br>
> Cezary Dziemian<br>
<br>
<br>
</blockquote></div>