• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Vote: Self-sustainable Decentralized Governance by Blockchain

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.


5oOZ1C6eAoWFgSZfQ5KZ7tGfcSlbJsvA5pFPhpu3d5eIT-pYVM7IteQyXvH-5eo8-MksYwc0gan6nz9Ez6yChNqyUzij2whre5w3YGVQsYFHEVewubkIZBCSVMs8DVL-MhSFIN8


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:
I believe they sold IPOs no? Ripple labs is also a centralized organization, no? But I agree with you, it's so unclear how governments will view and deal with us. This is outside my knowledge (for good reason, I already feel a headache coming on, LOL)

So Fernando, and all you in the know of the law and taxes, can you explain what responsibilities Masternodes my incur? Thanks!

Also, are you saying we don't actually have to load our masternode wallets, just use the dash.conf in any wallet and it will be good to vote?
 
So does this mean the plans to remove the reference node are being postponed or is it now a permanent fixture?

Also I doubt it's worth spending a lot of time worrying about governmental aspects influences until we are a lot larger and publicly visible. As I am certain most legislators or bureaucrats don't even know this projects exist let alone have any plan of action regarding it. Hell it will take years for them to begin to understand, just us like with any new tech.
 
Last edited by a moderator:
I agree with thelonecrouton. This proposal will force funds into an escrow account exposed to theft/confiscation/loss/tax. The risk is higher with the more account holders (now 2500 MN). Any account holder can be accused of something "illegal" in the eyes of a government entity and it will be traced back to this account and back to all the account holders. With all the exposed IP addresses, this could get really bad.

Can we make a change to this proposal? Let's call it Project Vote. The funds go to a specific person, let's say "Evan Duffield". The purpose of the funds, "To create a voting system." Start with 1.25% distributions and end the distribution at 3 months. This can be manually stopped in 3 months for this first revision. Then at 3 months the new system will be in place to automatically set project time limits and prioritize projects by votes up to the maximum 10% project funding cap.

The numbers above don't add up. Chart says 1.25% and text says 2.5%.
 
So does this mean the plans to remove the reference node are being postponed or is it now a permanent fixture?

Also I doubt it's worth spending a lot of time worrying about governmental aspects influences until we are a lot larger and publicly visible. As I am certain most legislators or bureaucrats don't even know this projects exist let alone have any plan of action regarding it. Hell it will take years for them to begin to understand, just us like with any new tech.

Very good question. I think our #1 priority needs to be eliminating the reference node. I'd like more information on how this impacts development plans on 0.12.0.x before I vote.
 
So does this mean the plans to remove the reference node are being postponed or is it now a permanent fixture?

Also I doubt it's worth spending a lot of time worrying about governmental aspects influences until we are a lot larger and publicly visible. As I am certain most legislators or bureaucrats don't even know this projects exist let alone have any plan of action regarding it. Hell it will take years for them to begin to understand, just us like with any new tech.

This is completely unrelated to eliminating the reference node, the plan to eliminate the reference node would continue exactly the same. This initiative would work without the reference node just fine.
 
Last edited by a moderator:
Very good question. I think our #1 priority needs to be eliminating the reference node. I'd like more information on how this impacts development plans on 0.12.0.x before I vote.

This changes nothing from 0.12.0, Evan is still working on eliminating the reference node that is one of the bigger priorities at the moment.
 
I agree with thelonecrouton. This proposal will force funds into an escrow account exposed to theft/confiscation/loss/tax. The risk is higher with the more account holders (now 2500 MN). Any account holder can be accused of something "illegal" in the eyes of a government entity and it will be traced back to this account and back to all the account holders. With all the exposed IP addresses, this could get really bad.

Can we make a change to this proposal? Let's call it Project Vote. The funds go to a specific person, let's say "Evan Duffield". The purpose of the funds, "To create a voting system." Start with 1.25% distributions and end the distribution at 3 months. This can be manually stopped in 3 months for this first revision. Then at 3 months the new system will be in place to automatically set project time limits and prioritize projects by votes up to the maximum 10% project funding cap.

The numbers above don't add up. Chart says 1.25% and text says 2.5%.

