Bitcoin Forum
September 26, 2016, 12:16:32 PM *
News: Latest stable version of Bitcoin Core: 0.13.0 (New!) [Torrent]. Make sure you verify it.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: The "Bounty Swarm"  (Read 3317 times)
Anonymous
Guest

August 07, 2010, 06:49:48 AM
 #1

I propose the following -which I call the "distributed bounty swarm".It would utilise a bitcoin type application where people would tag a transaction fee with a label such as "fix this bug" or "build this website feature" or "hire me" which would then be broadcast on the network and the person that solved the issue could collect the "cloud bounty" on offer.The bounties could be parsed from the swarm and listed on any website or client.Both the fee provider and the bounty collector would only be registered by their bitcoin address.This could  be encrypted with a pgp key to verify ownership.

What is needed
A way to broadcast to the swarm that a job has been completed.
An automatic escrow service that verifies the job has been completed.The fee is already verified by the swarm.
Some form of messaging/contact  between fee provider address and bounty collector address to allow pgp key sending.
Provide a sending and receiving address so that a coin sent to you gets sent back out with your signed pgp key which verifies you to the other party.
1474892192
Hero Member
*
Offline Offline

Posts: 1474892192

View Profile Personal Message (Offline)

Ignore
1474892192
Reply with quote  #2

1474892192
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1474892192
Hero Member
*
Offline Offline

Posts: 1474892192

View Profile Personal Message (Offline)

Ignore
1474892192
Reply with quote  #2

1474892192
Report to moderator
1474892192
Hero Member
*
Offline Offline

Posts: 1474892192

View Profile Personal Message (Offline)

Ignore
1474892192
Reply with quote  #2

1474892192
Report to moderator
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
August 07, 2010, 06:59:37 AM
 #2

Hmm...I feel weird in the abritation and judgement area. Some jobs won't be of to the satisifaction of some individuals. Some individuals think it is a satisifed job. Some jobs are completely subjective.

But, clearly, I am not thinking clearly since I am tired and all.

FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
August 07, 2010, 09:06:06 AM
 #3

I think it's a great idea for a separate service.

The currency can be bitcoin or something else even.

I think it's a great example of how public goods can be funded without coercion. I don't think bounties can provide every public good, so don't derail this thread trying to straw man me.

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
bytemaster
Hero Member
*****
Offline Offline

Activity: 728

BitShares


View Profile WWW
August 08, 2010, 01:15:07 AM
 #4

I had about the same idea 5 years ago and tried to implement it as "OpenContract".  The challenge is finding a way to clearly define requirements and dealing with multiple people who "race" to get it done.  I would love to see such a system.

https://steemit.com  Blogging is the new Mining
mizerydearia
Hero Member
*****
Offline Offline

Activity: 574



View Profile
August 08, 2010, 05:15:40 AM
 #5

I had about the same idea 5 years ago and tried to implement it as "OpenContract".  The challenge is finding a way to clearly define requirements and dealing with multiple people who "race" to get it done.  I would love to see such a system.

Humm, for some reason I am reminded of 99designs and http://no-spec.com
Ground Loop
Member
**
Offline Offline

Activity: 112


View Profile
August 10, 2010, 04:26:43 AM
 #6

Before solving the difficult "submission and satisfaction" part, I'd love to find a way to pay into a pool, even if that pool is controlled (received/arbitrated) by one person.

For example, bounty for some public good (SSE4.2 optimization or somesuch).  I just want a way to send coins out to be 'held' in escrow until some agreed arbiter releases them.

In the event the deadline arrives, there should be an easy way to "refund" all the coins back where they came from.

The irreversible and anonymous nature of bitcoins makes this really attractive, since the "doer" knows precisely how many coins are pending, and the donors don't need to identify themselves.

Bitcoin accepted here: 1HrAmQk9EuH3Ak6ugsw3qi3g23DG6YUNPq
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
August 10, 2010, 04:33:03 AM
 #7

So, who is working on this project?

Anonymous
Guest

August 10, 2010, 05:19:07 AM
 #8

Before solving the difficult "submission and satisfaction" part, I'd love to find a way to pay into a pool, even if that pool is controlled (received/arbitrated) by one person.

For example, bounty for some public good (SSE4.2 optimization or somesuch).  I just want a way to send coins out to be 'held' in escrow until some agreed arbiter releases them.

In the event the deadline arrives, there should be an easy way to "refund" all the coins back where they came from.

The irreversible and anonymous nature of bitcoins makes this really attractive, since the "doer" knows precisely how many coins are pending, and the donors don't need to identify themselves.

Yeah freelancer or odesk isnt appropriate though they offer some of the functionality.
Anonymous
Guest

August 10, 2010, 05:19:37 AM
 #9

So, who is working on this project?


Whoever wants too!!
Ground Loop
Member
**
Offline Offline

Activity: 112


View Profile
August 10, 2010, 05:53:31 AM
 #10

Really, it's just the refunding that's difficult.

If I post a btc address, and everyone agrees that I'm a trustworthy treasurer, I can receive the escrow/bounty just fine.  Further, with the right not-yet-extant tools, anyone could see the accumulated total (so no trust is required there).  That's very cool.  So that becomes the more general coin-tracking problem -- figuring out the total credits in any one address.

The problem comes if I want to refund the bounty to the respective donors.  That seems impossible without adding something to identfy the payer (IP address).  Hmm.

