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 
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.

Lightning-dev mailing list

Reply via email to