Can some one explain to me why several people are so paranoid about goverments, in the sense that why in the current state of affairs would anyone care in the slightest about DASH? Maybe when we reach the 100+ million marketcap, until then I can not see any logic in worrying about governments or resonantly be able to predict the reaction, Even then if you are so petrified in your belief that this is a problem then there is a simple solution, host your node somewhere that don't require personal details. Hell if there is a problem you can always activate the node somewhere else. I feel this paranoia it has very little to do with the proposal and that your turning a feature of DASH(decentralized cold nodes) into a negative for no good reason.

So in your proposal there would simply one large central address that is exposed to theft/confiscation/loss/tax? Then your propose a reduction to 1.25%, what are the benefits of this against 2.5% as i don't see any. You need a reasonable amount to capital to get things done and 2.5% really is not that much money. This is the kind of idea that you either do it properly or don't, because half assing and only dipping a toe into the water it will result in it failing to lift off.
 
Last edited by a moderator:
I agree with thelonecrouton.

I don't. This is not a FinCEN area of jurisdiction as Dash isn't 'money' per se. And there's been no issuing of stock/equities. While, of course, all that may change in the future, at the moment, I don't believe what's being proferred here contains anything that would be cause for concern. Futhermore, as Sapereaude has noted, the likelihood of government being even remotely aware of Dash, let alone what the ramifications of it's existence are long-term, is probably next to nothing.

The numbers above don't add up. Chart says 1.25% and text says 2.5%.

Chart says 1.25% for the first supposed initial deduction (I'm guessing) if that had've been rolled out when this idea was first mooted, so it's most likely irrelevant now and 2.5% is the initial deduction that will send funds into the budget program.

All-in-all I think it's a great initiative and I'm very happy with how Evan has laid it out. I can see much thought has gone into it and that there's a strong awareness of the relative complexities of deploying it, and the need for a phased implementation. I too would like to be sure that this facility's dependence on the reference node doesn't prolong the reference node's necessity. We need to be moving on from that ASAP in order to negate the never ending use of it by trolls and naysayers as "proof" that Dash is centralised (as pathetic and lame an argument as that is; it will be nice never to have to hear about it again).

Great first steps Evan and team to getting this working; I'll be voting yea.
 
I don't. This is not a FinCEN area of jurisdiction as Dash isn't 'money' per se. And there's been no issuing of stock/equities. While, of course, all that may change in the future, at the moment, I don't believe what's being proferred here contains anything that would be cause for concern. Futhermore, as Sapereaude has noted, the likelihood of government being even remotely aware of Dash, let alone what the ramifications of it's existence are long-term, is probably next to nothing.



Chart says 1.25% for the first supposed initial deduction (I'm guessing) if that had've been rolled out when this idea was first mooted, so it's most likely irrelevant now and 2.5% is the initial deduction that will send funds into the budget program.

All-in-all I think it's a great initiative and I'm very happy with how Evan has laid it out. I can see much thought has gone into it and that there's a strong awareness of the relative complexities of deploying it, and the need for a phased implementation. I too would like to be sure that this facility's dependence on the reference node doesn't prolong the reference node's necessity. We need to be moving on from that ASAP in order to negate the never ending use of it by trolls and naysayers as "proof" that Dash is centralised (as pathetic and lame an argument as that is; it will be nice never to have to hear about it again).

Great first steps Evan and team to getting this working; I'll be voting yea.

I agree. The reference node is a silly issue....but none the less I understand. The Ripple situation is very different. I would say that at some point as someone discussed that we need to work on DASH behaving more like gold rather then fiat, down the road. if that makes sense. I too have voted! Get the vote out ;)
 
Can some one explain to me why several people are so paranoid about goverments, in the sense that why in the current state of affairs would anyone care in the slightest about DASH? Maybe when we reach the 100+ million marketcap, until then I can not see any logic in worrying about governments or resonantly be able to predict the reaction, Even then if you are so petrified in your belief that this is a problem then there is a simple solution, host your node somewhere that don't require personal details. Hell if there is a problem you can always activate the node somewhere else. I feel this paranoia it has very little to do with the proposal and that your turning a feature of DASH(decentralized cold nodes) into a negative for no good reason.

So in your proposal there would simply one large central address that is exposed to theft/confiscation/loss/tax? Then your propose a reduction to 1.25%, what are the benefits of this against 2.5% as i don't see any. You need a reasonable amount to capital to get things done and 2.5% really is not that much money. This is the kind of idea that you either do it properly or don't, because half assing and only dipping a toe into the water it will result in it failing to lift off.

The reason for the paranoia is that there are so many people getting arrested in the Bitcoin space with what seems like insignificant activities. Bitcoin is getting more traceable and the record is permanent. So as time goes by more technologies are used to go back into the blockchain to chase transactions. DASH is similar except when Darksend is used. It isn't now that matters with DASH at $3 as much as in 10 or 20 years when it is $100 or $10,000. The blockchain transactions are permanent and public, which makes tracking back overtime an issue. The confiscation of funds will happen when the wallet hits $100K or $1,000K or something significant. All that needs to happen is for it to be considered an "unlicensed money transmitter business" or "failing to report suspicious activity".

The questions we need to ask with this comingled escrow fund(not just today, but 10 or 20 years from now):
Is this a money transmitter account? (How are projects going to be paid in $? Is a proxy used to convert DASH to $)
Are we paying taxes with the funds? Are we giving out W2s or 1099s and hiring contractors? Is the project owner required to report as income? (This is a lot clearer if DASH is sent to one person directly from the block rewards. When a comingled fund pays for labor, I think this all changes.)

Hosting a node offsite still is not that answer. Your IP that you access your server is recorded. Further action could be taken with a proxy server to hide your access, but you get the point. It isn't as easy as just changing providers. I agree that I can be paranoid, but this proposal will cause problems over time. We are trying to find a solution that will last, not something that exposes all the masternode owners.

I am not saying 1.25% is the right number. The chart above says 1.25% and the text says 2.5%. I just picked one. 2.5% would be about $72,575/year at $3/DASH, not insignificant by my standards. Maybe we put in 10% for 1 month.

The last issue is that this 10% has no end. Let's vote in each project with a specific donation and timeframe. There is no mechanism stated above to return the funds if there are no projects, so inevitably this will get wasted on bad projects or abused as time goes on. (I don't think this is the intent of this proposal, but a forced donation like this will not end well even with the best intentions.)
 
I'll rebase some of my previous commentary. Relying on the masternode network with a randomized script metric is somewhat concerning. Looking around the community right now, it is easy to see that there are a few people who own a fair number of masternodes or otherwise hold influence over a fair number of masternodes. A voting system that relies on script signatures is concerning in this regard and insofar as masternodes marked as signatory may disappear at a moment's notice. The other risk is that if the network does poorly issue this script sig, the coins could be immediately forfeit, which does not reflect well on the state of the currency regardless of consequence.

As far as secondary impact, resolving DASH payments against USD at a blockchain level is questionable. This inevitably relies on a centralized service to establish this payout criteria. Anything moving towards decentralization should not rely on a service of this nature. And then there is the question of viablility of the masternode voting metric in the current release build. The "Dress" pilot vote seemed to prove that voter retention was not well established in the network, so relying on an incomplete software to make decisions is concerning.

I applaud the effort, and encourage the movement, but let's establish the service before using it to make decisions, especially when open questions like this remain. If there is immediate risk of proceeding (say pre 0.13.0 expected release) let's assess those now with a better degree of specificity, otherwise plan testnet introduction of this featureset before voting on implementation.

And here's the necessary legal aspect: certain nations require reporting of income regardless of origin for taxation. Income that is arguably earned but otherwise mandated for payment is not straightforward. Joe Schmoe (even masternode operator Joe) cannot necessarily afford legal council to ensure he's within his rights, and this can be concerning without at least some level of rehashing before forcing an implementation. By all means, roll forward with intent, but on a testnet fork, only push towards mainnet when we have community support and/or time to play with implications so those in the community can weigh in on impact in this and other regards.
 
