Add consolidate_wallet argument to fund* RPCs #24795

1. 
   t-bast commented at 9:42 am on April 7, 2022: contributor

   I’m creating this issue to chase some concept ACKs. If this looks like a good idea to some people (other than myself), I’ll actually go ahead and implement it myself.

   Coin selection has a mode where it actively tries to consolidate small utxos into a bigger one. This is generally a good thing, but in L2 scenarios you don’t want to consolidate too aggressively, because having a pool of small utxos is useful for fee-bumping.

   This mode activates based on a start-up flag (consolidatefeerate, by default 10 sat/vbyte): if the current feerate is below this value, bitcoind will perform utxo consolidation when the user funds transactions. We’ve seen long periods of time where the feerate stayed below this value, effectively making utxo consolidation the default behavior. From an L2 application’s perspective, I’d like to keep a pool of small utxos, and only consolidate when it becomes too big. Using a start-up flag makes this quite hard.

   My proposal is to introduce a new RPC argument to all the funding RPCs: consolidate_wallet (or consolidate_utxos, whatever name you feel makes more sense). This would give more freedom to applications to choose when wallet consolidation should happen. The downside is that it’s yet another RPC argument. Do you think this is acceptable? @achow101 @Xekyo

2. t-bast added the label Feature on Apr 7, 2022
3. fanquake added the label Brainstorming on Apr 7, 2022
4. fanquake added the label Wallet on Apr 7, 2022
5. 
   murchandamus commented at 4:18 pm on April 14, 2022: contributor

   I think that it may be interesting to maintain a minimum count of UTXOs for wallets with sufficient funds also from a privacy perspective: having all of your funds get consolidated into a very low count of UTXOs would converge all of your transaction histories and reveals to counterparties a larger part of the wallet’s total funds when transacting. Perhaps it would be good to map out the problem space that we’re trying to address a bit more before we talk about the concrete solution, but an idea would be to automatically lower the consolidatefeerate for wallets with a lower UTXO count.
6. 
   t-bast commented at 5:46 pm on April 14, 2022: contributor

   I agree, I believe it makes sense as default behavior for everyone.

   The benefits I see of keeping a utxo pool:

   • fee bumping
     • this is very important for L2 contracts
     • but it’s not as important for L1-only users who will only infrequently need to fee-bump
   • initiating multiple multi-party contracts in parallel (could be vaults, dual-funded lightning channels, payment pools, etc)
     • multi-party contracts require a negotiation phase where you’ll commit some of your utxos
     • you cannot use these utxos elsewhere until the contract is either fully committed or aborted
     • this use-case is also not important for L1-only users
   • more opportunities to send payments that won’t need a change output
   • privacy
     • this is important for everyone

   The drawbacks:

   • more costly: when you actually need to send payments, you’ll use more inputs so the tx size is larger than if you had consolidated earlier when the feerate was low
   • (unsure about that) potentially harder to restore?
   • (unsure about that) potentially less performant?

   I don’t think we need to aim for something very accurate (e.g. trying to always have N utxos available with a value between X and Y), that would be too hard to manage and probably wouldn’t really be necessary to address user needs.

   We should aim for very simple knobs that users may configure, for example something like utxo-pool-size = [small, medium, large] and then internally tweak the consolidatefeerate to follow the user’s configuration as much as possible. Another possibility is to define a list of profiles (e.g. pocket-money / multi-party-contracts / life-savings) and map that to a utxo pooling behavior: that would work well if we’re able to identify the different profiles that make sense and in what way they require a different behavior. What’s interesting with that approach is that new profiles can be added in the future as they are identified.

7. 
   willcl-ark commented at 3:27 pm on April 10, 2024: contributor

   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.
8. willcl-ark closed this on Apr 10, 2024

   ---

Contributors
t-bast murchandamus willcl-ark

Labels
Feature Brainstorming Wallet