Félix-Antoine Paradis [ARCHIVE] on Nostr: 📅 Original date posted:2019-01-15 📝 Original message: Good morning! Excellent ...
📅 Original date posted:2019-01-15
📝 Original message:
Good morning!
Excellent point. I would like to add that on a UX perspective, I would be a
lot more worried about having a well connected node with well
funded/balanced channels.
You can always refuse to pay a lesser invoice but having to wait for a new
channel might be a deal breaker.
Deducting routing fees is also important in my view.
Felix
On Tue, Jan 15, 2019 at 7:14 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Francis and list,
>
> Not directly related to the original question, but I would like to bring
> up the issue of routing fees in such custodial cases.
>
> In your original post:
>
> > But for LN payouts (e.g. withdrawal from an exchange or a poker site),
> the Sender is the services provider, and it is the Sender who will be
> creating (most likely programatically) the terms of the payment.
>
> The issue is: when paying the user-provided invoice, does the Sender in
> this case deduct also the routing fee from the user account or not?
>
> One possible attack on a custodial service is:
>
> 1. Acquire 1.0BTC in the custodial service (purchase by fiat, or simple
> send via Lightning, etc.).
> 2. Create 100,000,000 invoices of 1 satoshi each on a node the attacker
> controls.
> 3. Have the custodial service pay to the invoices.
>
> Paying 1-satoshi invoices will tend to lead to fees approximately equal,
> or even greater to, the invoice amount.
>
> This is of course trivially fixable by imposing either a withdrawal limit
> (number of invoices that can be paid in a day) or a minimum withdrawal
> amount.
> There is some degradation of service, but reasonable defaults (100
> withdrawal invoices per day) could still be useful for typical usage.
>
> Alternately, the custodial service may deduct the routing fees from the
> account of the user.
> However, this latter solution is also undesirable in general, as routes
> (and thus fees) are controlled and selected by the sender, and in this case
> the user is the receiver, not the sender.
>
> The custodial service can very easily lie about routing fees; even if the
> user demands a report of the route, nodes along the route are allowed to
> change their routing fees at any time, thus the route information is
> potentially stale as soon as it is finalized and reported.
> The custodial service might secretly control particular nodes on the
> network and bias the routefinding algorithm towards those nodes even if
> those nodes charge high fees.
>
> Overall, however, such issues are minimal.
> Custodial services cannot be trusted to hold substantial money safely for
> long anyway, so any UX problems with them are largely immaterial.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190115/d8326de4/attachment.html>;
📝 Original message:
Good morning!
Excellent point. I would like to add that on a UX perspective, I would be a
lot more worried about having a well connected node with well
funded/balanced channels.
You can always refuse to pay a lesser invoice but having to wait for a new
channel might be a deal breaker.
Deducting routing fees is also important in my view.
Felix
On Tue, Jan 15, 2019 at 7:14 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Francis and list,
>
> Not directly related to the original question, but I would like to bring
> up the issue of routing fees in such custodial cases.
>
> In your original post:
>
> > But for LN payouts (e.g. withdrawal from an exchange or a poker site),
> the Sender is the services provider, and it is the Sender who will be
> creating (most likely programatically) the terms of the payment.
>
> The issue is: when paying the user-provided invoice, does the Sender in
> this case deduct also the routing fee from the user account or not?
>
> One possible attack on a custodial service is:
>
> 1. Acquire 1.0BTC in the custodial service (purchase by fiat, or simple
> send via Lightning, etc.).
> 2. Create 100,000,000 invoices of 1 satoshi each on a node the attacker
> controls.
> 3. Have the custodial service pay to the invoices.
>
> Paying 1-satoshi invoices will tend to lead to fees approximately equal,
> or even greater to, the invoice amount.
>
> This is of course trivially fixable by imposing either a withdrawal limit
> (number of invoices that can be paid in a day) or a minimum withdrawal
> amount.
> There is some degradation of service, but reasonable defaults (100
> withdrawal invoices per day) could still be useful for typical usage.
>
> Alternately, the custodial service may deduct the routing fees from the
> account of the user.
> However, this latter solution is also undesirable in general, as routes
> (and thus fees) are controlled and selected by the sender, and in this case
> the user is the receiver, not the sender.
>
> The custodial service can very easily lie about routing fees; even if the
> user demands a report of the route, nodes along the route are allowed to
> change their routing fees at any time, thus the route information is
> potentially stale as soon as it is finalized and reported.
> The custodial service might secretly control particular nodes on the
> network and bias the routefinding algorithm towards those nodes even if
> those nodes charge high fees.
>
> Overall, however, such issues are minimal.
> Custodial services cannot be trusted to hold substantial money safely for
> long anyway, so any UX problems with them are largely immaterial.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190115/d8326de4/attachment.html>;