I propose a specification of the CoinJoin protocol. It is not yet implemented, but if you find the work-flow sound it would not be hard to make an IRC bot with the sx command line utilities as a proof-of-concept.

The idea is a P2P network where a thread is relaying all transactions. Another thread is in charge of the mixing.

A first, simple implementation would be an IRC bot which sends and listens to encoded transactions. Of course this approach would not be P2P, but a public channel in a hidden IRC server provides several advantages:

   -Easy implementation: IRC servers already exist. Bots enter to the channel #coinjoin (for example) and speak there.
   -Soft trust system:
      - If we trust the IRC server (for large values of 'trust') and only registered nicks are allowed to talk in the channel, a Sybil attack will be difficult.
      - We can chat (privately or publicly) with some users and thus allow them to prove their identity (by signing a given message, telling you a private joke, etc.)

The concept is composed by two parts (threads):

   1) Communications thread: In the case of the IRC server architecture, it has the method "sendTransaction" and "listenToTransaction". The first one "chats" in the channel and the latter listens to transactions and stores them in memory.

   2) The actual mixing part: Its work-flow is showed in the link [1]. It has been designed with yEd (http://www.yworks.com/en/products_yed_download.html) and the file (if you want to edit it) is [2] . The main points are:

      - It handles "change" addresses. If you want to mix 47 BTC, it will be a pain (really!) to make 47 inputs of 1 BTC and mix the separately. This approach allows you to send the 47 BTC as input, recover 1 BTC (for example) mixed and your 46 BTC back (of course, not mixed! In order to avoid confusion, this change address is the same as the input address). Fees are deduced from the change address, and thus you can serialize this method trivially as many times as you want.

      - Random decisions to avoid an attacker that listens how the transaction is constructed to map inputs with outputs. Each time transactions are composed in a different order.

      - If something goes wrong (bad signature, peer not responding, etc.) the output is discarded and the process restarted.


Q: What means checkTransaction?

A:
1) Are inputs confirmed (at least 1 confirmation)? OR, Are all unconfirmed previous transactions valid (for the Bitcoin network) and with enough fee?
AND
2) Signatures match?
AND
3) Is there enough transaction fee?
AND
4) Are all outputs equal AND sum(outputs) < sum(inputs)?


[1] http://i41.tinypic.com/5p3k02.jpg

[2] http://www18.zippyshare.com/v/26446175/file.html