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

Self-sustainable Decentralized Governance by Blockchain

Sure, but what uptime do I need to establish the validity of my vote? Surely I can't jsut tart a node, vote, move the funds to a new address, start that one, vote again... As the democrats say; vote early, vote often... I the damn thing won't run long enough to even get a payment, can it still vote? Is that good or bad?
Maybe a way to do this would be to say only masternodes that have been active for 2+ weeks can vote. It would be impossible to vote, move funds to another node and run more than 2 weeks in a 2 week voting period.

There must be something wrong with your 4 crashing nodes. My nodes have been going strong since the last update. I think you are still in the payment queue if you don't shutdown for more than an hour. You could setup a restart script to run every hour, but you would be better off fixing the nodes or finding a new host.
 
The problem I have with your perspective:

It's impossible to put it back accurately and fairly once you take it.

The MNs are responsible for the vote. They're the ones involved. It should come from their piece of the pie.

It makes absolutely no sense at all for the MNs to pay it, but it "go back" to anyone other than themselves. They paid it, it wasn't used, it should "go back" to them.

etc.
I would like to see the setup of this project as simple as possible, but no simpler :) So what are the inherent flaws in this setup - and can they be overcome by oversight? DAO = Distributed Autonomous Organization :)


15% of block rewards are awarded the DAO. The Masternodes approve payments requested from the core developers and marketing sections of DASH working under the Foundation's oversight.


Projects may be submitted by developers or created by the community and sent out to bid. Masternodes vote on these projects and if approved AND funds are available, the projects get the green light.


At the end of each year, funds that are not used up are set aside in another account and distributed back into the network 1/210240 of the total at each block reward, redistributing it fairly back into the system.


Or this could be done every 2 years if a back up savings account is desired. This way there is a small but not huge incentive to save money, especially when dash becomes worth so much that it would be wasteful to spend it all.


Masternode voting, for practicality, would be at least 2/3 of masternodes participating and 51% or more yays to approve a project. There probably should be a way for masternode owners to give their votes to trusted entities, if they are not willing to study the propositions and vote. They could designate a person whom they trust and have them vote for them.


This would be desirable if we can't get 2/3 of the voting shares to participate. It's not easy to keep up on projects and be aware of all considerations. Perhaps the trusted voter could be the foundation (your shares would go whichever way the foundation is swinging? I suggest this option only because I see MN owners not keeping up with what is going on? I may be wrong here??

I honestly don't see us getting 2/3 participation from the MN owners. I think that's another issue we are going to have to consider. Do we subject votes to a quorum? If so, what's the quorum and how do we achieve it? In the United States, voter turnout in midterm elections is usually on the order of 25-30%.
 
I would like to see the setup of this project as simple as possible, but no simpler :) So what are the inherent flaws in this setup - and can they be overcome by oversight? DAO = Distributed Autonomous Organization :)


15% of block rewards are awarded the DAO. The Masternodes approve payments requested from the core developers and marketing sections of DASH working under the Foundation's oversight.


Projects may be submitted by developers or created by the community and sent out to bid. Masternodes vote on these projects and if approved AND funds are available, the projects get the green light.


At the end of each year, funds that are not used up are set aside in another account and distributed back into the network 1/210240 of the total at each block reward, redistributing it fairly back into the system.


Or this could be done every 2 years if a back up savings account is desired. This way there is a small but not huge incentive to save money, especially when dash becomes worth so much that it would be wasteful to spend it all.


Masternode voting, for practicality, would be at least 2/3 of masternodes participating and 51% or more yays to approve a project. There probably should be a way for masternode owners to give their votes to trusted entities, if they are not willing to study the propositions and vote. They could designate a person whom they trust and have them vote for them.


