eduffield
Core Developer
Hello Everyone!
It seems that we have a great deal of support for our recently proposed "Self Sustainable and decentralized governance by Blockchain" initiative and that's fantastic because we believe this will be a game changer for crypto, making it much more decentralized and capable of mass-adoption. However, we won't really know if the community wants the program until we vote on it, so I'm going to open voting. This vote requires 51% of the masternodes to success.
After careful consideration from the community and looking at our current/future expenses, we’ve decided to reduce the budget program to 10% of the reward. As the program delivers results, then we are hoping price appreciation should compensate for the difference and it will still leave some upside for masternode operators to enjoy later on. So the next revenue share increases would go towards the masternode budget program and the last two would still go to masternode operators.
We also want the decentralized governance program to start slow, so we as a community have time to go through the learning curve of a new feature. This is why the program would start only with 2.5% and then follow the same reward schedule that we already had in place.
Some changes to the Budget strategy
Some members of the community have brought up a critical issue with the way the system is designed. For example, say someone makes a proposal for receiving $1000 to pay for a marketing campaign. With the original design the user would receive about 300DASH.
Problem 1: However, what if the price appreciates 20% while they're getting funded? What happens to the other 20% that is left over?
Problem 2: Or worse, what happens if the price falls 20% while they're getting funded? Now the person doesn't have enough money and would require getting refunded.
Problem 3: From a technical perspective it's very difficult to make a system to enforce these payments, especially in a decentralized way.
Solution:
Instead of paying multiple addresses directly from the blockchain, I propose we make a "masternode escrow account". This will be a new type of account, that will require a quorum of masternodes to make transactions from. For example, it might require 30 random signatures from random masternodes, to make a transaction to pay for a specific proposal.
This type of masternode account means the masternode network can hold it's own money. It has many uses for us and will be extremely useful in the future for many different applications, e.g. it would be necessary for our decentralized web wallet idea.
However, we're not ready to make that masternode multisig account yet, as it will take a good deal of groundwork. So as an interim solution, we would like to use a 10-15 person multisig, where many of the most trusted community members will each have a key. Moving money out of this account would require at least 7-10 signatures. These community members would simply run a daemon with a specific parameter (masternodeaccountkey=YOURKEY), then when a budget is approved their daemon would use special protocol messages to sign the transactions. While not a perfect solution, it should work well as a first step and be very secure.
Payment Schedule, Scoring and Volatility
Being that all money will go to an escrow account, the system will be designed to approve budgets once a month. The system will order all active proposals, then pay them in order by YES count, until a proposal can't be paid in full or no proposal fulfils the minimum required criteria.
Due to the decentralized nature of the system, it will be very difficult to update a proposal and adjust the amount paid out. Due to this restriction, it's best if we denominate all proposals in USD. This means that if the price of DASH changes, up or down, the proposal will still pay the correct amount.
Here's how this is going to work if the vote passes:
We're going to implement the budgeting software in a 4 phase process. This budgeting system is going to be very complicated and difficult to implement, so it's going to take some time. In order to do this in a safe way, we're going to roll it out in multiple phases.
Phase 1.) v11 - We will patch the reference node to pay 2.5% of the block reward to the budget program. The schedule would remain the same, except further increases would be paid to the budget program and the last two would again go to masternodes.
We can use the existing voting system to vote on the first proposals, then if needed we can make manual transactions from the multisig account.
Phase 2.) v12.0 - This will be the first semi-automatic version of the budgeting system. Masternodes will be able to vote on multiple proposals at any time. The multisig account operators will then manually make payments from the multisig account.
Phase 3.) v12.1 - This will include the "budgetkey=" parameter which will automate the process of paying the budget.
Phase 4.) v? - At some point in the future, the masternode network will be capable of holding it's own money and we can move the budget multisig to their network account.
Payment Schedule
To put the budget into effect, the system would pay the escrow account its percentage of the block rewards. This would be done in phases as the original masternode reward increases called for.
With this revised schedule the masternode program still has a pending 5% reward share to grow and strengthen the network.
How To Vote
To vote, simply copy your masternode.conf into your dash directory, open the software then execute the command “masternode vote-many yea” or “masternode vote-many nay”.
To vote with a single masternode you can use the command “masternode vote yea” or “masternode vote nay”.
To view the voting progress you will need to update your client due to a bug in the current version that clears out votes after 8 hours. Once you update this will not be an issue, the command to view the voting progress is “masternode list votes”. This is not a mandatory update, masternodes do not need to update, only users that want to follow the vote on their clients.
Voting will begin immediately and be open for 2 weeks. We will consider the vote successful if at any time we have 51% of the masternodes support.
To update visit https://www.darkcoin.io/downloads, this update is NOT required for anyone but those that would like to view the progress of the vote.
--
An update to the proposal (May 8, 2015): https://dashtalk.org/threads/vote-s...vernance-by-blockchain.4825/page-4#post-53665
It seems that we have a great deal of support for our recently proposed "Self Sustainable and decentralized governance by Blockchain" initiative and that's fantastic because we believe this will be a game changer for crypto, making it much more decentralized and capable of mass-adoption. However, we won't really know if the community wants the program until we vote on it, so I'm going to open voting. This vote requires 51% of the masternodes to success.
After careful consideration from the community and looking at our current/future expenses, we’ve decided to reduce the budget program to 10% of the reward. As the program delivers results, then we are hoping price appreciation should compensate for the difference and it will still leave some upside for masternode operators to enjoy later on. So the next revenue share increases would go towards the masternode budget program and the last two would still go to masternode operators.
We also want the decentralized governance program to start slow, so we as a community have time to go through the learning curve of a new feature. This is why the program would start only with 2.5% and then follow the same reward schedule that we already had in place.
Some changes to the Budget strategy
Some members of the community have brought up a critical issue with the way the system is designed. For example, say someone makes a proposal for receiving $1000 to pay for a marketing campaign. With the original design the user would receive about 300DASH.
Problem 1: However, what if the price appreciates 20% while they're getting funded? What happens to the other 20% that is left over?
Problem 2: Or worse, what happens if the price falls 20% while they're getting funded? Now the person doesn't have enough money and would require getting refunded.
Problem 3: From a technical perspective it's very difficult to make a system to enforce these payments, especially in a decentralized way.
Solution:
Instead of paying multiple addresses directly from the blockchain, I propose we make a "masternode escrow account". This will be a new type of account, that will require a quorum of masternodes to make transactions from. For example, it might require 30 random signatures from random masternodes, to make a transaction to pay for a specific proposal.
This type of masternode account means the masternode network can hold it's own money. It has many uses for us and will be extremely useful in the future for many different applications, e.g. it would be necessary for our decentralized web wallet idea.
However, we're not ready to make that masternode multisig account yet, as it will take a good deal of groundwork. So as an interim solution, we would like to use a 10-15 person multisig, where many of the most trusted community members will each have a key. Moving money out of this account would require at least 7-10 signatures. These community members would simply run a daemon with a specific parameter (masternodeaccountkey=YOURKEY), then when a budget is approved their daemon would use special protocol messages to sign the transactions. While not a perfect solution, it should work well as a first step and be very secure.
Payment Schedule, Scoring and Volatility
Being that all money will go to an escrow account, the system will be designed to approve budgets once a month. The system will order all active proposals, then pay them in order by YES count, until a proposal can't be paid in full or no proposal fulfils the minimum required criteria.
Due to the decentralized nature of the system, it will be very difficult to update a proposal and adjust the amount paid out. Due to this restriction, it's best if we denominate all proposals in USD. This means that if the price of DASH changes, up or down, the proposal will still pay the correct amount.
Here's how this is going to work if the vote passes:
We're going to implement the budgeting software in a 4 phase process. This budgeting system is going to be very complicated and difficult to implement, so it's going to take some time. In order to do this in a safe way, we're going to roll it out in multiple phases.
Phase 1.) v11 - We will patch the reference node to pay 2.5% of the block reward to the budget program. The schedule would remain the same, except further increases would be paid to the budget program and the last two would again go to masternodes.
We can use the existing voting system to vote on the first proposals, then if needed we can make manual transactions from the multisig account.
Phase 2.) v12.0 - This will be the first semi-automatic version of the budgeting system. Masternodes will be able to vote on multiple proposals at any time. The multisig account operators will then manually make payments from the multisig account.
Phase 3.) v12.1 - This will include the "budgetkey=" parameter which will automate the process of paying the budget.
Phase 4.) v? - At some point in the future, the masternode network will be capable of holding it's own money and we can move the budget multisig to their network account.
Payment Schedule
To put the budget into effect, the system would pay the escrow account its percentage of the block rewards. This would be done in phases as the original masternode reward increases called for.
With this revised schedule the masternode program still has a pending 5% reward share to grow and strengthen the network.
How To Vote
To vote, simply copy your masternode.conf into your dash directory, open the software then execute the command “masternode vote-many yea” or “masternode vote-many nay”.
To vote with a single masternode you can use the command “masternode vote yea” or “masternode vote nay”.
To view the voting progress you will need to update your client due to a bug in the current version that clears out votes after 8 hours. Once you update this will not be an issue, the command to view the voting progress is “masternode list votes”. This is not a mandatory update, masternodes do not need to update, only users that want to follow the vote on their clients.
Voting will begin immediately and be open for 2 weeks. We will consider the vote successful if at any time we have 51% of the masternodes support.
To update visit https://www.darkcoin.io/downloads, this update is NOT required for anyone but those that would like to view the progress of the vote.
--
An update to the proposal (May 8, 2015): https://dashtalk.org/threads/vote-s...vernance-by-blockchain.4825/page-4#post-53665
Last edited by a moderator:
