Explain why the presence of the 195 other outputs makes the second coinjoin less private than the first one.
It can be better understood if you compared a shorter coinjoin, which instead of 228 inputs, it'd have 6 (as in whirlpool), since we're talking about the case where most of these hundreds of inputs are disguised as anonymity set, but are maliciously added by the coordinator (which is theirs).
So, a 6 input, 6 output coinjoin with variable amounts would look like this:
0.50 BTC 0.50 BTC
0.40 BTC 0.40 BTC
0.30 BTC -> 0.30 BTC
0.20 BTC 0.20 BTC
0.10 BTC 0.10 BTC
0.05 BTC 0.05 BTC
Is there any probability that the input of 0.10 BTC can have created the 0.50 BTC output? No. The only ways to create the 0.50 TXO would be if one of the following conditions was true:
User owns: 0.50 TXI
User owns: 0.40 and 0.30 TXI
User owns: 0.40 and 0.20 TXI
User owns: 0.40 and 0.10 TXI
User owns: 0.30 and 0.20 TXI
Therefore, if we know beforehand that Alice controls only the 0.10 TXI, we could ignore certain outputs (in this case
all the other outputs). The only explanation would be that Alice controls the 0.10 TXO, because it is impossible that she could have created another output. Now, this, incidentally influences other people's privacy, as now it is evident that Bob (with his 0.50 TXI) cannot have created the 0.40 and 0.10 TXO.
Let's have a look on the whirlpool coinjoin: (rounding down to 0.50 BTC for each TXI),
0.50 BTC 0.50 BTC
0.50 BTC 0.50 BTC
0.50 BTC -> 0.50 BTC
0.50 BTC 0.50 BTC
0.50 BTC 0.50 BTC
0.50 BTC 0.50 BTC
What are the probabilities that each of the inputs created the TXO_0? All equal, 16.6%. Even if you employ blockchain analysis, and know with high degree of certainty that Alice controls only one of the inputs, the result is still the same. You could only know that Alice's TXO cannot be x, because x was consolidated with y (and we know that Alice does not control two inputs). To mitigate this issue, you only allow from your users to select only one of their UTXO to join the round. (Still does not completely protect against a malicious coordinator, but makes it more expensive, and complicated as consolidations from more rounds need to be taken into consideration and users can choose to remix indefinitely.)
It's not a strawman, if you are still unsatisfied with the client's detection system, why don't you simply ask your friend to join the same coinjoin round as you to verify there's no Sybil attack taking place?
I join, my coins pass the coordinator's approval, my friend's coins are refused. Why is this considered Sybil attack and it's not my friend's coins "naughty" according to blockchain analysis?