The intent was that mixes have a one-to-one correspondence to simple cycles. So, examples 1a and 1b induce two mixes, while 1c three mixes.
After thinking over the threat model, I'm tending to agree more with laurentmt's point, and my answer to your question is this:
Combining node-distjoint cycles of the same amount is not only a viable variation, but also has the advantage of larger anonymity size for that mix. Supposing the mix amount is equal, if I were to weigh the pros of a large single trxn versus that of two with a significant time difference, I'd favor the larger trxn.
Anyway, I think BVM cycling/splitting phase remains highly valuable (even for coinjoin) considering your objective to come up with a scalable solution.
Indeed, the "problem" of coinjoin is that it's subjected to 2 antagonist constraints:
1 - more players involved in the tx (more txins & txouts) is desirable for better privacy.
2 - txs are subjected to technical constraints (max number of txins & txouts) and organizational constraints (it's more likely that the signature of a coinjoin tx will fail if there's a lot of participants -1 rogue participant is enough-). These points make less participants quite desirable.
BCM cycling phase (or a variant) may be an adequate solution to "locally" maximize entropy and cope with (2) at the same time.
Thus in the case of coinjoin, may be this phase can be tweaked to produces subgraphs instead of simple cycles. These subgraphs should be as close as possible of a given pattern (with defined # txins & txouts).
Note : I don't know the best target values for # txins & txouts but I'm quite confident that people from the community are able to define them.
Open question : Is it desirable to introduce specific behaviours in BCM depending on the underlying primitive ?
WRT (1), chained coinjoins seem a straightforward solution (and already implemented in Darkcoin
)
Imho, it shouldn't be managed by BCM but by wallets which call multiple iterations of BCM according to rules defined by the wallet.
I think it's the solution implemented by Darkcoin wallets allowing users to select the number of iterations.
Main reasons I see for this:
- I don't think anybody has come up with an objective criteria defining what is the right number of iterations / desirable entropy (surely depending on the threat model as you pointed out)
- I may be wrong but this "chained txs" schema seems to me quite specific to coinjoin. Not sure others primitives have the same requirement.
laurentmt, this will help in the entropy analysis somewhat. Being that the # of cycles of the same flow amount is also a random variable, the size of the combined cycle is still too a RV.
It makes me think that it would be nice to have some stats from the blockchain about distributions of this kind of things. Added into my todo list.
EDIT: Removed assertion about how the cycling phase works. Seems wrong.