This would be desirable if we can't get 2/3 of the voting shares to participate. It's not easy to keep up on projects and be aware of all considerations. Perhaps the trusted voter could be the foundation (your shares would go whichever way the foundation is swinging? I suggest this option only because I see MN owners not keeping up with what is going on? I may be wrong here??
I am just going to go off a little, don't take this personally.
How much will it cost to maintain this DAO? Who owns it? It needs to have a wallet. Is this a multisig wallet that 2000 masternode owners sign? If not than why should we trust a few members with wallet ownership. (Now and more importantly in the future when this is $millions) Oops wallet was hacked again and we lost all the funds! Now that there is a DAO, does it need to pay taxes before paying for a service or product? A direct blockchain payment should be treated like a mining reward - not taxed.

Again I disagree with the 15% coming off the top without any voting. The votes need to allocate the amount of funds specific to each project. Otherwise, you have funds sitting around ready to be "lost" or just used ineffectively.

I believe masternode owners are very active. They update their masternodes in just a few days. They need to be looking at these forums to see wallet releases. If a vote of 2/3 is hard to get then make is 25% for approval and 51% for unapproved. Or whatever the combination that works. Or make it a vote over a month, but I think 2 weeks is more appropriate since wallet updates are almost 100% in 1 week. I also think there will be some development projects(coin critical) that will be automatically move forward with 0 votes but could be stopped with a 51% no vote.
 
I honestly don't see us getting 2/3 participation from the MN owners. I think that's another issue we are going to have to consider. Do we subject votes to a quorum? If so, what's the quorum and how do we achieve it? In the United States, voter turnout in midterm elections is usually on the order of 25-30%.

IMHO:
I see lots of problems if just some part (51%, 2/3, ...) of all MN ops will decide for any other ops who didn't vote becaurse of any reason (so majority will manage 100% of funds - is a problem).

Each MN owner should manage-vote only about their own part in RD&Marketing budget! This is the only fair system.

But If some MN ops can't decide for 1-2 years where their part will go - this money should go from them to system (to Official foundation or to miners - but not back to MNs).
 
IMHO:
I see lots of problems if just some part (51%, 2/3, ...) of all MN ops will decide for any other ops who didn't vote becaurse of any reason (so majority will manage 100% of funds - is a problem).

Each MN owner should manage-vote only about their own part in RD&Marketing budget! This is the only fair system.

But If some MN ops can't decide for 1-2 years where their part will go - this money should go from them to system (to Official foundation or to miners - but not to MNs again).
I don't see an incentive for a masternode to vote a donation amount to a project that may or may not go forward. It is a better incentive to put a specific feature and specific donation amount up to a vote. Once the votes get to a certain threshold the project moves forward and funds pulled. Otherwise, a few masternodes fund the project and it is half funded? now what?

If a MN owner wants to fund a specific project, great, they can send a direct payment. We don't need voting to do manage that.

The crypto voting mechanism is a real game changer. We will see the brilliance of it very soon.
 
Whatever is decided, we need to trial run it somehow, and re-evaluate at the end of the term. That way, if something simply isn't working as designed, we can scrap it and try another way.

Also, keep in mind with the "vote first, then save money" scenario, development will take considerably longer as we will have to vote ===> save money ===> start project, whereas the other way we just vote ===> start project.

A readily accessible fund, if managed properly, would be better for timely implementation of projects.
 
Last edited by a moderator:
I don't see an incentive for a masternode to vote a donation amount to a project that may or may not go forward.
It is the simple incentive - each MN op is owner of 1000 DASH so interested in price rising so interested in most effective (as he thinks) development and promotion.

"People are greedy" - it is a fact and it is normal.
In case of individual donations this fact works always against us.
In case of system Evan has offered - this fact will always work for us.

His offer - great sample of the correct system approach.

It is a better incentive to put a specific feature and specific donation amount up to a vote. Once the votes get to a certain threshold the project moves forward and funds pulled. Otherwise, a few masternodes fund the project and it is half funded? now what?

Have a look at thelonecrouton's arguments - If there is no good (as I think) project at the moment are offered - I'd better accumulate "my RD&Marketing votes=funds" for future great projects but not spend it immediately and ineffective...
 
Last edited by a moderator:
It is the simple incentive - each MN op is owner of 1000 DASH so interested in price rising so interested in most effective (as he thinks) development and promotion.

Have a look at thelonecrouton's arguments - If there is no good (as I think) project at the moment are offered - I'd better accumulate "my RD&Marketing votes=funds" for future great projects but not spend it immediately and ineffective...

I agree Masternodes will donate to projects that make sense and raise the value of DASH. The problem is that I don't want to donate to 18 projects that get 1/4 funded and never happen. I want to donate to a project that will be completed because it will get the funds it needs. The voting system makes a consensus for the best projects and diverts funds to only those.

Putting it another way, would you preorder a bitcoin miner? What were the chances of getting a miner last year? How many companies went bankrupt, didn't deliver, or were late? So why should I donate to a project that might not get funded with enough to finish and get left with nothing.

If there is no good project now, I don't want to donate anything. The idea of collecting funds and then distributing them is the same government/banking system we have now. How does that turn out? People that hold the money make the laws/rules. We can do better.

If a really good idea came through and it needed 30% funding or something. Then we can vote on the project and to raise the cap for contributions for x months. I am not in favor of storing/accumulating extra funds as a rainy day thing. It puts the funds at risk and destroys the very benefit of a decentralized crypto ecosystem.

Funds can be given from the block rewards directly. Maybe Evan creates a dummy set of masternodes that pay for each project. I don't know the best way to do it. If the project needs full funding on day one, a dash holder could offer the full amount upfront in exchange for the % of block rewards for the x months it pays.
 
It puts the funds at risk and destroys the very benefit of a decentralized crypto ecosystem.

Just to make this point clear: the funds are NOT in anyone's wallet, they are in the blockchain.

Only a sufficient number of votes can release a certain amount. It's ALL in the hand of the Masternodes owners.

What still needs to be defined is how a destination address and the amount itself can be defined in a way that excludes possible manipulation (aka not done "by hand").
 
Maybe a way to do this would be to say only masternodes that have been active for 2+ weeks can vote. It would be impossible to vote, move funds to another node and run more than 2 weeks in a 2 week voting period.

There must be something wrong with your 4 crashing nodes. My nodes have been going strong since the last update. I think you are still in the payment queue if you don't shutdown for more than an hour. You could setup a restart script to run every hour, but you would be better off fixing the nodes or finding a new host.
Here's a solution: when a proposal is created have the system take a quick "snapshot" of all active mn's at that block time and then only those mn addresses can vote on that proposal. Then limit the voting time to something that makes sense like a week.

JL
 
Just to make this point clear: the funds are NOT in anyone's wallet, they are in the blockchain.

Only a sufficient number of votes can release a certain amount. It's ALL in the hand of the Masternodes owners.

What still needs to be defined is how a destination address and the amount itself can be defined in a way that excludes possible manipulation (aka not done "by hand").

The post alex-ru was referring to was about accumulating funds for future projects when there are no good projects available. I don't see how the blockchain can store funds. I think It can only distribute the block rewards as they are created. In order to accumulate the funds they would need to go into a wallet - and then the problem of ownership, loss, etc. comes up.

I fully agree that a "Hands off the DASH" distribution approach is best. The voting system needs to enforce distributing the funds to a project owner without any hands in the middle.
 
Whatever is decided, we need to trial run it somehow, and re-evaluate at the end of the term. That way, if something simply isn't working as designed, we can scrap it and try another way.

Also, keep in mind with the "vote first, then save money" scenario, development will take considerably longer as we will have to vote ===> save money ===> start project, whereas the other way we just vote ===> start project.

A readily accessible fund, if managed properly, would be better for timely implementation of projects.
How long did it take for XCOIN to become DARKCOIN and then DASH.

Me, me, me, now, now, now!

Can't take advice from people like that... Short-sighted and selfish doesn't last.
 
The problem is that I don't want to donate to 18 projects that get 1/4 funded and never happen.

Your scenario can't happen.

1) Vote for inclusion in queue.
2) Vote for block percentage to be put into queue.
3) Prioritize projects in queue.

