[FireProofing] Dynamic minimum output limit

[BTCparadigm]

Description

Add an automatically adjusting sanity check to the client, about what outputs are economically reasonable to create in coinjoin.
Remove uneconomical standard denominations from the possible ones, when transaction fee of creating that output denomination exceeds 30% of a Segwit v0 input cost, with the same fee rate.
In other words, the minimum output value must be at least 3.33 times the cost in fees required to create a single Segwit v0 input.

Put the leftovers to mining fees, because they are presumably small enough amounts compared to the total transaction fee.
Increase the current 10 000 sanity check limit to 49 999 sat or more, to prevent round disruptions.

Bold = debatable

Reasoning

Speed up transactions and make output selection stricter to not burn sats in vain.
The reasoning behind choosing Segwit v0 input as the basis, is that its the costliest, so its the best option if we want to avoid weird edge cases of cheaper base assumptions, and because we want to use this coin to pay people in the future, or to be otherwise useful.

Designs

Calculations

Taproot Input	Taproot Output	Segwit v0 Input	Segwit v0 output
57,5	43	68	31

Taproot in sats:

Fee rate sat/vbyte	Fee per Output	Minimum Output amount	Fee per Input	Minimum Output amount
1	43	143,2	57,5	191,5
5	215	716	287,5	957,4
10	430	1431,9	575	1914,8
50	2150	7159,5	2875	9573,8
100	4300	14319	4150	19147,5
200	8600	28638	8300	38295
400	17200	57276	16600	76590

Segwit v0 in sats:

Fee rate sat/vbyte	Fee per Output	Minimum Output amount	Fee per Input	Minimum Output amount
1	31	103,2	68	226,4
5	155	516,2	340	1132,2
10	310	1032,3	680	2264,4
50	1550	5161,5	3400	11322
100	3100	10323	6800	22644
200	6200	20646	13600	45288
400	12400	41292	27200	90576

30% of 5000 sats is 1500 sats, and it costs 1500 sats to create a Taproot output at 34.88 sats/vbyte.
If we assume the 30% magic number applies to inputs as well, it costs 69 vbytes for a segwitv0 input, so we could not register those 5000 sat amounts as inputs at a fee rate higher than 21.74 sat/vbyte.

Smallest denomination	Most willing to pay	Max round fee sat/vbyte
5000	1500	21,7391304
6561	1968,3	28,526087
8192	2457,6	35,6173913
10000	3000	43,4782609
13122	3936,6	57,0521739
16384	4915,2	71,2347826
19683	5904,9	85,5782609

Worst case Segwit v0 input and Taproot output:

Round fee rate	Cost to consume	Cost to create	Total participation cost
1	69	43	112
5	345	215	560
10	690	430	1120
50	3450	2150	5600
100	6900	4300	11200
200	13800	8600	22400
400	27600	17200	44800

5000 sats in % with worst case of Segwit v0 input and Taproot output:

Round fee rate	Cost % Input	Cost % Output	Cost % Total
1	1,38	0,86	2,24
5	6,9	4,3	11,2
10	13,8	8,6	22,4
50	69	43	112
100	138	86	224
200	276	172	448
400	552	344	896

[MaxHillebrand]

Just adding the small output to mining fee seems not great, we want to save the users money, not spend more of it.

Instead, the decomposer should find a solution that creates no small outputs.

[BTCparadigm]

Just adding the small output to mining fee seems not great, we want to save the users money, not spend more of it.

Instead, the decomposer should find a solution that creates no small outputs.

Yes, that's what I meant by "Remove uneconomical standard denominations from the possible ones".

[Transisto]

Seem safe to manually get rid of 5000s

[adamPetho]

IMO @turbolay has a serious concern about this, which shouldn't be overlooked:

if 90% of clients update but 10% don’t, the clients that don’t will be messed up twice in high fees:

• They will still create outputs making them to lose money
• These outputs won’t gain any privacy because all the other clients won’t create them anymore

Something to consider. We might gonna need the backend side fix, too.

[BTCparadigm]

if 90% of clients update but 10% don’t, the clients that don’t will be messed up twice in high fees:

They will still create outputs making them to lose money
These outputs won’t gain any privacy because all the other clients won’t create them anymore

Considered but as discussed with @turbolay, there's nothing we can do for old clients, other than to get them to update. Making all clients waste money just to provide privacy for the small outputs makes no sense.

We might gonna need the backend side fix, too.

Yes, at least we have to consider the coordinators minimum output amount and how it effects the coordinator fees.

[Transisto]

I don't see what's hard with the coordinator just not generating more of them and only merging them up.
Why would that need a client update? Isn't it the coordinator that decide what outputs will be generated?

[BTCparadigm]

I don't see what's hard with the coordinator just not generating more of them and only merging them up.

That's what it already does.

Why would that need a client update?

No, that's for server side stuff.

Isn't it the coordinator that decide what outputs will be generated?

For itself, yes.

I was talking about how coordinator cant charge coordinator fees if they are in total less than the minimum denomination.
For example, trying to charge 0.3% from 0.016 BTC is ~4,8k sats, which by itself is not an allowed output.

[BTCparadigm]

Just to put it out there, it doesn't really matter what we use as a basis or what is the percentage.
My example of 3.33 * SegWit v0 Input means making the minimum output equivalent of ~226 vBytes * sat fee rate.
From this it would lose at worse 68 vBytes * sat fee rate worth of value, by becoming an input in the next transaction, assuming tx fees stays the same, leaving ~158 vBytes * sat fee rate as movable value. Just to be clear, this is equivalent of (3.33 - 1) * SegWit v0 Input.
My point is, I guess we need to figure out how many vBytes worth of value are we hoping to carry at minimum.

The higher the minimum output denomination, the less small UTXOs users get.
This comes with a tradeoff of producing bigger leftover amounts that can't be decomposed without small denominations.
So, the higher the minimum output denomination, the higher amount a user is likely to lose to mining fees as leftovers.
Now the question is, where is the sweet spot?

Minimum output amount in vBytes	Value % carried as SegWit v0 Input	Value % carried as Taproot Input
75	110,29	130,43
87,5	128,68	152,17
100	147,06	173,91
112,5	165,44	195,65
125	183,82	217,39
137,5	202,21	239,13
150	220,59	260,87
162,5	238,97	282,61
175	257,35	304,35
187,5	275,74	326,09
200	294,12	347,83

The example calculations I've made in OP points that users would be willing to lose the same 3.33 * SegWit v0 Input - 1 sat (~226 vBytes) worth of value as leftovers in the worst case scenario, but it might be too much.

[nopara73]

As discussed previously, #10842 to some degree, but previous pull requests resolved this.