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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