As long as someone is mining blocks, everything in the queue gets funded.

Again, you're getting tied up in budget management details that could simply be eliminated by not having a budget to manage... We don't need a budget anymore, we're beyond that.

We have the ability to do better than the old-school budget system and all it's shortcomings. Some people simply fear change, others fear losing the ability to skim into their own pockets... I propose a system where it doesn't fuckin' matter. You can cry when diff goes up and your miner doesn't money hose, but guess what; doesn't fuckin' matter!

I propose an advertising campaign. The most expensive bullshit ever... I propose it be funded at the full 15% and every time it comes to conclusion, be brought up for a vote again and again forever.

A built-in message/news handler, kinda like gentoo's emerge platform... There might need to be a cap on the number of proposals, because we can read only so much stuffs. Right in ncurses, read about it, vote on it. Kinda like ballot propositions.
 
Last edited by a moderator:
I said:
The problem is that I don't want to donate to 18 projects that get 1/4 funded and never happen.
Your scenario can't happen.

1) Vote for inclusion in queue.
2) Vote for block percentage to be put into queue.
3) Prioritize projects in queue.

As long as someone is mining blocks, everything in the queue gets funded.

Again, you're getting tied up in budget management details that could simply be eliminated by not having a budget to manage... We don't need a budget anymore, we're beyond that. The only reason to want a budget is to abuse it.

