Hi Drawoc - the Project Creator sets the time frame to be met so say it is - 10 Btc in say 15 days - if 15 days pass and 10 Btc is pledged to the project then the project is labeled a success and funding is released to the Project Creator. Hopefully, this helps.

Hi Drawoc - the Project Creator sets the time frame to be met so say it is - 10 Btc in say 15 days - if 15 days pass and 10 Btc is pledged to the project then the project is labeled a success and funding is released to the Project Creator. Hopefully, this helps.

Oh, so is this for funding projects before they've started? I initially got the impression that it was more for pledging money for a project, and after the project was finished, the person who completed the project receives a bounty.

Hi Drawoc - the Project Creator sets the time frame to be met so say it is - 10 Btc in say 15 days - if 15 days pass and 10 Btc is pledged to the project then the project is labeled a success and funding is released to the Project Creator. Hopefully, this helps.

Oh, so is this for funding projects before they've started? I initially got the impression that it was more for pledging money for a project, and after the project was finished, the person who completed the project receives a bounty.

It is pledging for a project before it is started with only a few differences in that it has to meet some requirements to do so. In this case, the amount needed in Bitcoins (10 BTC) and days (15 days) to reach it . Really, no different then the pledging you are mentioning above.

There is one other difference the Project Creator offer's ( optional ) incentives to pledge and in return the "pledger" gets the rewards mentioned for his/her pledge. All in all it is basically the same.

It is pledging for a project before it is started with only a few differences in that it has to meet some requirements to do so. In this case, the amount needed in Bitcoins (10 BTC) and days (15 days) to reach it . Really, no different then the pledging you are mentioning above.

There is one other difference the Project Creator offer's ( optional ) incentives to pledge and in return the "pledger" gets the rewards mentioned for his/her pledge. All in all it is basically the same.

It is pledging for a project before it is started with only a few differences in that it has to meet some requirements to do so. In this case, the amount needed in Bitcoins (10 BTC) and days (15 days) to reach it . Really, no different then the pledging you are mentioning above.

There is one other difference the Project Creator offer's ( optional ) incentives to pledge and in return the "pledger" gets the rewards mentioned for his/her pledge. All in all it is basically the same.

Sure! Python for web is quite easy to learn, if you already know Python (especially advanced stuff like you did) that's the most important part.

My ideas:

People can post a new bounty, or add to an existing one (all in escrow, of course, to make sure payouts happen).

For each bounty there needs to be a (or more) "moderators" that decide if the bounty can be claimed, or that rework still needs to be done. Moderators should be developers, so that code quality is also looked at.

A developer that has done some work on a bounty can post his initial work to prove that he is working on it; it might be that this still requires rework, but moderators can "lock" the bounty in his name so no one else can claim it in the meantime.

Each bounty must have a "due date", by which the posters get back their escrowed money if there is no initial submission by then

They system should have a (primitive) discussion thread on each bounty to discuss requirements etc.

Registration / authentication simply using OpenID

Maybe we should ask for this topic to be moved to Project Development?

Bitcoin Core developer [PGP]Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.

A developer that has done some work on a bounty can post his initial work to prove that he is working on it; it might be that this still requires rework, but moderators can "lock" the bounty in his name so no one else can claim it in the meantime.

Yes but only for a short time, depending on the trustworthiness value of that developer. Maybe have milestones for larger projects.We'll also have to watch out for scumbags submitting copyrighted code from other projects as their own and it being released under an incompatible license.

Each bounty must have a "due date", by which the posters get back their escrowed money if there is no initial submission by then

Yep, I'm thinking that each project has an address and we just post the funds back to the address that sent them, so there's no need for people to register accounts to donate. Completed projects would have new funds posted directly to the person who completed the task. Not sure about new funds, maybe new funds being added should re-open / extend a project, or maybe they're just posted back to the address that sent them.

They system should have a (primitive) discussion thread on each bounty to discuss requirements etc.

I think the requirements should be set in stone when the project is created. We're dealing with donations from many people who are donating because they agree with the requirements. This is horribly bureaucratic but IMO the only way to do it fairly.

Absolutely, I hate sites that force me to sign up with a new password, almost as much as I hate having to store user passwords!

Thinking of security, would it be possible to write the platform in a way which prevents the site owners, moderators and any intruders from having access to the funds? For example we could encrypt the private key with a "project key" (owned by the site) and a "sponsor key" (one sponsor per donation address, potentially many per project). Once the site moderators agree that the requirements have been met, the project sponsors enter their key and the funds are released. Or maybe something is possible using scripting?

This would have the down-side of projects running forever and funds potentially being lost if the sponsors disappear, as we couldn't close a project without knowing the sponsor key. But it would IMO be a better option than running an escrow site given all the recent hackings!