Last edited by a moderator:
The reason for the paranoia is that there are so many people getting arrested in the Bitcoin space with what seems like insignificant activities. Bitcoin is getting more traceable and the record is permanent. So as time goes by more technologies are used to go back into the blockchain to chase transactions. DASH is similar except when Darksend is used. It isn't now that matters with DASH at $3 as much as in 10 or 20 years when it is $100 or $10,000. The blockchain transactions are permanent and public, which makes tracking back overtime an issue. The confiscation of funds will happen when the wallet hits $100K or $1,000K or something significant. All that needs to happen is for it to be considered an "unlicensed money transmitter business" or "failing to report suspicious activity".

The questions we need to ask with this comingled escrow fund(not just today, but 10 or 20 years from now):
Is this a money transmitter account? (How are projects going to be paid in $? Is a proxy used to convert DASH to $)
Are we paying taxes with the funds? Are we giving out W2s or 1099s and hiring contractors? Is the project owner required to report as income? (This is a lot clearer if DASH is sent to one person directly from the block rewards. When a comingled fund pays for labor, I think this all changes.)

Hosting a node offsite still is not that answer. Your IP that you access your server is recorded. Further action could be taken with a proxy server to hide your access, but you get the point. It isn't as easy as just changing providers. I agree that I can be paranoid, but this proposal will cause problems over time. We are trying to find a solution that will last, not something that exposes all the masternode owners.

I am not saying 1.25% is the right number. The chart above says 1.25% and the text says 2.5%. I just picked one. 2.5% would be about $72,575/year at $3/DASH, not insignificant by my standards. Maybe we put in 10% for 1 month.

The last issue is that this 10% has no end. Let's vote in each project with a specific donation and timeframe. There is no mechanism stated above to return the funds if there are no projects, so inevitably this will get wasted on bad projects or abused as time goes on. (I don't think this is the intent of this proposal, but a forced donation like this will not end well even with the best intentions.)

I'm afraid that this is no paranoia: "better safe than sorry".

I like the idea, it's exciting, but let's not jump blindly on it, because it needs polishing, and we do not need to rush. Let's study the pros and cons in order to not adventure ourselves with reckless decisions.

The idea is great, I know it, but the solution is almost there: We do not want it to be palliative. We want it to be good long term.

Let's open our ears and listen to all opinions... and only then decide/vote :)
 
Last edited by a moderator:
"US Financial Crimes Enforcement Network (FinCEN) director Jennifer Shasky Calvery said during a speech today that her agency is in the process of investigating businesses in the digital currency ecosystem......"

http://www.coindesk.com/fincen-director-examiniation-digital-currency/

I hope we're not becoming a "digital currency business" as defined by the US govt here... Where're Dash lawyers?
This endeavor of allocating funds towards developers, regardless of how well-intentioned or well-implemented would inevitably draw further attention in this regard.
 
...And here's the necessary legal aspect: certain nations require reporting of income regardless of origin for taxation. Income that is arguably earned but otherwise mandated for payment is not straightforward. Joe Schmoe (even masternode operator Joe) cannot necessarily afford legal council to ensure he's within his rights, and this can be concerning without at least some level of rehashing before forcing an implementation. By all means, roll forward with intent, but on a testnet fork, only push towards mainnet when we have community support and/or time to play with implications so those in the community can weigh in on impact in this and other regards.

If the block rewards go directly to a project owner, the project owner has the obligation to report their own income, correct? (Wouldn't this eliminate any tax implications from DASH? This is essentially mining.)

If the block rewards go to a fund and that fund pays a project owner then the fund owner may be required to report income and/or report income paid to the project owner, correct? (This would essentially, force a bunch of (current or future) tax paperwork on the fund owner we don't want.)
 
RE: the projects being estimated in fiat but being paid in DASH is only so that the amount of DASH at the time equals the fiat equivalent. Lets say that someone bids 1000 Euros to do a job, we grant him the job, but from the time the job is granted to the time the job is done, say DASH goes up 200% in price. Then we simply pay him the equivalent of 1000 Euros current exchange rate. That's all.

I don't know the answer to your question, Solarminer, but I hope someone on the team who is either a tax specialist or lawyer can answer.
 
Back
Top