This quote was referring to the problem if each masternode determined the amount that they would donate(with the concern that if some masternodes didn't want a project they wouldn't be forced to contribute). I don't like this approach as it results in partially funded projects.

Every project is fully funded when it is voted on in a prioritized way with funding % from block rewards. Every masternode contributes the same amount(as long as x% votes it in). This works. No budget.
 
This works. No budget.
Exactly, no fucking about. No potential for abuse.

One might say that once in queue, the priority might be fiddled with to keep certain projects at the bottom. This isn't likely since it had to get a majority of support to get into the queue in the first place. It's just a good way to push back certain things if something or paramount urgency comes up.
 
Also, voting should be inclusive to a super majority of actual voting participants. Not a mere 51% that can flop around on occasion of abstainers being high. It's needs to be a 66% by participation, not a 66% by total, or a 51% by anything at all... It needs to be beyond just half. A project has to have significant enough value to garner more than just 51%. Simple mob rule isn't good enough, it has to be a clear winner of an idea.
 
This is blatant nonsense. Neither of us have said any such thing. I just think the process needs modifying to prevent waste and abuse.



Or maybe it's because we care about the project and know full well how this is going to play out?

I can see the $$$ signs whirring in the eyes of certain folk who have Evan's ear, they think they've hit the jackpot with a perma-fountain of easy money here.


I've made my case, I'll shut up. Unless Moli wants to step in and give me some rough stuff. :eek:
LOL... Been busy with my real life job and real life entertainment... I just now sat down to read this thread "Go to first unread".. damn 3 and half pages...

What rough stuff are you expecting? :tongue:
Right now I don't have much opinion on this subject. This proposal might be a good idea to support the development but does anyone know how this is going to pan out? If it goes wrong later on they can't blame it on you, so don't worry. :)

I have a good idea for you to get busy though: How about let's make a campaign to get more miners to mine on the p2pools? :grin:
 
The minor and also temporary value of having a budget/slush fund/pork barrel are outweighed by the guarantee of abuse and impossible management. It's not worth it for such a tiny advantage that will not even be an advantage any more after the first month or two.

Is that permanent liability worth it just to imagine yourself on the moon a few moments sooner (an imagining which will not likely be actualized)?

No. Fuck no.

Temporary free stuff that never comes to being is not worth collapsing an entire economy, but it's been voted for over and over again through out history, leading to the demise of nation after nation...

It's just plain stupid that we would even be having such an absurd conversation in crypto... Is getting your pet project done one day sooner, maybe, more important than securing the blckchain and keeping the supply closed-loop? Fuck no. Holy fuck-baby-buddah-in-the-butt-sideways-with-a-flaming-pine-cone NO!

Look at it from the other end.

You might, maybe, if you're really lucky, get your pet project done slightly sooner. There's no guarantee of that small temporal advancement even being realized. But, you completely wreck the supply-goes-only-to-contributors notion of the first PROOF OF SERVICE coin ever made to get that maybe tiny thing that doesn't even matter... Are you fucking nuts? Is entitlement and immediate gratification so damn important that you're willing to do that?

Low information voters are an anomaly among MN operators for a reason; if you can't scrape together enough DASH to form your own damn MN, you're one of those bad decision makers.

I know this old hippie chick in California who has sense and discipline enough to scrape together more than one... Wisdom of the NON-RETARDED group.
 
