The "Bounty Swarm"

[Anonymous]

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.

[1713919239]

1713919239

[1713919239]

1713919239

[kiba]

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]

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.

[bytemaster]

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.

[mizerydearia]

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]

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.

[kiba]

So, who is working on this project?

[Anonymous]

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]

So, who is working on this project?

Whoever wants too!!

[Ground Loop]

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.

[mizerydearia]

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]

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 

[Insti]

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]

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?

[Insti]

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

Good question. No.

[Ground Loop]

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.

[theymos]

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.

[FreeMoney]

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?

[theymos]

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.

[Insti]

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?

[Gavin Andresen]

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

If they are (I didn't see anything preventing them after a quick reading of the code), then they trigger the 0.01BTC micro-transaction fee.

I'll be doing a lot of experimenting (on the TEST network, of course) with refunding transactions over the next few weeks.  I think the UI issue can be resolved (it should be pretty straightforward to teach the UI to recognize refund transactions and show them as "refund from BLAH", where BLAH is either a BC address or a label from your address book.

I've already implemented a "refundtransaction" api call, but it still needs work before it would be ready for standard bitcoin.  In particular, it shouldn't be possible to create infinite 'refundtransaction' loops (where you accidentally or purposely refundtransaction a refunded transaction, probably triggering another refund, etc).

And refunding a transaction should, ideally, use the same "coins" (... should have the same ancestor transactions, for anybody who's going to get all pedantic on me) as the original transaction, if possible, so if that original transaction is exactly as valid as the original transaction.  Otherwise it might be possible to generate a bad transaction, send it somewhere you know it will get refunded immediately with different, valid transactions, and so "launder" your bad bitcoins for good.

[Insti]

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

If they are (I didn't see anything preventing them after a quick reading of the code), then they trigger the 0.01BTC micro-transaction fee.

I'll be doing a lot of experimenting (on the TEST network, of course) with refunding transactions over the next few weeks.  I think the UI issue can be resolved (it should be pretty straightforward to teach the UI to recognize refund transactions and show them as "refund from BLAH", where BLAH is either a BC address or a label from your address book.

I've already implemented a "refundtransaction" api call, but it still needs work before it would be ready for standard bitcoin.  In particular, it shouldn't be possible to create infinite 'refundtransaction' loops (where you accidentally or purposely refundtransaction a refunded transaction, probably triggering another refund, etc).

And refunding a transaction should, ideally, use the same "coins" (... should have the same ancestor transactions, for anybody who's going to get all pedantic on me) as the original transaction, if possible, so if that original transaction is exactly as valid as the original transaction.  Otherwise it might be possible to generate a bad transaction, send it somewhere you know it will get refunded immediately with different, valid transactions, and so "launder" your bad bitcoins for good.

The micro transaction fee only applies to the the 'out' side.

By putting the 'return address' on the 'In' side, we can pass a specific return address if we want.

TXIn [ Return Address (0), Address with money (10) ]
TXOut [ Payee Address (9.95), Change Address (0.05) ]

The return transaction should be indistinguishable from any other transaction.

TXIn[ Some other Address (9.95 ) ]
TXOut[ Return Address (9.95) ]

Anyone who is accepting 'bad' transactions and returning good coins deserves to give their money away.

[Gavin Andresen]

The micro transaction fee only applies to the the 'out' side.

Right, but every TxIn has to have a corresponding TxOut (except for GENERATE/coinbase transactions, but those have their own rules).  So if you want a 0 BTC TxIn, you've gotta first pay yourself with a 0BTC TxOut and that'll trigger the fee.  TxIns don't contain a value, the value is in the corresponding TxOut...

Anyone who is accepting 'bad' transactions and returning good coins deserves to give their money away.

But you agree that it wouldn't be OK for a 'refundtransaction' API call to make it easy to do that, right?

[Insti]

The micro transaction fee only applies to the the 'out' side.

Right, but every TxIn has to have a corresponding TxOut (except for GENERATE/coinbase transactions, but those have their own rules).  So if you want a 0 BTC TxIn, you've gotta first pay yourself with a 0BTC TxOut and that'll trigger the fee.  TxIns don't contain a value, the value is in the corresponding TxOut...

Ok, that makes things more complicated again.
I suggest just using the first listed TxIn address as the return address + let peoples clients manipulate the transactions so the 'right' value is in that position. This may involve an initial transaction to yourself to put some(all) of the money in a 'refund possible from shop X' address, before the actual payment to shop X.
(Now you tell me transaction input order is not deterministic?)

Anyone who is accepting 'bad' transactions and returning good coins deserves to give their money away.

But you agree that it wouldn't be OK for a 'refundtransaction' API call to make it easy to do that, right?

'refundtransaction' API call should make it difficult to refund 'bad' transactions.

Refunds should not be a common occurrence.

I can see how it might be a problem if you are instantly refunding a double spent coin with a 'good' coin.
but might it be a better solution to just queue the refund until the incoming transaction was sufficiently mature?
It's another convenience/privacy trade off.

(Should this discussion be in it's own 'Refunds' thread?)

[Anonymous]

The idea of semi anonymous bounties does seem possible after reading everyones replies.

[jgarzik]

One method of funding is using prediction markets to further the scientific and useful arts:

Prediction Markets For Promoting The Progress of Science and The Useful Arts
Tom W. Bell, 2006
http://www.tomwbell.com/writings/PredEx.pdf

[Anonymous]

One method of funding is using prediction markets to further the scientific and useful arts:

Prediction Markets For Promoting The Progress of Science and The Useful Arts
Tom W. Bell, 2006
http://www.tomwbell.com/writings/PredEx.pdf

i think someone was working on a prediction market

[jgarzik]

One of the salient points of the paper is that you can provide a bounty swarm using a prediction market.  One of the key attributes of a prediction market is permitting insider trading, to add knowledge to the market.

[waynechong1995]

Your idea could be further improved by using "plugins", like how real-time chat implemented in websites that allow visitors to further understand your requests. Your list of needed feature i guess its already available on other sites that serve different purposes.

Wonderful idea though, i never thought of this kind of implementation that resemble web freelancer services.

[erobecbea]

This is incredible idea. How long time ago nobody made it?