[ANN] Rein - Decentralized Freelance Market

[weex]

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

[weex]

Added a couple of sheets demonstrating what the signature chains look like.

Spreadsheets (please see the detailed walkthrough for context):

Signatures Demo
Users

[weex]

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

[achow101]

Interesting project, I will follow, and perhaps help out with it if I have time. I can code, but only proficiently in java.

I left a few comments on the procedural outline which I would like you to look at. They are just clarification questions.

Also, I have few other questions:
1. Who are the reviewers and auditors and how are they determined?
2. Why must there be two addresses created and funded for each job?
3. How will this be decentralized?
4. Is there any way to prevent people from pretending to be multiple people at once? E.g. job creator is also the mediator or a reviewer for the same job.

[weex]

Interesting project, I will follow, and perhaps help out with it if I have time. I can code, but only proficiently in java.

I left a few comments on the procedural outline which I would like you to look at. They are just clarification questions.

Also, I have few other questions:
1. Who are the reviewers and auditors and how are they determined?
2. Why must there be two addresses created and funded for each job?
3. How will this be decentralized?
4. Is there any way to prevent people from pretending to be multiple people at once? E.g. job creator is also the mediator or a reviewer for the same job.

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.

[weex]

Had a fair amount of activity due to offering 0.05 btc for people to pre-alpha test in https://bitcointalk.org/index.php?topic=1234048.msg12847456#msg12847456

Lessons learned from today:

1. At this point, we have 5 user records created. Each has been signed as reviewed but none has been signed the third time.

2. We'll need to write out guidelines on when it is ok to sign at the reviewer or auditor stages. Basically specify which fields in the template are required and how we can do some validation on them.

3. We also have a little chicken and egg problem in that if someone's user record must be reviewed and audited before they can act as a reviewer or auditor then we can never get there. So at the beginning, we'll have to relax that requirement. If you have a reviewer signature, you may act as an auditor.

4. The enrollment signature needs to be signed by a user's master signing key. This establishes a single point of authority for an identity.

5. Clearly a lot of validation can be done with a one or a few scripts taking the Users sheet as a CSV input. Getting those written might be the first jobs posted unless someone wants to volunteer. Basically take a CSV download and check all of the user records for consistency, if not the signatures themselves.

[weex]

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-----

[weex]

Created a new git repo with a script to begin basic validation on the Users sheet.

https://github.com/weex/dpsmp

This is the script for which I created the signature verification module job above. Ideally this script will check everything to make a reviewer or auditor's job dead simple. Download the sheet, run the script, review or audit any records they can or raise alarm bells on anything that's amiss.

[CIYAM]

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.

[weex]

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.

Thank you CIYAM. II looked at it and at least know now what your handlestands for. If I have it right, it was a project to build a marketplace based on GPG and focused on using a specific development platform. Were there projects funded outside of that?

I'm calling this a protocol because though we have to start with specific tools, a well-documented and well-designed protocol can be platform agnostic. Maybe it would be best if you wrote up lessons learned on your project and posted a link here.

[CIYAM]

We're there projects that were funded outside of that?

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'm calling this a protocol because though we have to start with specific tools, a well-documented and well-designed  protocol can be platform agnostic. Maybe it would be best if you wrote up lessons learned on your project and posted a link here.

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).

[weex]

We're there projects that were funded outside of that?

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'm calling this a protocol because though we have to start with specific tools, a well-documented and well-designed  protocol can be platform agnostic. Maybe it would be best if you wrote up lessons learned on your project and posted a link here.

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).

Point taken. Clearly people do gigs online all the time so it sounds like a key focus is going to need to be addressing the reasons why more workers don't get involved. What might those be?

[CIYAM]

Point taken. Clearly people do gigs online all the time so it sounds like a key focus is going to need to be addressing the reasons why more workers don't get involved. What might those be?

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).

[weex]

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).

The way I'm looking at this project is not so much as a way to attract some class of user, but more to empower any user to be able to easily conduct a trade of their labor in a trust-free manner. Some have advised that higher paid workers prefer longer term gigs and would probably prefer a process with milestones rather than one-off jobs. It's too early to worry about any of that though. We still need to get through the first trade and build the process, in the process. I could definitely use your help with any of the things in the OP.

Oh, also what kind of premiums did you offer over what you considered fair in your experience but still get no takers?

[cryptozhellya]

nice

[CIYAM]

Oh, also what kind of premiums did you offer over what you considered fair in your experience but still get no takers?

Things like getting some very simple scripts written (kind of stuff that would take someone with the skills only an hour or so). I had to offer a few hundred dollars for these kinds of tasks (many of which I just ended up doing myself instead to save funds).

[weex]

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.

[weex]

Added:

Applications:

• A decentralized labor market combines human judgement with individual accountability through cryptographic signatures.
• Currency hedging, volatility protection - As long as enough funds are locked up to fulfill the value of the job, the signers can easily return excess funds to the job creator. For example, let’s say a job fee is set at $5k split between a front end dev and back end admin. Guarding against a 20% currency move means putting $6k in Bitcoin in escrow. If the value of escrowed funds drops, the workers would be right to demand more funds be placed in escrow to continue work. No action is required if the opposite happens.
• Milestones - Escrowed funds could be paid out in multiple payments based on reaching milestones in the project. The people in the project have to work together to send the payments and are accountable since their actions are recorded cryptographically.
• Subcontracting. Funds could be broken out and used to create and fund other jobs with completely different mediator/worker/milestone combinations.

[weex]

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

[achow101]

I will take a look at the sig tool update job and see what I can do with the program.

Also, is it possible to post for hire requests on that marketplace e.g I want people to hire me to do work.