Thinking of security, would it be possible to write the platform in a way which prevents the site owners, moderators and any intruders from having access to the funds?

You could generate a new address every time that a sponsor wants to sponsor a project. Then when payment arrives, generate one transaction for every possible outcome (one transaction that sends the bitcoins back to the sponsor, and one that sends it to the developer) but don't broadcast them. After that, you delete the address' private key. When the outcome is determined (bounty should be sent to developer or returned to sponsor), simply broadcast that transaction on the network.

This way, the most damage an attacker could do would be to choose whether the bounty went to the developer or the sponsor. The attacker could never send any of the coins to himself (unless he was the dev/sponsor).

This has a few downsides:

If the sponsor sends coins to an address after its private key is destroyed, those coins are gone.

You still keep the private key around until a payment is received.

All developers must be known before the bounty is moved to escrow. Any developer that appears late in the game cannot collect bounties held in escrow before he started work on a project.

It would be nice if we could create transactions that said to forward all funds sent to one address, present and future, to another address. That would kill problems 1 and 2. (Also useful for ex. importing an untrusted address into one's wallet.) If this isn't possible currently w/ script, it sure would be nice to see implemented. (Bounty anyone? Gotta love irony.)

Thinking of security, would it be possible to write the platform in a way which prevents the site owners, moderators and any intruders from having access to the funds?

You could generate a new address every time that a sponsor wants to sponsor a project. Then when payment arrives, generate one transaction for every possible outcome (one transaction that sends the bitcoins back to the sponsor, and one that sends it to the developer) but don't broadcast them. After that, you delete the address' private key. When the outcome is determined (bounty should be sent to developer or returned to sponsor), simply broadcast that transaction on the network.

This way, the most damage an attacker could do would be to choose whether the bounty went to the developer or the sponsor. The attacker could never send any of the coins to himself (unless he was the dev/sponsor).

This has a few downsides:

If the sponsor sends coins to an address after its private key is destroyed, those coins are gone.

You still keep the private key around until a payment is received.

All developers must be known before the bounty is moved to escrow. Any developer that appears late in the game cannot collect bounties held in escrow before he started work on a project.

It would be nice if we could create transactions that said to forward all funds sent to one address, present and future, to another address. That would kill problems 1 and 2. (Also useful for ex. importing an untrusted address into one's wallet.) If this isn't possible currently w/ script, it sure would be nice to see implemented. (Bounty anyone? Gotta love irony.)

1 and 2 is doable using the current system:Upon receiving some funds you can create an temporary address/private key pair, send the funds to this new address, and use the generated private key to generate the two outgoing transactions. Now store both transactions and throw away the temporary private key. That way the original address does not vanish and so no coins will be lost.

1 and 2 is doable using the current system:Upon receiving some funds you can create an temporary address/private key pair, send the funds to this new address, and use the generated private key to generate the two outgoing transactions. Now store both transactions and throw away the temporary private key. That way the original address does not vanish and so no coins will be lost.

This idea rocks! Are there any escrow services that use this method? If not, there should be!

1 and 2 is doable using the current system:Upon receiving some funds you can create an temporary address/private key pair, send the funds to this new address, and use the generated private key to generate the two outgoing transactions. Now store both transactions and throw away the temporary private key. That way the original address does not vanish and so no coins will be lost.

1 and 2 is doable using the current system:Upon receiving some funds you can create an temporary address/private key pair, send the funds to this new address, and use the generated private key to generate the two outgoing transactions. Now store both transactions and throw away the temporary private key. That way the original address does not vanish and so no coins will be lost.

Are there any escrow services that use this method? If not, there should be!

Agreed. Maybe we should contact Btcrow, and suggest it to them? (I don't think anyone's using it yet.)

I'm taking this proposal as an idea to possibly working on. The only thing pop me in mind is, Is this method won't be to hard for the average user ? I wanna keep every escrowed transactions easy for everyone.

I'm taking this proposal as an idea to possibly working on. The only thing pop me in mind is, Is this method won't be to hard for the average user ? I wanna keep every escrowed transactions easy for everyone.

Well, the idea is that this happens behind the scenes on the server side. The users might not even know you're doing it. The goal is that anyone who now hacks your server can't send the bitcoins to themself, only to one of the parties in the transaction. In other words, it becomes impossible for anyone to steal bitcoins off of the server, thus increasing security.

BitcoinStarter.com will entertain any kind of project even smaller ones - I agree elementary usability features would be very helpful to the community to have.

Any time frame on when this will be ready?Will it hold the pledged bitcoins in escrow?

Earliest this weekend ( this is my goal at least! ) and latest at the end of this month. The pledged Bitcoins will be held in escrow and released if project is successful. If not successful all Bitcoins are returned to their perspective pledgers.