Considerations for expanding coordinators allowed UTXO sizes.

[Transisto]

What are considerations for lowering the minimum UTXO sizes and allowing for custom lower limits?

A common size of "0.1 BTC" had to be used initially to favor large anonymity set focused at specific size.

As adoption increase a wider range of default sizes can be considered.

Fungibility can be increased by taking part in a large anonymity set coinjoin or participating in multiple coinjoin with a lower anonimity set over longer period of time.

The lower bound has to be low, not much higher than the monetary value of typical of an on-chain transactions (purchases/donations). That size has to not be too high as to increase transaction sizes disproportionately to total amount spent.

Highlighted here are the sizes I think should be considered for mid term expansion.

BTC	@6,000.00  $
0.000391	2.34  $
0.000781	4.69  $
0.001563	9.38  $
0.003125	18.75  $
0.00625	37.50  $
0.0125	75.00  $
0.025	150.00  $
0.05	300.00  $
0.1	600.00  $
0.2	1,200.00  $
0.4	2,400.00  $
0.8	4,800.00  $
1.6	9,600.00  $
3.2	19,200.00  $
6.4	38,400.00  $
12.8	76,800.00  $
25.6	153,600.00  $
51.2	307,200.00  $

An expansion plan could be done in steps to expand options while maintaining network effect via client defaults :

1. Allow client to instruct coordinator to limit a minimum size up to "0.8"
2. Keep default size to 0.1 but allow clients to participate with or select "MinSizeLimit" to one step lower. (0.05 BTC)

This assume that people limiting their min UTXO to participate in multiple 0.8 coinjoins are responsible enough to know that partaking in 10 consecutive CJ of 3 anonset is unlikely to be equivalent to a single 30 anon-set CJ.

https://github.com/zkSNACKs/WalletWasabi/issues/1322 https://github.com/zkSNACKs/WalletWasabi/issues/1238

[nopara73]

[Brainstorming]

Right now we do 0.1, 0.2, 0.4, ...

So if someone has 0.5, then he'll do 0.1, 0.2, and 0.3 change back.

As a first step we could turn this around and do 0.4, 0.2, 0.1.

So if someone has 0.5, then he'll do 0.4, 0.1 (and no change back - unreal example, but it illustrates the point.)

And then we could introduce lower amounts because that wouldn't mess with most of the peers.

However the question arises: is 10btc mix with 2 people better than 1btc mix with 100 people? Because the algorithm would result similar things.

IMO there could be an optimization, something like 102 and 1100, so the 1*100 would be chosen. Though it's an NP issue, but I guess we can hack around something there.

Allow client to instruct coordinator to limit a minimum size up to "0.8" Keep default size to 0.1 but allow clients to participate with or select "MinSizeLimit" to one step lower. (0.05 BTC)

Those fingerprint the client.

The sizes are good, IMO the lowest amount should be dynamically determined based on the current feerate target 2. I think the min amount should be at least 100 times larger than the fee of a 1 in 2 out tx with feerate of estimatesmartfee conservative 2.

[nopara73]

Aaah, smaller amounts would also ruin the DoS protection. https://github.com/nopara73/ZeroLink/#d-dos-attack