Allow sending payment before fee estimation completes

[sangaman]

Description

A semi-recent feature with Zap is that when you go to pay an invoice, it first calculates and displays an estimated fee. While this calculation is happening, the UI "spins" and doesn't let you actually submit your payment request until the estimation completes. Often this can take a while, as I'm guessing Zap/lnd are querying routes and making rpc calls behind the scenes.

Rather than prevent the payment until this fee estimation is done, it would be nice to allow the user to submit the payment before the estimation is complete. Ultimately, the fee estimate is merely an estimate and the payment is constrained by the fee settings in Zap and lnd.

Context

The appeal of lightning payments is speed and convenience. It's slow and inconvenient to have to wait for fee estimation to complete, which often takes upwards of 5 seconds in my experience which is a long time when I'm trying to scan a QR code in person and a merchant is standing there waiting for the payment to come through.

Possible Implementation

Don't prevent the user from submitting a payment right away upon scanning a QR code or pasting an invoice.

[michaelWuensch]

Thanks for the issue.
I will consider it. But most likely it does not speed it up that much. When doing the fee estimation, it will actually do path finding. When sending, it actually uses the previously discovered path. So while you could hit send a little bit earlier, the sending process itself would take longer.

[sangaman]

If I undersrand correctly then, it's querying for a route and then trying to pay to that route? If the route fails, would it then have to start the process over or does lnd automatically try other routes if the provided route fails?

I might look into the code myself. All I know is that my experience recently across several payments to various recipients is that I have to wait much longer for the button to send the payment to become clickable (while fee is being estimated) than for the payment to actually complete once I press the button, which strikes me as counterintuitive. Maybe the QueryRoutes call is not very optimized or maybe it makes a deeper search through the network graph.

[michaelWuensch]

It is actually not querying a route using a query route command, it is doing a so called "payment probe". This is basically a complete payment but with faked payment hash. Therefore that payment will fail in the end, but we know afterwards a possible route and exactly what the fees are and display those fees to the user. We then use that information to construct a payment that will exactly take this route. Executing that payment is fast as no more route discovering has to be done.

I admit tough that this is not perfect user experience but I also would see it problematic to not being able to see the fees before you hit send.