Allow dynamically changing maxtxfee #14927

There should be an rpc method: setmaxtxfee to allow users to dynamically change the maxtxfee without resetting the wallet.

Justification: #14896 (comment)

Not sure if this is worth doing... maxtxfee to me is more of a sanity check against insane fee creation.

There are two ways of quickly generating transactions with RPC:

• sendtoaddress or sandmany (no fee control)

or:

• createrawtransaction [] {"address":<amount>}
• fundrawtransaction <hex> <options> (can define feerate, etc.)
• (can check fee)
• signrawtransaction <hex>
• sendrawtransaction <hex>

The problem with those methods is that you only have control of the feerate, but not the absolute amount of fees. However sometimes you want to make a payment, but only if you can do at a certain price (otherwise you'd rather wait, consolidate first or lower the feerate)

I see your use case... which eventually is an edge case. It is solvable with a simple logic:

• createrawtransaction [] {"address":<amount>}
• fundrawtransaction <hex> <options>
• check absolute fee (will be returned fundrawtransaction)
• Eventually check amount of inputs (decoderawtransaction(<hex>)[vin].size())
• "Execute" (sign/send) transaction or wait and do steps again

@jonasschnelli I agree it's possible to manually check the fee before broadcasting, but on account of there already being a maxtxfee setting, it would obviously be easier for a caller to use that.

But the real advantage of using the maxtxfee is that now the wallet is aware of our constraints, and can make an effort to work under them.

The constraint you where describing seems to be on a per-transaction basis.

I don't think using a global maxtxfee for a such use-case is wise. Since the usecase you describe if per transaction and per wallet basis, maxtxfee is global and will have affect on all wallets and all transactions.

Also, in general, users got really confused with absolute fees versus feerates. I think it's our duty to make people aware that transactions have different sizes (depending on the amount of inputs) and absolute fees is in general a flawed concept.

Yeah, on a per-transaction basis would be ideal. I just imagine it's a lot more work to add.

and can make an effort to work under them.

AFAICK it already tries to minimize the fee/input set. So when it hits that -maxtxfee check it's kind of pointless doing backtracking.

@promag I don't believe that's how the algorithm works at all. I believe it first it prioritizes creating transactions with no-change, and then failing that prioritizes minimizing the change output as opposed to minimizing the fees or input set.

BnB does actually minimize inputs. The waste metric increases as the number of inputs selected increases (assuming that the current feerate is higher than the long term fee rate which it usually is). Since the input set that meets the no-change target with the lowest waste metric is chosen, the input set with the fewest number of inputs will typically be chosen.

Also, minimizing the input set (equivalent to minimizing fees) is not a good algorithm. It will always end up choosing the the largest inputs first, which will result in the coins in your wallet being ground to dust. In the long run, coins will be ground to dust and thus cost a lot more to spend.

I think it's reasonable to add maxfee to fund transaction calls, in the same fashion as #14641?

Nervermind, just do what @jonasschnelli suggests above #14927 (comment).

@achow101 That's only true with a very restrictive set of assumptions.

If you receive a lot of transactions (are a merchant), you're going to have hundreds to thousands inputs in your wallet, which ideally should help the BnB find good solutions, but you absolutely don't want it (or the fall back) to generate a solution that costs hundreds of dollars. It'd be far preferable to minimize the input set if no reasonable (e.g. under the maxtxfee) solution could not be found, and then the wallet owner would consolidate those inputs.

In the long run, coins will be ground to dust and thus cost a lot more to spend.

That's only true if you assume transaction fees go up with time, but it's often exactly the opposite: most commercial users (especially merchants) periodically consolidate their inputs at a tiny fraction the feerate of when they generate normal transactions.

That's only true if you assume transaction fees go up with time

No it doesn't. Grinding to dust means you have lots of small inputs, so in order to reach a particular target value, you are using more inputs and thus paying higher fees.

but it's often exactly the opposite: most commercial users (especially merchants) periodically consolidate their inputs at a tiny fraction the feerate of when they generate normal transactions.

This is not an assumption we can make. We can't assume that users are going to consolidate their inputs. Not all users understand inputs and outputs and know to consolidate. Furthermore, most users of Bitcoin Core's wallet are not merchants. Those who are are likely not receiving that sort of transaction volume. Of the many companies involved in Bitcoin optech, all (or almost all) of them use their own coin selection implementation, not Bitcoin Core's.

This is not an assumption we can make. We can't assume that users are going to consolidate their inputs.

I understand that, and it's not an assumption that I'm asking core to make. I am just pointing it that out as justification for why being able to use a maxtxfee is actually useful.

The feature request didn't seem to attract much attention in the past. Also, the issue seems not important enough right now to keep it sitting around idle in the list of open issues.

Closing due to lack of interest. Pull requests with improvements are always welcome.