There were harsh words written about TBF's plans of using its financial resources to hire lobbyist instead of paying programmers for a testing and development of the Bitcoin system. My solution was, (i) create a tool for Bitcoiners to finance the system development through crowd financing (voting with money) and (ii) let TBF spend their money on lobbyists and die.
I made a draft picture of how such a crowd financing website might look like https://bitcointalksearch.org/topic/m.2209663
Topic: Developer Grant (Bounty) Allocation Through Proof Of Stake Voting (Read 2186 times)
August 06, 2013, 12:07:46 AM
So this is implemented now in MemoryCoin and has been running for the past few days.
https://bitcointalksearch.org/topic/ann-memorycoin-267522
Technically it seems to be working well, but I don't think many users understand the voting or its benefits yet.
https://bitcointalksearch.org/topic/ann-memorycoin-267522
Technically it seems to be working well, but I don't think many users understand the voting or its benefits yet.
I didn't get a lot of feedback on this, so I'll assume it is perfect 
as is and plough on with the implementation. Send me a private message to be included in the Beta.
as is and plough on with the implementation. Send me a private message to be included in the Beta. 
Similarly, this does not solely apply to development. I think that's the use-case that is easiest to understand, but we might see coin owners choose to support a foundation, or a charity.
Actually the model that CIYAM Open uses (http://ciyam.org/open) is exactly like this - not an "all or nothing kickstarter" but instead people donating funds to projects, project areas or to specific project tasks (at this stage donations are *not* refundable but support for refundable donations via escrow can be handled).
It could easily be applied to a non-profit organisation where all funding and spending could be traced publicly via the blockchain.
It looks like you're working on a 'Kickstarter for Bitcoin'. I think that has merits and different strengths and weaknesses to the project I'm looking at.
With your idea, the projects come first, and then seek funding. That can work, but projects have a lot of work to do fundraising.
My idea is to create a constant stream of funding in the block-chain. Coin owners don't have to decide whether or not to support a project - some projects will be funded regardless - they just have the power to decide which ones.
There are no middlemen, no admin, no gatekeepers, no bureaucracy. Grant applicants apply, coin owners vote.
Similarly, this does not solely apply to development. I think that's the use-case that is easiest to understand, but we might see coin owners choose to support a foundation, or a charity.
With your idea, the projects come first, and then seek funding. That can work, but projects have a lot of work to do fundraising.
My idea is to create a constant stream of funding in the block-chain. Coin owners don't have to decide whether or not to support a project - some projects will be funded regardless - they just have the power to decide which ones.
There are no middlemen, no admin, no gatekeepers, no bureaucracy. Grant applicants apply, coin owners vote.
Similarly, this does not solely apply to development. I think that's the use-case that is easiest to understand, but we might see coin owners choose to support a foundation, or a charity.
I am working on something that could take care of this very well except it would have a precursor to Step 1.
Step 0. A goal is set and bitcoin owners pledge the amount that they are willing to contribute toward that goal.
Then several developers can submit proposals. A criteria will be set for taking on the proposal.
Then the proposal that appears to be the best to the bitcoin owners will be voted on. If the criteria is met, the proposal is awarded.
Your technical problem is solved by the software and the behavior problem is solved via escrow.
I believe that the idea of people pledging toward a problem first is easier than first presenting a solution and then asking for funds. This does not apply solely to development either.
See my signature for more.
Step 0. A goal is set and bitcoin owners pledge the amount that they are willing to contribute toward that goal.
Then several developers can submit proposals. A criteria will be set for taking on the proposal.
Then the proposal that appears to be the best to the bitcoin owners will be voted on. If the criteria is met, the proposal is awarded.
Your technical problem is solved by the software and the behavior problem is solved via escrow.
I believe that the idea of people pledging toward a problem first is easier than first presenting a solution and then asking for funds. This does not apply solely to development either.
See my signature for more.
I have an idea to allow for grants (bounties) to be voted on by coin owners and awarded in the block chain.
I envisage grants being awarded to developers working on projects related to the coin, or groups working for the benefit of the coin.
I want to avoid adding too much code, on the assumption that the more code I add, the more errors I'll introduce.
How it would work.
Here's what I've come up . . . and I'm seeking feedback on its merits, technical and otherwise. I'm assuming implementation in an altcoin, say Grantcoin, but I'll use Bitcoin friendly numbers.
Step 1. Grant Proposal.
A developer seeking a grant creates a vanity address of the form gGRANTXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX and sends a small amount of coin to get it into the block chain.
He advertises his proposed project to the community and requests coin owners to vote for his grant allocation.
(No code change required)
Step 2. Voting.
Coin owners wishing to vote for a grant allocation send a small amount to the grant allocation address GGRANTXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX. Coin owners can vote for multiple projects and set an order of preference by sending a larger amount of coin to preferred projects.
Example. A coin owner might like 5 grant proposals and vote for them in order of preference by sending
Preference 1 - .00000020 coin to GGRANT11XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Preference 2 - .00000015 coin to GGRANT06XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Preference 3 - .00000010 coin to GGRANT07XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Preference 4 - .00000006 coin to GGRANT22XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Preference 5 - .00000002 coin to GGRANT56XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
(Small code change required, technical problem 1 - see below)
Step 3. Grant Award.
Once a day, say every 144 blocks, votes are tallied, and the top 3 grant vote winners are awarded a fixed amount in that block, say 20 Coins.
Voting is proportionate to the amount of coin currently in the address from which the grant allocation address received. Voting is by transferable vote, similar to STV, but taking the size of voter's stake in the coin into account.
http://en.wikipedia.org/wiki/Single_transferable_vote
(Medium code addition - code to calculate vote winners and add reward to block. Must be 100% deterministic.)
Step 4. Vote Changes
Coin owners can leave their votes unchanged for the next day's voting, or add new preferences by sending coin to new or existing preferences.
(No code changes required)
Technical Problem 1
Usually change is sent to a different address than the sending address. This would make the vote worthless, as there would be no coin left in sending address. I propose to remedy that by changing the default client to always send change back to the sending address. There's a hit to anonymity.
Behavior Problem 1
Developers may not deliver on their promises. I don't see an easy way to resolve this. I propose we leave it up to the community and coin owners to evaluate the credibility and trustworthiness of grant applicants.
So I'm interested if you can see any other technical problems that might arise, or problem behavior that this allocation system would be likely to encourage.
I envisage grants being awarded to developers working on projects related to the coin, or groups working for the benefit of the coin.
I want to avoid adding too much code, on the assumption that the more code I add, the more errors I'll introduce.
How it would work.
Here's what I've come up . . . and I'm seeking feedback on its merits, technical and otherwise. I'm assuming implementation in an altcoin, say Grantcoin, but I'll use Bitcoin friendly numbers.
Step 1. Grant Proposal.
A developer seeking a grant creates a vanity address of the form gGRANTXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX and sends a small amount of coin to get it into the block chain.
He advertises his proposed project to the community and requests coin owners to vote for his grant allocation.
(No code change required)
Step 2. Voting.
Coin owners wishing to vote for a grant allocation send a small amount to the grant allocation address GGRANTXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX. Coin owners can vote for multiple projects and set an order of preference by sending a larger amount of coin to preferred projects.
Example. A coin owner might like 5 grant proposals and vote for them in order of preference by sending
Preference 1 - .00000020 coin to GGRANT11XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Preference 2 - .00000015 coin to GGRANT06XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Preference 3 - .00000010 coin to GGRANT07XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Preference 4 - .00000006 coin to GGRANT22XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Preference 5 - .00000002 coin to GGRANT56XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
(Small code change required, technical problem 1 - see below)
Step 3. Grant Award.
Once a day, say every 144 blocks, votes are tallied, and the top 3 grant vote winners are awarded a fixed amount in that block, say 20 Coins.
Voting is proportionate to the amount of coin currently in the address from which the grant allocation address received. Voting is by transferable vote, similar to STV, but taking the size of voter's stake in the coin into account.
http://en.wikipedia.org/wiki/Single_transferable_vote
(Medium code addition - code to calculate vote winners and add reward to block. Must be 100% deterministic.)
Step 4. Vote Changes
Coin owners can leave their votes unchanged for the next day's voting, or add new preferences by sending coin to new or existing preferences.
(No code changes required)
Technical Problem 1
Usually change is sent to a different address than the sending address. This would make the vote worthless, as there would be no coin left in sending address. I propose to remedy that by changing the default client to always send change back to the sending address. There's a hit to anonymity.
Behavior Problem 1
Developers may not deliver on their promises. I don't see an easy way to resolve this. I propose we leave it up to the community and coin owners to evaluate the credibility and trustworthiness of grant applicants.
So I'm interested if you can see any other technical problems that might arise, or problem behavior that this allocation system would be likely to encourage.
Jump to: