Check my write up about this -> So it started with a reply in the speculation thread, namely:
https://www.reddit.com/r/Monero/comments/3n06qw/there_seems_to_be_some_confusion_around_the/
Hello all,
I'm aware of the plans from the devs of Monero to ban 0 mixin transactions. These plans are well founded. (if you're unaware, please read MRL-0004).
But one thing I don't know is whether you intend to ban it as a consensus rule, or as a default behavior of the only implementation currently available? As in, simplewallet would no longer generate them, bitmonerod would no longer propagate them, but if a block appears with one, it would be accepted.
If you intent to block it in the default behavior, then please don't mind with this topic. Thank you for reading up to here. :)
Otherwise, I'd ask you to reconsider.
Consensus rules are tough to change once the project gains momentum, as we can see with Bitcoin. Having a hard-fork scheduling early on is no guarantee such schedule will be possible to remain in the future, actually it's quite likely not to happen if the coin gains large adoption. Default behaviors, OTOH, are much more flexible, and yet very powerful to shape a network. Take Bitcoin's dust rules, for example.
In the particular case of 0 mixin transactions, although I understand the problem they represent today, I'm sure there's a good chance some valid use cases for them to appear in the future. And if this future is too further on, it might become too difficult and overly political to change the consensus rules.
Two examples of valid use cases for no mixin I can think right now: multisig (insofar impossible with mixin) and child-pays-parent. The latter is the situation in which the receiver of a transaction wants to speed up its acceptance by adding fees to it. It would then create a new one spending the unconfirmed output he received, to another output of his own, but this time with larger fees. There's no need for mixin here: the link between the two transactions is clear, doesn't represent a privacy issue, and does not incur in cascade loss of privacy for others because the output will be "burned" in a 0 mixin even before it's confirmed. Nobody else would use it in their mixin.
Anyways, these are just two example, there might be others. My suggestion is: block 0 mixin by making it impossible to be generated and propagated by the default software. But if some block appears with a 0 mixin, let it stay. Just like Bitcoin handles dust. This would pretty much kill 0 mixin, without cementing a dangerous consensus rule. The less consensus rules we have, the better.