Split coordinator liquidity pool for fees

[Kruwed]

Feature request: The coordinator creates one type of round designed for impatient users who need immediate transactions, and one type of round designed for patient users who want the most amount of privacy for the amount they pay in fees. The acknowledged downside is that overall round coordination speed will drop by splitting the liquidity pool into two round types, but IMO we have enough overall liquidity to allow this.

---

Discussed in a meeting with @BTCparadigm , my observation is that it is not possible to optimize the tradeoff of coordinator feerates for a "default user" because user behavior skews towards one extreme or the other: No users ever need to wait a "medium" amount of time, they either need their coins to spend right away, or they don't need to spend them at all.

Therefore, the coordinator should offer pools that are specifically designed to accommodate these users, since them sharing the same coinjoin either leads to one person waiting too long, or one person paying too much. There are two variables than can be adjusted by the coordinator and one variable that can be adjusted by the client to optimize these rounds:

• Minimum input count required to start the round (coordinator side)
• Mining fee required to participate in the round (coordinator side)
• Maximum amount of inputs a user is allowed to register to a single round (client side)

Here's a plausible example of the variables for each of the two pools:

"Speedy business" pool

• 150 minimum inputs
• Target confirmation blocks: 36
• Max inputs allowed by client: 15

"Patient privacy" pool

• 200 minimum inputs
• Target confirmation blocks: 96
• Max inputs allowed by client: 10

In the speedy business pool, rounds will be created faster due to the lower minimum input threshold and due to clients registering more inputs on average. Rounds will confirm faster due to the higher mining fee, keeping remix liquidity constantly available. This is especially useful for people making payments in coinjoins (#10570)

With the patient privacy pool, the bigger rounds are more private than smaller rounds, so waiting to participate in a big round is better if you want to gain the most anon score for the total amount you spend in fees. The acknowledged downside is that this will also cause rounds to fail more frequently, and it will take longer to get 200 registrations than 150 registrations. However, if users are already prepared to wait 12 hours, 24 hours, or even a week for their transaction to get mined under current circumstances, adding an extra hour or two for successfully coordinating the transaction with a higher input count seems worth it. Since there is a lower amount of max inputs allowed by clients, this means there are going to be more individual users in the round, which is better for privacy as well: There is an assumed minimum of 10 participants in the speedy pool (150/15) and minimum of 20 participants in the privacy pool (200/10).

UX/UI:

-The default pool should be "Patient Privacy" since autocoinjoin is on by default, so users are offered the "best deal" initially and can opt in to the "premium rate".
-The pool options are somewhat complex when considered as an addition to the 3 profile setup we currently have (Minimize costs, Maximize speed, Maximize privacy) since it combines some aspects of each profile, and does not consider the anon score target of the user or their hours/days/weeks/months median fee tolerance.
-Users should be able to switch between pools, I cannot think of any privacy downsides for doing so.
-Putting this switch in the music box makes the most sense. This switch should be accompanied by a box showing the fee required by the coordinator in the last round broadcast from each pool.

Downsides:

-This will prevent extra large 300+ input rounds from being created as frequently since each pool will often start their rounds at the 150 or 200 minimum. However, previous pending coinjoins tend to confirm in the same block as one another, or within a few blocks of another, so these large input rounds still occur naturally when this leads to a quick increase in remixing liquidity.
-Multiple pool support is an integration issue for BTCPay, Trezor

[Kruwed]

Inscriptions & their markets have led to a very stable and predictable minimum fee rate persisting in the mempool, making this feature proposal mostly useless.