Last edited by a moderator:
Ok, so I'm reading what you all are saying, and I believe I understand the main issues:

1. Rather than taking 15% of the mining rewards to create a fund that is then used to pay for core development, marketing and projects, some of you would prefer approving funding for things as we go, with a time limit on the donation to these projects.
a. This will likely make it harder to get consensus to fund a project, especially if it is coming out of masternode funds directly after they have become used to the rewards.
b. This might cut down on waste but is likely to under-fund core development and marketing. Since returning funds through block redistribution costs nothing, it is in no way wasteful.

Note: Solarminer, there should be no cost to run this DAO, it will be a program run off the blockchain. The DAO belongs to no country, so there will be no taxes until the funds are released to the DOA developers. These developers will have to account for the funds as self employed. And yes, I think the idea is that it will be a multi sig wallet, where a winning ballot unlocks one of the signatures, or else the signature.

Camosoul, you said:
It's impossible to put it back accurately and fairly once you take it. The MNs are responsible for the vote. They're the ones involved. It should come from their piece of the pie.

But I actually remember, the miners never had a choice in this, they were to have their rewards reduced to 40%, which hasn't happened yet. And the Masternodes were to get 60%, which hasn't happened yet. Right now, we have a good ROI with 2500 masternodes, and if we wanted to increase the number of masternodes for the network, all we'd have to do is halve the deposit required to running one. We don't need that extra 15% to increase the numbers to 3000 MNs. So really, the ROI isn't going to drop, just the number of MNs. If we halve the collateral then we would have more servers making the network better distributed. Also, since the cost of buying a masternode has gone up (due to price of DASH), I'd suspect it would still be as secure as ever. I also think returning any extra funds, after a savings is established, is very easy, and actually fairer if we share with the miners. Sharing with the miners will also makes it less likely that funds will be returned for purely altruistic reasons. Masternode voters will be more inclined to use funds for the benefit of the coin, than vote the funds back into their pockets if the projects or developers and marketing is more likely to benefit them (and the coin in general) than getting half the funds back.

David, yes, I think we need a quorum, I just didn't know the word for it. We may have good response in the begining, but as time goes on, I think something will have to be done for lack of interest/time to invest in being appraised of the proposals and giving an informed vote.

Alex-ru, I agree with you that a pure democracy could bring this down. If there were a tiered system, maybe we can make it more functional, with the voices of the minority being heard? I can't think of such a set up on the fly here, but it would be excellent if we could come up with some minority protections, and full community integration.

Solarminer, you said: "I agree Masternodes will donate to projects that make sense and raise the value of DASH. The problem is that I don't want to donate to 18 projects that get 1/4 funded and never happen. I want to donate to a project that will be completed because it will get the funds it needs. The voting system makes a consensus for the best projects and diverts funds to only those."

Agreed, and I believe we'll have to fund projects fully, either by dedicating future rewards to it, or keeping it ready to go in the blockchain. How can all this work? It's really not so hard. It can all be programmed into the block chain, and there should be progress reviews, headed by our main development team if appropriate, who will review what has been done, and make the recommendation to the network to make a progress payment. Or if nothing is being done on the project, a recommendation to put on hold, or cancel the project (if it's a scam) There are risks when hiring people, but we can minimize them just like any other business.

Crowning, you said "What still needs to be defined is how a destination address and the amount itself can be defined in a way that excludes possible manipulation (aka not done "by hand")."

I'm certain this can be done via contracts inside the DAO. The DAO coding, which must have a way to flexibly insert these contracts, will be assigned to the development team. It will be one of their responsibilities. (the way I see it)
 
The post alex-ru was referring to was about accumulating funds for future projects when there are no good projects available. I don't see how the blockchain can store funds. I think It can only distribute the block rewards as they are created. In order to accumulate the funds they would need to go into a wallet - and then the problem of ownership, loss, etc. comes up.

I fully agree that a "Hands off the DASH" distribution approach is best. The voting system needs to enforce distributing the funds to a project owner without any hands in the middle.

You need to familiarize yourself with the concept of distributed autonomous organizations/corporations/contracts. This can be done, and is really what all this is about. We will be the first to truely tap into the power of DAOs
 
Back
Top