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! 💯
