[Lightning-dev] Payee pay fee

ZmnSCPxj ZmnSCPxj at protonmail.com
Wed Feb 20 08:52:24 UTC 2019

Good morning Cezary,

> What, can't this this be done in easier way? For example:
> 1. Payee provides fee limit along with with Invoice. This can be amount percentage or absolute value in msats. 
> 2. Payer in order to pay just finds route, that do not exceed limit from invoice
> 3. Payer just pays invoice
> 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.

This is possible.
You could propose additional field in BOLT11 spec for this.

I would tweak this slightly.

It is currently allowed to pay more than an invoice value.
So a plausible proposal is:

1.  User of an exchange service decides withdrawn amount.
2.  User decides largest acceptable loss in LN fees.
3.  User computes: invoice_value = withdrawn_amount - max_ln_fees.
4.  In BOLT11, specify a new `withdrawn_amount` tag that signals that the service performing the payment should not spend more than the specified `withdrawn_amount`, and should deduct only the amount released by the service (the amount released, includes fees) from the user account.
    This is trust-based; but any custodial service is inherently trust-based anyway.
5.  A "good" service would overpay to the user, such that `withdrawn_amount` is exactly what it releases.
    Again, this computation is more complex than the current computation, as the LN BOLT spec currently specifies that fees are computed "backwards" from the value that the destination receives.
    A "not bad" service will just pay the `invoice_value` to the user and deduct `withdrawn_amount` always, and fail the withdrawal if it would release more than `withdrawn_amount`.
    A "bad" service will becomes the next MtGox.


More information about the Lightning-dev mailing list