Specify CoinJoin output size

[alecov]

Is it possible to specify a specific UTXO result for CoinJoin?

1. I don't want 0.00005 UTXOs or similar. It's dust.
2. I do want a specific large output and am willing to wait more for this.

Tiny UTXOs should be disabled, really. Today, 5000 sats is about one dollar. It'll cost a heft to even spend this kind of output, it's a waste.

[yahiheb]

No that is not possible.
Such tiny UTXOs could be useful to find solutions to make a transaction without getting change back when sending bitcoin (Change Avoidance feature)

[Kruwed]

Both these functions are available using the WabiSabi coinjoin plugin for BTCPay Server, but they are not yet available in Wasabi Wallet. You can choose the minimum output denomination, and you can specify a large output by created a batch payment that spends to your own address.

[alecov]

This is exactly what I originally envisioned, I wonder if (or when) it will be available on Wasabi.

[turbolay]

Tiny UTXOs should be disabled, really. Today, 5000 sats is about one dollar. It'll cost a heft to even spend this kind of output, it's a waste.

It is not as straightforward as "disable and save money". If we disable 5000 sats denominations (which BTW the client already does if it costs more to create + spend them than their value), what would the decomposition look like if you have, let's say, 900 005 000 sats as total inputs (after fees)?
Note that this is a really simplified example, but the client could either:

1. Create nine 1 BTC outputs + one of 5000 sats
2. Create nine 1 BTC outputs and give the 5000 sats to the miners
3. Create eight 1 BTC outputs + one of 1 BTC 5000 sats.

Case 1 is easy, you will probably gain a lot of AnonScore on all your outputs. Therefore, you will maybe not have to remix, or at least not a lot, to reach your privacy target.

Case 2 is already what clients are doing. The amount they are willing to lose that way is: Max(5000, cost to create + spent an UTXO). Even if 1 sat is saved by creating this UTXO, you (or at least some users) would want to save this sat instead of giving it away to miners.

In Case 3, you will have an output of non-standard denomination, whom AnonScore will stay the same, and even worse, risks being sanctioned and reset to 1, which would be really harmful if you have a high privacy target and already did a good amount of mixes on this coin. You WILL have to remix this coin, so this will already cost money, but the coin selector for coinjoin will also include in the mix coins with higher privacy. But, we compute the AnonScore of outputs as the weighted average of the AnonScore of inputs. Therefore, the non-standard output that was created in the previous round will have an impact on the AnonScore gain dynamics for many of your other coins. You will need more remixes, and so it will cost more money.

So you see, not creating small outputs can, in fact, have hidden costs, which is the reason why the amount decomposer creates them. On the other hand, I agree that we should have some sort of options to prefer more aggressive consolidation rather than crumbling (creating many small coins). The AmountDecomposer already does that, but probably it could be more aggressive. There are also privacy implications here: the decomposition cannot be too deterministic, otherwise, demixing would be a bigger risk.

One final note: Batching Payment into CoinJoin is slowly but surely being pushed into the codebase, which would allow you to do basically what you want: manually choose your output denomination.

I hope that my explanation was not too overwhelming and would shed some light on why clients can sometimes create such UTXOs.

[alecov]

It is not as straightforward as "disable and save money".

Indeed. On second thought, my comment on outright disabling dust was poorly thought about; @yahiheb is also right on the change avoidance aspect.

On the other hand, I agree that we should have some sort of options to prefer more aggressive consolidation rather than crumbling (creating many small coins).

Yes, this is the main issue. Wasabi is such a high-end piece of software that users will expect a more granular level of control. For example, some users might know details on certain future payments and thus can help set what kind of UTXOs he should have. I presume this can ultimately augment privacy by avoiding excess consolidations or change generation.

Related to this, other useful features are payment for multiple addresses (which I believe will be implemented) and setting fee to a specific sat count (instead of sat/vB), both of which provide more control on eg. change generation (or forfeiting).

Your latter point about mixing determinism undermining privacy is also very interesting and non-obvious at first sight, although I believe the user should still be able to decide minimally on what kind of UTXOs he expects, privacy consequences being "caveat emptor".

One final note: Batching Payment into CoinJoin is slowly but surely being pushed into the codebase, which would allow you to do basically what you want: manually choose your output denomination.

That is so good. Thanks for the team on putting effort on this.

I hope that my explanation was not too overwhelming and would shed some light on why clients can sometimes create such UTXOs.

Not at all overwhelming and outright clear. Thanks for the thorough explanation.