We present CoinShuffle, a completely decentralized protocol
that allows users to mix their coins with those of other interested users.
This implies a smaller anonymity set, as it requires interested users.
The unlinkability of transactions is protected as
long as at least any two participants in a run of the protocol are honest.
Less resources will be required to sybil attack, because of the smaller anonymity set. Also, sybil attacks will decrease the anonymization chances. If two out of 4 are sybils, then instead of a 25% random chance of being identified .. you now have a 50% chance .. and so on.
To the best of our knowledge, no fully anonymous and efficient solution has
been proposed to the best of our knowledge.
quoted for lols
Bitcoin users who wish to participate in a mixing protocol need a bootstrapping
mechanism to find each other, e.g., through a public bulletin board acting as
facilitator or through a peer-to-peer protocol specifically crafted for this purpose.
...
the participants must additionally agree on a channel for
further communication during bootstrapping. We consider bootstrapping to be
orthogonal to our work and assume that it is available to all Bitcoin users.
Weak link here. I almost thought they were joking .. but they weren't
This is where cryptonote would dominate .. this type of 'bootstrapping' is not necessary .. as the solution presented is inherent to the protocol. No effort on your end is required to perform an anonymous tx. The reason they don't consider this a goal is because they're trying to put the costs of performing it on you and your transactee .. while cryptonote does this for the standard tx fee that you also have to pay in BTC.
If after the mixing, a user
would like to spend the mixed coins associated with the output address while
maintaining her anonymity, she has to ensure that network metadata, e.g., her IP
address, does not reveal her identity or make the spending transaction linkable
to a run of the mixing protocol.
Monero will have i2p inherent to the protocol. While not perfect, this will block all but the strongest of adversaries from knowing your identity.
The shuffling provides robustness in the sense that attacks that aim to disrupt
the protocol can be detected by honest users and at least one misbehaving
participant can be identified and excluded.
The other participants can then run
the protocol again without the misbehaving participant.
I think it would be tough to identify a dishonest user and set up black/white lists using tor/i2p .. which without you would most likely be be able to identify the 'shufflers' outside of the protocol anyways .. making sybil attacks 100% effective no matter how many were sybil/real? Actually I think this is where masternodes have an edge over shuffling - because you can impose a fee on a sybil attacker. Again though, Monero offers transaction fees to prevent sybil attacks. Also, your transaction can't be linked because RS's, and soon to be unidentifiable through protocol i2p. Either way .. Monero doesn't have this problem (of failed transactions) because it's not using multisig to perform these mixes.
Hash Function.
CoinShuffle require a collision-resistant hash function H.
It looks like they've added ddos protection. Yay.
We further assume that every participant already knows the
verification keys of all other participants. All participants have already agreed
upon a fresh session identifier and an amount B of coins that they would
like to mix.
This isn't handled within shuffle protocol? This is seeming to sound pretty outdated ..
At the end of the blame phase, at least one misbehaving participant is identified
and excluded from the protocol.
...
It is worth noting that, whenever the blame phase is reached, the participants do
not construct a transaction that is accepted by the Bitcoin network.
reduces anonymity set by 1. Sybil concern - this is done for free.
If the malicious transaction is accepted, honest
parties do not lose their coins, but the mixing will have failed. Then, it might be
the case that a restart of the protocol is not possible because the participants
have already gone offline, in the belief that the protocol has been successful.
Basically ruins the DDOS protection. Just make a successful transaction, send out a double spend and then these people have transactions that don't go through ie: blocked transactions, unless people are okay with waiting for the network to reject the transaction .. but then they'd still have to do it all over again .. wastes time .. which can be wasted cheaply for BTC tx fee.
additional: the mixing type presented here does not allow proof of transactions on the blockchain. Cryptonote offers a view key, which can be used to verify permanently (without the wallet itself) the previous transactions of the wallet. Anyways, it mostly seems that they've offered a transaction method that 'works' in the sense that it can be done .. but also has attack vectors that are not shared by CryptoNote/Monero. Seems like an okay idea, but is outdated with the introduction of CryptoNote.
i'm over 2 XMR and counting 
