I'm one of the authors of the CoinShuffle paper. Really fantastic to see that people are interested in the protocol!

I had a brief look at the code and I think there are several severe problems:

• You use authenticated public-key encryption (from the NaCl library). It has the property that a recipient can be sure who created a given ciphertext. This is exactly the opposite of what we need in CoinShuffle. In fact, the whole point of shuffling is to hide that information from the recipient.
  We need normal IND-CCA encryption, e.g., or DHIES.
  So your implementation does not provide anonymity (or unlinkability as dubbed in the paper).
  
• Each peer must check that there are no duplicate plaintexts after decrypting. Otherwise attacks on unlinkability are possible.
• The whole blame phase is missing, so there is no robustness against DoS attacks as described in the paper. This is actually not a huge problem for a first implementation for a first implementation but should be noted because you implemented currently only a subset of the full CoinShuffle protocol.

(The list is not necessarily complete; these are just the problems that I've seen immediately.)

The problem is that the paper as-is is written for crypto researchers and is quite high-level. I think the protocol is not overly complex but the devil is in the details as with all crypto.

I've just started a collaboration with Kristov Atlas. We will write a BIP draft including a more detailed, development-oriented specification of the protocol including all the nitty-gritty details. We also plan talk to wallet developers and I will definitively write some code as soon as a reasonable version of the BIP is there. Contributions and collaborations are welcome in all stages, of course.

There are also some open questions, e.g., how to find participants for the shuffling, and what to use for communication (on a network level). How is that done in your implementation?