Rein is designed to help you conduct freelancing transactions safely and easily. Clients can post jobs to Rein's decentralized network and freelancers can submit bids on available jobs.

As of now, the best use of Rein is to build, fund and manage multisig escrows to ensure each party gets what they want in a job. Along with the escrows, job descriptions, bid amounts, and timing are cryptographically signed by participants to a job. That way, if anything goes wrong the mediator can pay out or return funds as necessary.

The Mission:
Create a decentralized market to enable people to work and have work done in exchange for bitcoin. Learn more...


Setup Guide
HOWTO: Setup Rein


Development Roadmap
We have a few tasks on our development roadmap for which we're looking for developers. Since we want to help grow the Bitcoin development community and many devs are interested to grow their skills, we've been able to do a ton with not a lot of funds.

If you can help with funding, PM me. Your donations can go directly to escrow for specific features.

Timeline
Oct. 2015 - Planning begins
Jan 2016 - Alpha tagged, command-line version
March 2016 - First transaction completed - a digital painting
May 2016 - Tor support
Oct 2016 - Web-based user interface
Nov 2016 - Rein is used for several jobs to improve Rein per the development roadmap
Feb 2017 - v0.3.0 Beta released with bip32 setup, transaction sign&send, ratings


Press
Bitcoin.com: Bitcoin Freelance Marketplace Rein Launches in Beta
Bitcoinist: The Rein Project Completes First Freelance Contract
Brave New Coin: Bitcoin-only decentralized marketplace, Rein, targets growing freelance industry
BTCManager.com: Rein’s Experiment in Decentralized Labor: An Interview with David Sterry
BetByBitcoin: Review decentralized freelance market – Rein


Software
Latest release: v0.3.0-beta
Python-rein client - Client for Rein.
Causeway server - Run a server and get paid for providing microhosting. Grants microhosting space, ECDSA signature auth, stores and returns key/value pairs. Also responds to queries for specific types of documents like job postings, bids, deliveries, or all documents by job ID.

To get setup see the README for python-rein: https://github.com/ReinProject/python-rein/blob/master/doc/HOWTO-setup-rein.md

For more info, see: https://reinproject.org

Offering 0.05 BTC for help with this today. https://bitcointalk.org/index.php?topic=1234048.msg12847456#msg12847456

Thank you for checking this out!

Clarified and resolved those comments.

1. Reviewers and auditors are simply other users registered in the system at the beginning. Once some users have established a track record or we implement some kind of community multisig bond, we will limit those roles to some threshold trust score.

2. The second address is to pay the mediator for their dispute resolution services. The job creator chooses a mediator when they build their job in order to reduce steps. Mediators should specify their fee in the message they sign to establish or update their user record.

3. One step at a time. By establishing a protocol for how all this works, any number of applications or networks should be able to implement it and eventually we will have a p2p network with tor connectivity.

4. I don't think so but we can at least make it cost something. Either reputation or probably my best idea on this so far is to require an amount of btc to be locked in a multisig address with lots of members (like 10-of-15). Burning coins is another way.

Posted the first two jobs to the new Job Listings sheet. Pasted here as well.

-----BEGIN BITCOIN SIGNED MESSAGE-----
Job Name: Signature Tool Updates
Job Creator’s Public Key: 03FB2CA1B513858CD8461AE875BA7096CB7D585C29E7C6B5294FEF7B6C326389C4
Mediator’s Public Key: 04594f2582c859c4f65084ee7fe8e9ec2d695bb988a3f53db48eaaff6ff3a0282b2be0c79fefca0 1277404d0fdc3a923e8ed02efd6ab96980f3e229a81fbe032e9
Category: Software Development
Job Description: I’m looking for someone to help update the signature tool. Please fork https://github.com/weex/bitcoin-signature-tool and provide me a pull request with the following changes:
1. Make the Verify page the first page a new visitor lands on.
2. Once a user verifies a message, show a button that when clicked copies the verified message over to the Message textarea on the Sign page and changes the view over to the signing page.
3. If a user clicks on the Signed Message field on the Sign page, make the entire cell highlight so it can be easily copied for pasting into a sheet.
4. Change the private key field to display *****s when it’s filled in and create a Show button that toggles the display of the private key.
-----BEGIN SIGNATURE-----
1BbgnPQYeXAt39ifLNUWP1RBktpzGLmRZS
IHgKhIpPFYfSs1Mi19OAZQlTOeqIV4oNdyE/7uVLIM6YtFsWg1VqFZ84+sIXAMk8C88dPuOB9gGGLKAQmxBo2c8=
-----END BITCOIN SIGNED MESSAGE-----

