Because when we have very many inputs, it makes sense to split the users based on a second criteria. This could be either for input values, or for sats/vbyte fee rate.
Currently we split based on input values, because it results in two transactions with more homogeneouty, the whales coinjoin with whales, and plebs coinjoin with plebs.
Oh, that makes sense. So 400 is just an arbitrary number that is rooted in the amount of UTXOs registered in a coinjoin round on average? If there are generally more users it would make sense to raise the number as well?
Yes, it's one of many variables in the backend configuration file.
In general, larger coinjoins is better, but there are at some point diminishing marginal returns of an additional input.
Bitcoin Core has a mempool standarness policy which limits transactions to 100kvB, that's around 600 inputs and 600 outputs. Larger transactions are still valid when they are in a block, but they don't get releayed as unconfirmed transactions by the default node configuration.
[code here: https://github.com/bitcoin/bitcoin/blob/v24.0/src/policy/policy.cpp#L101 ]
The reason is, that building an optimal block template with very large transactions is computationally very expensive, it's faster to do it with more but smaller transactions. And for mining decentralization, the speed of block template construction is insanely important.
Ontop of that, the more inputs, the higher the likely hood of one of them failing to sign, thus disrupting the coinjoin process.
Thats at least the intuition, but in some analysis the failure rate of +350 input rounds is roughly the same as for 250+ inputs, so maybe this isn't even a serious scaling issue.
Really interesting insights, thanks for sharing! đŸ’¯