Bitcoin accepted here: 1HrAmQk9EuH3Ak6ugsw3qi3g23DG6YUNPq
mizerydearia
Hero Member
*****
Offline Offline

Activity: 574



View Profile
August 10, 2010, 06:11:23 AM
 #11

I'm not sure if this is related, but I think it is.  As I was searching through the forum and also with some collaboration with jgarzik on IRC, I prepared http://www.bitcoin.org/wiki/doku.php?id=list_of_patches and particularly learned more about listtransactions patch http://bitcointalk.org/index.php?topic=611.0

I believe that patch may be useful in some way.
Anonymous
Guest

August 10, 2010, 06:57:07 AM
 #12

Really, it's just the refunding that's difficult.

If I post a btc address, and everyone agrees that I'm a trustworthy treasurer, I can receive the escrow/bounty just fine.  Further, with the right not-yet-extant tools, anyone could see the accumulated total (so no trust is required there).  That's very cool.  So that becomes the more general coin-tracking problem -- figuring out the total credits in any one address.

The problem comes if I want to refund the bounty to the respective donors.  That seems impossible without adding something to identfy the payer (IP address).  Hmm.

Probably need to secure ip first  Cheesy
Insti
Sr. Member
****
Offline Offline

Activity: 294


Firstbits: 1duzy


View Profile
August 10, 2010, 08:47:22 AM
 #13

Really, it's just the refunding that's difficult.

If I post a btc address, and everyone agrees that I'm a trustworthy treasurer, I can receive the escrow/bounty just fine.  Further, with the right not-yet-extant tools, anyone could see the accumulated total (so no trust is required there).  That's very cool.  So that becomes the more general coin-tracking problem -- figuring out the total credits in any one address.

The problem comes if I want to refund the bounty to the respective donors.  That seems impossible without adding something to identfy the payer (IP address).  Hmm.

The 'from' Bitcoin address is stored in the transaction, you don't need any extra information.
Sending money back where it came from is not difficult.
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
August 10, 2010, 09:54:03 AM
 #14

Really, it's just the refunding that's difficult.

If I post a btc address, and everyone agrees that I'm a trustworthy treasurer, I can receive the escrow/bounty just fine.  Further, with the right not-yet-extant tools, anyone could see the accumulated total (so no trust is required there).  That's very cool.  So that becomes the more general coin-tracking problem -- figuring out the total credits in any one address.

The problem comes if I want to refund the bounty to the respective donors.  That seems impossible without adding something to identfy the payer (IP address).  Hmm.

The 'from' Bitcoin address is stored in the transaction, you don't need any extra information.
Sending money back where it came from is not difficult.

Why doesn't this show up in the client? Am I blind?

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
Insti
Sr. Member
****
Offline Offline

Activity: 294


Firstbits: 1duzy


View Profile
August 10, 2010, 02:51:43 PM
 #15

Why doesn't this show up in the client? Am I blind?

Good question. No.
Ground Loop
Member
**
Offline Offline

Activity: 112


View Profile
August 10, 2010, 03:53:54 PM
 #16

Seriously?  The From bc address is right there in the transaction?  That would be great.
My clients show only the address the payment was *to*, not from.

I'd love to set up a receive address that maintains (in the client?) the sources of all funds, and has a "return to payer" feature.

Bitcoin accepted here: 1HrAmQk9EuH3Ak6ugsw3qi3g23DG6YUNPq
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2422


View Profile
August 10, 2010, 08:26:29 PM
 #17

Transactions are usually from many different addresses (maybe hundreds), so you can't show them in the "all transactions" list.

Returning a payment to one of these addresses would be confusing, since they would see a payment going to an address they created for some one-time thing months ago or whatever. They'd have no way of knowing it was from you. The client could be modified to detect this, though.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
FreeMoney
Legendary
*
Offline Offline

Activity: 1246


Strength in numbers


View Profile WWW
August 10, 2010, 08:28:42 PM
 #18

Transactions are usually from many different addresses (maybe hundreds), so you can't show them in the "all transactions" list.

Returning a payment to one of these addresses would be confusing, since they would see a payment going to an address they created for some one-time thing months ago or whatever. They'd have no way of knowing it was from you. The client could be modified to detect this, though.

What about showing the one(?) address to which the change was sent? Is there a change address if change happens to be 0?

Play Bitcoin Poker at sealswithclubs.eu. We're active and open to everyone.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2422


View Profile
August 10, 2010, 08:31:14 PM
 #19

What about showing the one(?) address to which the change was sent? Is there a change address if change happens to be 0?

There isn't. Good idea, though -- there would be a single change address in almost all cases.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Insti
Sr. Member
****
Offline Offline

Activity: 294


Firstbits: 1duzy


View Profile
August 10, 2010, 08:40:12 PM
 #20

Transactions are usually from many different addresses (maybe hundreds), so you can't show them in the "all transactions" list.

Returning a payment to one of these addresses would be confusing, since they would see a payment going to an address they created for some one-time thing months ago or whatever. They'd have no way of knowing it was from you. The client could be modified to detect this, though.

If you know there is the possibility of a return, you just do another transaction to a new address before the actual transaction so it is only coming from one address.

Or you could just make sure the first listed transaction from address was the one you wanted to be the 'return address'
Would probably require slight client modification, but should be simple to do.
Then we just agree on the standard. (which is all the system is anyway.)

Are transactions allowed to have input addresses with a zero balance?

Pages: [1] 2 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!