Rein is a new experiment in decentralized markets. The Rein model mirrors that of internet at large through the use of paid microhosting to store data about users and gigs. Since storage and bandwidth requirements are low, a high amount of redundancy and censorship-resistance may be acheived at low cost (on par with the cost of a gourmet coffee for a year of redundant hosting on several servers).

This is very much a minimum viable product. Servers can be paid for their services but they do not communicate with each other, and while the client attempts to validate what it sees, this validation is not complete nor has the software seen a security review. As such, you are advised to limit use of Rein to small jobs where loss of funds or time spent would not present a significant burden.

To read more about the project, visit http://reinproject.org

Python-rein is a command-line interface client to the Rein market.

Development:

pip install --editable .

With the --editable switch, your edits immediately become live in your environment.

Production:

python setup.py install

Please see the setup guide.

Each transaction in Rein requires a job creator, worker, and mediator. Most of the time it is expected that the mediator will do nothing but collect a small fee. In case of dispute, however, the mediator holds a third key so that escrowed funds can be refunded, split or awarded according to their judgement.

rein bid

This command will query each registered server for jobs that are open for bids, and help you build and sign a bid document.

The first step in posting a job is to carefully choose a mediator. At this time there is little in the way of reputation in the system. Your own research should guide your choice.

rein post

Once a mediator is chosen, you will describe what you want done and by when. Once the post is signed, use sync to push it to your registered servers.

After a job posting and bids have been made, the job creator will use offer to choose a bid. They should then fund both the primary and mediator escrow addresses so the worker can begin. Once the work is complete, the worker uses deliver to post deliverables which can be reviewed and accepted by the job creator with accept. During the accept step, the job creator will be prompted for signed primary and mediator payment transactions.

Python-rein currently cannot query for unspent outputs or assemble transactions so it is recommended that you download a copy of ReinProject's fork of Coinb.in in order to sign (and for the worker and mediator, broadcast) the payment transactions.

If you want detailed information about pending jobs use rein status. If run with the --jobid option, all documents associated with a specific gig will be printed to the screen.

Rein uses two types of escrow in order to protect funds that are to go to the worker or job creator (depending upon the success of the transaction) as well as the mediator.

For the primary payment, a simple 2-of-3 escrow address is created. To spend the funds placed at this address requires that two parties out of the job creator, worker, and mediator sign each payment. The user is prompted for a signed primary payment if they are a job creator accepting a delivery or they are the mediator resolving a dispute. This payment can be built and signed using Coinb.in which will retrieve unspent outputs (i.e. the funds) and allow the user to specify the destination address and amount, with excess going to the Bitcoin network as a fee for the miner of the transaction.

Having only been signed by one party, this payment should be reviewed before the second party adds their signature and broadcasts the transaction.

For example in a normal, non-disputed transaction the worker should check that their address is the one being paid and that the Bitcoin network fee is reasonable. If an error is found, the signing party can be contacted to build a new transaction with the correct information.

For the mediator payment, a mandatory multisig address is created. To spend the funds placed at this address, the mediator must sign the payment and be accompanied by either the job creator or worker's signature. This ensures that the job creator and worker cannot conspire to steal the mediator payment, even though in theory they could both refuse to sign the mediator's payment if both feel the mediator made an unfair judgement.

Like with the primary payment, a user is prompted for a signed mediator payment if they are a job creator accepting a delivery or they are the mediator resolving a dispute.

To help test, download and run a server locally. Run rein testnet true, then rein setup. You can use the address/key pairs on this sheet for convenience to setup Alice, Bob, and Charlie with the right keys/identities.

Then run using nose:

$ nosetests
..
----------------------------------------------------------------------
Ran 2 tests in 0.837s

OK

Tox fails right now but does run flake so will be helpful for cleanup.