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:
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?
I think you missed that I am generating onetime keypair from the sender side. Only the receiver's pubkey is known.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 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?
crypto_box_keypair(onetime_pubkey.bytes,onetime_privkey.bytes);
if ( (cipher= encode_str(&cipherlen,src,len,destpubkey,onetime_privkey,onetime_pubkey)) != 0 )
Since this onetime keypair is generated for each packet, I do not see how this is linkable.
As far as conflict resolution, I use the ethernet method, ie. if something goes wrong, try again with a different set of participants. Since I am using a realtime network to do the comms, a full round will finish in less than a minute. i use InstantDEX orderbook to establish the list of participants.
James
P.S. I will add check for no duplicates