Payee Pay Fee

Lightning Network is currently starting to build up, it has recently passed 2 Million dollars in capacity, but its still far from being perfect, there’s currently very little ways of assessing how much fees a payer will pay, although its currently mostly a negligible value, it may not be in the future.

A use case of the Payee paying the fees of the transaction is used in almost every exchange platform, because on the main blockchain you can assess the current average fees and even figure out how much, on average, it will take your payment to be accepted by the network if you sent it with a definite amount, this currently does not exist in Lightning.

If the payee pays the fees the payer can route the payment towards complicit nodes that charge way higher fees than average.

This use case is important and so there were different suggestions on the Lightning-dev mailing list to solve this problem, one of which was proposed by LN developer ZmnSCPxj. The payee is to provide one or more complete paths from the payer to the payee node as fully encrypted onions, this benefits the payee by knowing exactly how much in fees he is expected to lose, the payer cannot correlate a particular user with its LN node and the payer cannot bias the route towards the complicit nodes we talked about.

The problem with this is that a standard for transporting these encrypted onions needs to be enforced and implementations need to provide a method for providing multiple routes from the payee to the payer.

Another, much simpler, suggestion was proposed by Cezary Dziemian and edited by ZmnSCPxj, the payee is to provide a fee limit along with the invoice, this can be a percentage or an absolute amount and the payer has to find a route that does not exceed this limit, an additional field could be added to the BOLT11 spec for this. This provides an economic compromise as the payer could fairly find a route and send the true invoice value and some other payer could always subtract the limit provided, even if the route itself takes less fees.

Support us and the authors of this article by donating to the following address:

3HzpoDbsd4w1t9qiuUrMp8wppNRFyCW4tL

Comments powered by Talkyard.