richbodo / multibounty

Bounty code for multi-sig bitcoin applications

multibounty

#MultiSig Bounty Library

NOTE: This is no longer maintained. We were trying to build a trustworthy general-purpose bounty system. We found that apps communicating through a blockchain and a third party site/system, will generally be as trustworthy as the least trustworthy link in the communications system.

This is where most blockchain mashups fail.

The only way to make a system of this type trustworthy would be to add functionality to common open-source wallets - that would give everyone the means to communicate properly through a trusted blockchain, and eliminate any central points of trust.

Summary

Multibounty provides a library and example that uses the bitcoin blockchain to solve the following problem:

You are an author of some code or other work on github. You want to incentivize people to do work, such as fix bugs in code, or supply excellent edits to documentation.

We learned quite a bit about how to solve this problem while requiring the least trust of users(aka the most trustworthy process).

As stated above, we concluded that a platform (we built a prototype of that) is the wrong way to go. We now believe that an open source bitcoin wallet client that understands how to broker discussions with other clients using the blockchain itself is the answer. A microformat should be developed specifically for bounty work, and demonstrated using that client. Our final presentation with our conclusions is here: MultiBounty Final Presentation

Everything below relates to our toy bounty platform project, which we wrote in meteor using block.io as the backend.

Three steps need to be made:

1. Bounty Transaction: You want to offer a bounty that is irrevocable, to be awarded for the work desired, to the first person to satisfy some condition. So you make a Bounty Transaction locking up that money for that purpose.

2. Decision: A decision is made as to who should win the bounty, either by You, or by the MultiBounty Platform as Oracle.

3. Award Transaction: Finally, an award must be made sending the output of the Bounty Transaction to the receiving address of the winner.

Two of the simplest workflows we imagine are included below in use cases 1 and 2.

I took a first pass at mocking up the simpler of those two cases, Bounty Driven Editing, as a website:

Future Work: Many different possibilities exist for more complex use cases and workflows.

Looking just at the three steps required to make a bounty:

In the first step, the Bounty could be multiparty (many people chip in to the award, some number need to be in agreement to present it).

In the second step, the Decision to award a bounty, can be complex, involving multiple parties, voting, test driven development, handoff of copyright, and more. The bounty could also be restricted to a list of individuals (or even just to the author).

In the third step, the award transaction might be given partially to many submissions that all contribute some value.

Finally, the underlying services for blockchain manipulation (blockcypher, block.io, bitcore-wallet-service, ethereum, etc) and decision making (github, travis.ci) could be abstracted. We'll just start simple, though.

There are some really fun ideas that have been proposed for bounties, and could be explored further here. Such as:

• Security bounties - obtain a private key required to sign a transaction by cracking security of a system, revealing it. Of course, one would want this to be verified by a few others who would sign to verify that the exploit was fully revealed to the owner of the system cracked.
• Github integration - this is a tricky one, because although a micro-format can be used in co-operation with github issues and commits to prevent one from having to leave their flow (platform-less bounties), github is a horrible sidechain, allowing modification to almost anything you add after the fact. As far as we can tell, github.com itself would have to add some functionality to enable this to work reliably (immutable issues or equivalent).
• Copyright assignment might be interesting. That could be done as a contract on one blockchain or another as well, although how legally binding that might be in any jurisdiction is a bit fuzzy. Simple enough to apply a shrink wrap EULA when submitting an edit - but maybe you don't want to offer the copyright until you get the bounty. Or...maybe you want to have fun writing smart contracts! ;)
• The big kahuna problem is to make it easy for end users to do this without a platform - something that would probably involve much more featureful client wallets than we have seen (proposal, signed transaction sharing, on-chain messaging..

MultiBounty was created as a blockchainu midterm project. Blockchain U rocks.

multibounty's Issues

Author Display Bounty Page Shows Submissions with Status and Accept and Reject Buttons

Each Submission submitted for a bounty shows in it's entirety below that bounty.

Add a status field (New/Accepted/Rejected) and Buttons to Accept or Reject each submission

Public Display Bounty Page Accepts Submissions

Each bounty displayed has a Submit Edit Form:

1. Body of the edit
2. Receive address that editor hopes to receive bounty at
   Submit Button

One submission per rcv addy or error.

Add submission to db - one bounty has many submissions

Signup for author works

Typical email/pass signup. Email confirmation.

Create Approval page that allows Author to Approve or Reject Editors work

Signup takes author to a create bounty page with submit bounty form

Submit bounty form has:
Creative Work
Bounty Task (what the author wants the editor to do)
Bounty Amount
Submit button

Author Can Reject Submissions

When the author clicks on "Reject" next to a submission on the Author Display Bounty page, the submission is moved to "Rejected" state. The accept and reject buttons dissapear, to be replaced by the text "Rejected"

Public Display Bounty Page Displays Bounties

Same fields as Author Display Bounty Page

Author can accept submissions

On the Author Display Bounty page, the author can click on the Accept button next to any submission.

The accept button changes the state of the submission to "Accepted" and buttons no longer show next to that submission - they are replaced by the text "Accepted"

Additionally, all other submissions for that Bounty are moved to the "Rejected" state with buttons removed and "Rejected" text added.

Create Bounty page (website) that allows author to submit Bounty Task

Create Award page that allows Editor to submit work

Author Display Bounty Page Displays Bounties

Bounty Fields:
Creative work
Task for Editor
Bounty Amount
Receiving address for transaction

Multibounty Library can create an Award transaction using the Bounty Transaction output script as an input, and awarding to an editors receiving address.

Multibounty Library can create a bounty transaction to an output script that both author and "platform" must sign spending of.

Submit Bounty Form

With Copay - add the following to the submission form:

Tell them to create a copay account, then create a shared wallet, and enter the private key in the form.

When they submit the form, verify the shared wallet, and show them the recieving address. Tell them that the balance is zero, and that they should fund it. Tell them how to do that, and that anyone else can do it, too.

Accepting a submission sends bounty

When an author accepts a submission, the multisig transaction is signed by platform and author and sent to the editor.

The award amount is added to the submission, and displayed on the Author Display Bounty page and the Public display bounty page, along with a link to the transaction id on some web-based blockchain browser.