[feature]: Add outpoints array to EstimateFee RPC

[michaelWuensch]

Is your feature request related to a problem? Please describe.

While outpoints can be set in SendCoins and OpenChannels, it cannot be set in EstimateFee.
Please add this functionality so proper fee estimations can be displayed for more sophisitcated transactions.

Describe the solution you'd like

Add an outpoints array to the estimate fee endpoint (https://lightning.engineering/api-docs/api/lnd/lightning/estimate-fee/) exactly like in SendCoins for example.

[guggero]

Since you are interested in the total fee amount required, an alternative approach for this would be to use the new CoinSelect parameter of the FundPsbt call (see example here:

lnd/itest/lnd_psbt_test.go

Line 1246 in 036a5a9

Template: &walletrpc.FundPsbtRequest_CoinSelect{

).
The PSBT based template you specify inputs you definitely want to spend and the main output to send to.
More inputs are added if necessary and a change output will either be added if needed or the excess amount can be added to an existing output.

[michaelWuensch]

@guggero Thanks for your suggestion. But using FundPsbt will also lock those UTXOs making them unavailable for the actual SendCoins endpoint I want to call afterwards.

Here in more detail what I try to achieve:
My goal is to have an excellent UX by providing an accurate fee estimation to the user BEFORE he performs an on-chain transaction. The fee estimation provider (lnd, mempool.space, etc.) is modular and interchangable.
Therefore I just need to know how big a transaction will be in vbytes.
So far I used EstimateFee RPC and calculated the size in vbytes using the returned response.
This approach does not work when selecting specific UTXOs or when using the sendAll flag as these options are not available in the EstimateFee RPC.

When going the PSBT route utxos will get locked all the time while the user crafts his transaction ( as I want to update the fee estimation on every change) which is a problem. Furthermore when changing everything to the psbt flow, I don't see an easy way to achieve something similar to the sendAll flag.

[guggero]

True, you don't automatically get sendAll functionality when using the FundPsbt flow. Unless you pass in all the UTXOs that are available from ListUnspent.

will also lock those UTXOs making them unavailable for the actual SendCoins endpoint I want to call afterwards.

The idea would be that you'd also use the FinalizePsbt/PublishTransaction RPCs to send the actual transaction. And if the user updates the inputs, you'd unlock and re-lock the new set.

IMO locking the inputs is actually a feature you should want. Otherwise if the user selects certain UTXOs and you don't lock them, how can you be sure they're still available once you call SendCoins? In theory there could be a sweep going on in the background that uses up one or more of those UTXOs.

So I'm in general a bit hesitant in adding a lot of features to some of the older RPCs, since maintaining them is a lot of work.
And I know that using the PSBT based APIs can be a bit more involved for developers, you generally get way more flexibility out of them once you know what's possible and how they are intended to be used.

[michaelWuensch]

Thanks for your comment.
You are probably right that going the full psbt route is the most flexible solution. This will be quite some work, but I'll try and see if I run into any problems.
Thanks again for your insights.