Add a greedy coin selection option #9870

Now with bitcoin fees are getting rather pretty painful, it'd be nice to have a greedy option for coin selection. This has the obvious implication of bloating the wallets unspent outputs, but that's something that can be resolved in a different way (e.g. sweep the wallet when there's not much fee pressure).

Adding a greedy option is a surprisingly non-invasive change: https://github.com/RHavar/bitcoin/commit/0f42b19f786eb688afc7790d087c08e4859ccb97

With of course the required pluming around it

Can you define greedy?

Oh, sorry. Greedy as in it greedily picks a big-enough output immediately, instead of trying to clean up your wallet at the same time.

If I'm trying to sending X bitcoin, the current algorithm first filters for all unspent outputs that are < X BTC and then tries to use a subset of them to create the transaction. This has the benefit of when you send bitcoin, you're generally cleaning up the wallet at the same time.

This used to be a good idea, but I'm not so sure anymore (at least for a large bitcoin user). For me to get transactions through "on peak" was costing ~150 sat/byte, yet I am able to clean up my wallet for <10 sat/byte on the weekend.

So the idea of a greedy option is to decouple this. I don't want my wallet cleaned up "on peak" and would rather use as few inputs as possible.

Wouldn't it just be better to define the proposed algorithm addition/change as "fee-optimizing rather than utxo-optimizing"?

A "greedy" matching algorithm is one approach to that problem, but definitely not definitive and seems to detract from what you're actually trying to introduce as a feature.

I'm not really sure. Maybe "greedy fee-optimization"?

I think "greedy" is important as that it only really optimizes for fees in the short-term but overall it likely would lead to more fees. (Unless you do something like me, and periodically clean up the wallet with low-fee transactions)

Improving coin selection is being discusses in #7664, let's focus the discussion there...

More recent discussion here: #12605

Let's continue discussion in #12605