Occasionally sending a transaction will result in a comically expensive amount of inputs being spent. Often this is totally unexpected, and the sender would have preferred to have instead have fallen back onto a different selection with less inputs or failing that have not make the transaction (until after they do some consolidation).
I propose there is an option "-maxInputs" that can be set by senders to force coin selection to never spend more that inputs.
Occasionally sending a transaction
Are we talking of GUI or RPC users?
My case is rpc, but I don't see why it wouldn't apply generally.
The ideal solution would be to control it on a per-transaction level, but a global -maxInputs config would be almost as useful. Imagine I have a wallet with a thousand inputs, and trying to make a payment. Creating a transaction that requires $500 of fees is pretty crazy, and definitely not what I want even if it was the best way to avoid change.
So you mean -maxtxfee?
Maybe! But it'd require a bit of changes to work.
I literally want to say: "I want to send X coins to Y and never spend more than Z coins". As if I need to spend more than Z coins, I would consider that my wallet needs defraging before I make the payment.
So I could emulate that by using -maxtxfee, but I run into two problems: Firstly it does not support dynamic adjustment which is essential when fee rates change. And the more pressing problem is that correct me if I'm wrong) the coin selection in unaware of it. So with an aggressive maxfee it will frequently create a coin selection that exceeds the -maxtxfee, and then in the final stage core will reject it for exceeding the maxtxfee.
If the coin selection itself was aware of the maxtxfee constraint, it could make a good effort at avoiding trying to create solutions that would violate it and instead say focus on larger inputs.
Have you considered fundrawtransaction in combination with listunspents?
I'm not sure that helps, unless you're suggesting I do coin selection myself? Which is definitely something I would rather avoid.
What is the problem of calling fundrawtransaction until the input count is less than your maximum and then sendrawtransaction?
I don't think that works. Let's say my maxInputCount I want to use is 3, and fundrawtransaction keeps finding a no-change solution that spends N inputs, no amount of polling fundrawtransaction is going to change that.
I think the concept of max inputs is (partially?) flawed. An input can have a large 7of7 multisig script (or any other large script) or a "lightweight" P2WPKH script.
I'm not sure what you want to achieve by purely limiting the amount of selected inputs. The (new) BnB coin selection is pretty efficient for most use cases.
If the internal coin selection is not efficient enough for your use-cases. Try what @promag suggests (manual coin selection) with fundrawtransaction or purely with createrawtransaction... or use CoinControl over the GUI.
Ok, maybe this is a bit too controversial. I'll close this issue, and create one about improving the existing maxtxfee