Depends on #7518.
Currently there is a dynamic/minimum fee determination when the transaction is constructed.
This PR adds the fee option to fundrawtransaction for when the caller wants to specify an already determined fee by other means.
Note that this is rebased with #7518 so only consider the last commit.
Will add tests when this is considered acceptable.
Concept ACK. The RBF feebump command requires a similar change.
Strict flag forces type check on all object keys.
Wouldn't feerate make more sense to specify, since presumably you don't know how big the transaction will be?
I agree that feerate makes more sense. When you're calling fundrawtransaction, you don't know what the final inputs (and sometimes outputs) will be, or you wouldn't be calling it.
Suppose the use case where the fee was estimated, rounded, displayed and accepted by the user. I just want to honour that value. If it is not enough then if fails, but if it succeeds then its added to the block reward.
I'm aware of transaction size and all, but at the end I just need to fund the requested fee.
@promag: how about using CoinControls nMinimumTotalFee for that purpose?
As I said, I have to honour that value and still use the unspent selection algorithm. There is no nMaximumTotalFee otherwise I would be happy.
Unless you (all) agree on adding nMaximumTotalFee and fail if it's not enough.
We try to avoid absolute fees on the API, because they make it easy to accidentally post a transaction with too little (or too much) fee. Especially for a call like fundrawtransaction, where, as said by @sdaftuar and @sipa, the final size of the transaction is not yet known. A fee rate would be better IMO.
If it is not enough then if fails, but if it succeeds then its added to the block reward.\ If it is not enough then if fails, but if it succeeds then its added to the block reward.**
But when would it fail? You mean when it would be rejected by local mempool policy (note that this can vary quite much over time)?
@laanwj nMaximumTotalFee would be added to CCoinControl and only used in CWallet::CreateTransaction. This is useful for services depending on bitcoind wishing to create transactions and have control of the final fee.
Edit: This is not related to the mempool policy as it remains the same and it is a different subject.
I still don't see the point. Why would you specify a maximum fee instead of a fee-rate? Before calling fundrawtransaction you don't know how large the transaction is going to be, and miners judge fee-rate (fee/KB), not total fee, so it's easy to get a transaction stuck this way.
Agree with @laanwj. Even though we have a -maxtxfee as some upper bound which ideally should never trigger, adding something like this as an option to fundraw does not make sense. You can look at the transaction later to find out the total fee and discard it/do other things if you don't like the fee amount.
You can look at the transaction later to find out the total fee and discard it/do other things if you don't like the fee amount
Right, that's one of the things you get for free with using a multi-step process instead of a single sendtoaddress.
Imagine there are lots of small unspents that if used causes the total fee to increase. If lockUnspent option is true and fee exceeds the max fee then no locking would occur.
Regardless of maxFee, I believe exposing the minFee (of CCoinControl) and allowing to override nTxConfirmTarget is acceptable?
Needs rebase.
I'm going forward with maxfee.
Closing this due to inactivity, no reply from author in a month. Feel free to ping me if you're starting work on this again then I'll reopen.
Related: #7967 ([merged] [RPC] add feerate option to fundrawtransaction)