-----BEGIN BITCOIN SIGNED MESSAGE-----
Job Name: Python module for signature verification
Job Creator’s Public Key: 03FB2CA1B513858CD8461AE875BA7096CB7D585C29E7C6B5294FEF7B6C326389C4
Mediator’s Public Key: 04594f2582c859c4f65084ee7fe8e9ec2d695bb988a3f53db48eaaff6ff3a0282b2be0c79fefca0 1277404d0fdc3a923e8ed02efd6ab96980f3e229a81fbe032e9
Category: Software Development
Job Description: The signatures on the Users sheet are signed manually by users before they add their signature as reviewer or auditor. We need the following few python functions that can validate the various signatures on the Users sheet. Please include a script that will test the functions.

validate_enrollment(enrollment_signature_text) - validates the ECDSA signature on the Enrollment signature as valid/invalid. also checks that it was signed by the master signing key within.
Returns an array with:
* true/false bool that signature verifies and uses specified master signing key
* signing key

validate_review(reviewer_text) - checks the outer signature on a review.
Returns an array with:
* true/false on the signature verification
* signing address
* text of message that was signed (everything between ----BEGIN BITCOIN SIGNED MESSAGE----- and ----BEGIN SIGNATURE-----) with the dash-space removed from the beginning of the internal ----- lines. This should enable the message to be verified by validate_enrollment.
 
validate_audit(auditor_text) - checks the outer signature on an audit
Returns an array with:
* true/false on the signature verification
* signing address
* text of message that was signed (everything between ----BEGIN BITCOIN SIGNED MESSAGE---- and ----BEGIN SIGNATURE----) with the dash-space removed from the beginning of the ----- lines for ONLY the outermost signature. This should enable the message to be verified by validate_review.

Please PM weex on bitcointalk.org with any questions.
-----BEGIN SIGNATURE-----
1BbgnPQYeXAt39ifLNUWP1RBktpzGLmRZS
Hz9gbXPhtSpLkNFVacvNADdb7cbiIL3aIzuCNGY6Mx+pekr5o58UVqcsomjGKCjqT3g3htnU87eAp8KrWFy5buE=
-----END BITCOIN SIGNED MESSAGE-----

Not sure if you had ever looked at CIYAM Open but it is a similar (but simpler) concept (http://ciyam.org/open).

Feel free to contact me via PM if you'd like to discuss my experiences with trying to get this kind of thing up and running.

Probably the main project other than the platform itself and the Automated Transactions (AT) project was the Moneychanger project (from the Open Transactions people). Unfortunately they did all their payments "off the record" so the Project tasks listed there show no payments (and were never closed).


I guess the main lesson that I've learned is that people are not yet ready to work this way - even when I offered almost insanely generous payments for tasks there were very few (if any) people willing to take on the work (and that was not due to not trusting me about payment).

To a fair extent I think it very much depends upon the kinds of tasks.

Very talented programmers (which I have tried to target) are simply not possible unless you offer almost ridiculously high prices (it is just too easy for them to get a high paying stable job).

Low talented programmers you'll find but are really not even worth bothering with (they'll cause you more trouble than you pay them for).

Graphic designers are perhaps your best bet as those people tend to work for nothing (often trying to chase bounties which only one of them will get). For CIYAM Open I didn't want to do bounties (as I think it is actually unfair to have people working for nothing) but I think for that kind of task they actually seem to work better (apparently those kind of people like to gamble on whether they will get paid at all).

nice

Perhaps the greatest opportunity for this protocol isn't for small gigs and medium sized jobs. Maybe we should be thinking about where greater amounts of trust are required between participants. The low budget example here might be hiring a project manager and locking the funds for a project they manage so it is split fairly  between the manager and each of the workers.

A huge feature could be volatility protection. The amount of escrowed bitcoin could be greater than required to handle currency fluctuations with any excess returned to the job creator.

Posted the job about verifying signatures to https://bountify.co for $50 in BTC. It should show up in an hour or two.