Liquidity provider utxo management

[remyers]

@murch

I would agree that CoinGrinder and BnB would be more useful in your scenario than Knapsack and SRD. It might make sense to modify the sendmany RPC to allow restricting the coin selection to a subset of the coin selection algorithms or to patch out the calls to Knapsack and SRD from your node. Given that the post-processing of input set candidates is currently only based on the waste metric, It seems to me that you might want one call with the target consisting only of the liquidity transaction output, and if it doesn’t return a changeless solution, several calls with targets composed from the liquidity transaction output plus one or multiple of the amounts missing from buckets. Given the intent to refill the buckets, perhaps the latter calls should be restricted to the non-bucketed UTXOs.

I created a branch where I can set which algos are enabled. I have been running some simulations to compare using bnb+cg vs all algos. I’m using the same funding scenario file from my other tests, but none of the other changes related to targeting buckets.

Counter intuitively my initial tests showed all algos having slightly lower total fees and fewer median inputs than using only bnb+cg. I’m running more tests to try to figure out why.

@murch

Which brings me to the question, how would you distinguish non-bucketed and bucketed UTXOs? Would they be kept in separate wallets, separate amount ranges, marked in some manner?

I do not restrict which UTXOs coin selection can pick, except when refilling buckets I pre-select as an input the single “maximum value UTXO that is not in a bucket.” I use the bucket ranges preloaded from a json file to pre-filter the available coins based on if they are in a bucket or not.

That makes sense to initially try to select from UTXOs that are in a bucket to create a changeless transaction, but when that fails try to select from only non-bucketed UTXOs. This is related to suggestion 1.