Skip to content

prime33/coinjoin

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

33 Commits
 
 
 
 
 
 
 
 
 
 

Repository files navigation

RUNNING:

to run the client install Python PyQt4, and sx (see http://sx.dyne.org)

  # apt-get install python-pyqt4
  # wget http://sx.dyne.org/install-sx.sh
  # bash install-sx.sh

Tor control configuration:
  (not needed at the moment)
  In order to allow the application to reset your tor connection between coinjoin stages, you first need to
  setup your tor control password (HashedControlPassword in /etc/tor/torrc, also uncomment ControlPort line).

  Then edit client.py and set your control password there.

then run it:

  $ python client.py

TECHNICAL INFO:

Clients use the server as a rendezvous point.

The goal of the clients is to get a list of N inputs and N outputs
for a specific locked amount, so a transaction can be created by all
to sign.

Since clients won't sign the transaction if they don't see their
inputs and outputs, or amounts match, the problem is just getting 
inputs and outputs in a way so they can't be correlated to know who
owns the outputs.

In our case the server takes up the following tasks:
 1) locks "rooms" for  number of participants
 2) collects outputs, then inputs for all participants, then shows
   the collected information, together with a transaction with all
   the info, clients have to sign the transaction and return it back.
 3) mixes the transactions into one final transaction signed by all,
    and broadcasts it to clients and to the network.

The server doesn't hold funds, and the client can check the final
transaction before signing it so no trust is put on the server.

The server keeps all information in memory.

The setup is implemented with the premise that server and client can't
see each other's ip, specially the server can't see the client ip. To
avoid user error we enforce the service to run over tor, but other
anonymizing network could be used.

POSSIBLE ATTACKS:

We've thought about the possible attacks that can be done on this approach:

 - Sybil attack:
   An attacker with many nodes could cheaply (just transaction costs) run many transactions to basically isolate other users.
 - Ddos attack:
   Attackers can boicott ongoing transactions so users have to restart again and again most probably also leaking privacy information specially if outputs are retried.

FUTURE WORK:

This is intended as a first proof of concept for a "coinjoin" protocol
where different rendezvous mechanisms will be tested in order to collect inputs and outputs for creating multi-sig transactions among different wallets.

Server mechanisms ease the practical access by users and initial deployment, totally serverless mechanisms should follow using readily available procedures.

PROTOCOL:

 - client is pyqt + sx
 - server is gevent + flask + sx

Client and server speak a json protocol where a room is created
for each url of the form:

   <server>/g/<room_name>

or

   <server>/g/[public]<room_name>/<participants>/<amount>

so a sample url would be:

   http://7vxb75tbnszhy2go.onion/g/goy7yeiXopethi

The first time a url is accessed with GET the room gets created
and starts collecting information.

Rooms go through several states or stages, one at a time:
 * outputs: Collecting outputs
 * inputs: Collecting inputs
 * signatures: Collecting signatures
 * final: final tx available (and broadcasted)

In each stage each client has to send their specific argument, after
collecting inputs and outputs a tx for signing is generated and each
client signs their own, finally the server mixes the result into the
final tx.

Clients send their input through POST to the room url:

POST parameters:
 - input: send our client input (only allowed in inputs stage)
 - output: send our client output (only allowed in outputs stage)
 - sig: send out signature (only allowed in signature stage)

LICENSE:
 This work is released under AGPL v3, check COPYRIGHT file for more details.

 Since this is quite low level work we're happy to see it used in other places, although we're more comfortable with
 releasing the code under AGPL to promote a more open ecosystem, please get in touch with us if you want to incorporate
 our code into incompatible licenses.