Self-sustainable Decentralized Governance by Blockchain

[camosoul]

Competition breeds excellence. Handouts breed leeches.

Competition could be a race to the bottom, and often is. Competence, hard work, and intellect breed excellence.

I believe reputation could be a major factor in these projects, no matter how they are decided upon.

Two nearly identical feature proposals could be presented, one by Some New Guy for Cheap. And one by Udjin, for Expensive. I'll still vote for Udjin's project because I know he's worth it, some things are worth paying extra to get.

 

[TanteStefana]

That's why I said least retarded.

Option 1) Imaginary Benefit + Pork Barrel + Impossible to Regulate Refunds.
Option 2) Actual Benefit + Nothing.

I'm simply flying the flag of the option that is clearly the least retarded...

MN operators will not vote down everything, no one with a functioning brain can even suggest that would come to pass. It's just plain silly and flies in the face of all the factors at play. That's like saying that miners would prefer that value never increase... They don't consider it because it doesn't apply to them directly. They're hand-to-mouth base-level animals of the system. MNs are a level that is several steps up, and never been in any other coin. It changes the whole game and those presenting the arguments as if that were not true are either deliberately trying to deceive for the sake of the pork barrel they're drooling over, or genuinely ignorant about how this works...

Your favorite option does make the system less agile and clunky though.. :tongue:

Quote:

Be open minded. But don't be so open minded that your brain falls out...

:grin:

 

[strix]

Well, it has taken 24 hours, but I have finally read the entire thread--thank you Tao of S. for the notice--I might not have seen it for another two weeks. This is clearly a momentous occasion; we are privileged to be witnesses to, and participants in, what future generations will study in school, and scholarly papers will be written about.

In view of that, and the huge burden of responsibility that I feel weighing on me, (thank you very much Tao:tongue, I feel compelled to make the following extremely important suggestion that others have barely touched on.

One person (sorry, I forget who), noted that in today's world Yea and nay are rarely used, and suggested that votes be noted as "Yes," or "No." While this has merit, I think that in order to put a proper face on it that this requires further modification. I humbly suggest that we use "Aye," and "No." So that in the event of the successful passage of a measure we maintain correct posture...

That is to say--that the eyes should be above the nose.:what:

I share this primarily to keep anyone (including myself), from taking any of my further thoughts on this august thread too seriously.

 

[camosoul]

Your favorite option does make the system less agile and clunky though.. :tongue:

Quote:

Be open minded. But don't be so open minded that your brain falls out...

:grin:

In one way it does. But it makes it super-duper high-speed low-drag in other ways. Definitely a worthwhile compromise going forward.

 

[TaoOfSatoshi]

Please don't publish a MN Voting Guide... MN operators are supposed to be smart, remember? ;-)

*Puts away draft* Aw, you ruined my fun!

OK, I'm out for now, good talking with you guys.

Baseball night! My Blue Jays are down in your neck of the woods taking on T-bay. They can't seem to beat them this year. :sad:

Cheers, I'll be back later to catch up on the 4 pages I'll miss...

 

[Solarminer]

That's a good example. I see your point.
What the fund option (potentially) does however, is accumulate even when there isn't valid proposals until one is proposed that does make sense. And in the meantime, the scope of what's possible increases. Or the amount of development projects could increase based on fund size.

Actually, if you look at both ways.
We vote:
Project A need 5% of the block rewards for x time = 5 DASH
Project B needs 10% of the block rewards for x time = 10 DASH

The Vote per project donation model.
5% of the blockchain immediately starts going to project A
10% of the blockchain immediately starts going to project B
Both projects start work and are finished in x time.

The 15% Mandatory Donation Model
15% of the blockchain starts to go into a general "fund".
At some point a distribution goes to project A - maybe each week or when full project amount is accrued?
And then is there a vote for each transaction that goes out of the wallet? Are the masternodes going to vote again on which amount goes to which project first?
Then when project A is funded, distributions go to project B.
In x+y time both projects are funded. I suppose partial distributions to each would work, but this probably will not be the case. The y is the time project B had to wait until it was funded.

Vote per project is a hands off approach without any coordinating when to pay projects, in what order. Also both projects start right away and potentially would be completed faster.

If project A needs a downpayment for a camera rental or something, they could ask an investor to upfront the money in exchange for the remaining fund distributions(maybe importing the wallet key). This isn't really possible with the mandatory donation model as all the project funds are co-mingled.

You see where that co-mingled wallet with super secret multikey + mn voting security gets to be a problem?

 

[crowning]

Two nearly identical feature proposals could be presented, one by Some New Guy for Cheap. And one by Udjin, for Expensive. I'll still vote for Udjin's project because I know he's worth it, some things are worth paying extra to get.

Very good point. Looking at the number of Masternodes which are hosted by Masternode services there will always be a good percentage of Masternode owners who don't have your technical/social background (they may not even be forum members) and can't judge properly.

One of our future tasks will be to educate those.

 

[Solarminer]

Well, it has taken 24 hours, but I have finally read the entire thread--thank you Tao of S. for the notice--I might not have seen it for another two weeks. This is clearly a momentous occasion; we are privileged to be witnesses to, and participants in, what future generations will study in school, and scholarly papers will be written about.

In view of that, and the huge burden of responsibility that I feel weighing on me, (thank you very much Tao:tongue, I feel compelled to make the following extremely important suggestion that others have barely touched on.

One person (sorry, I forget who), noted that in today's world Yea and nay are rarely used, and suggested that votes be noted as "Yes," or "No." While this has merit, I think that in order to put a proper face on it that this requires further modification. I humbly suggest that we use "Aye," and "No." So that in the event of the successful passage of a measure we maintain correct posture...

That is to say--that the eyes should be above the nose.:what:

I share this primarily to keep anyone (including myself), from taking any of my further thoughts on this august thread too seriously.

I would also think voting with just a binary model will make this difficult. We should entertain a project-Y and project-N or something like that. I guess your method would be project-A vs Y, not really 100% with you on this, but I don't mind either way. We could also move to a + and - so other languages stay consistent.

That way during a vote you can specify the project and the vote. Otherwise, you will have the matrix of yes/no questions you need to answer for each vote. Those with more than one masternode will find this difficult.

Pasting in a few lines like this would be easy:
masternode vote Blinding-Y
masternode vote Troll-Defense-Association-N
or
masternode vote Blinding+
masternode vote Troll-Defense-Association-

 

[strix]

snip... I guess your method would be project-A vs Y, not really 100% with you on this, but I don't mind either way. We could also move to a + and - so other languages stay consistent. ...snip

It is an honour to meet you Solarminer.:smile: I have truly appreciated your level headed input, and the way you have clarified and collated the suggestions to this point. It really does help one to think about the options more clearly when they are laid out side by side.

My respect for you is even greater now that I suspect you may not be a native English speaker. My suggestion was a joke, and not serious. It was based on a word play using the phonetic similarity of "aye" (an archaic form of yes) and "eye;" and the plural of "no," and "nose." Sorry for the confusion.

And keep up the good work!:grin:

 

[Solarminer]

It is an honour to meet you Solarminer.:smile: I have truly appreciated your level headed input, and the way you have clarified and collated the suggestions to this point. It really does help one to think about the options more clearly when they are laid out side by side.

My respect for you is even greater now that I suspect you may not be a native English speaker. My suggestion was a joke, and not serious. It was based on a word play using the phonetic similarity of "aye" (an archaic form of yes) and "eye;" and the plural of "no," and "nose." Sorry for the confusion.

And keep up the good work!:grin:

Thanks for the kind words. Actually, I reside in the US and am located in the midwest. Any language misinterpretations are clearly from my engineering background and nearly unused right brain. :grin:

 

[camosoul]

Vote per project is a hands off approach without any coordinating when to pay projects, in what order. Also both projects start right away and potentially would be completed faster.

It could initially just be FIFO, with organization bullet points added later.

As already discussed, fund rate, priority, etc...

Binary works well in layers. It keeps things organized.

1) Are we doing this shit? Y/N
2) How much of the block reward are we committing to this shit? 1/5/10/15/Decide Later
3) Is this shit more or less important than other existing shit we're doing? M/L/I'm Too Drunk To Make This Decision.

Things could go parallel... If 3 accepted proposals get 5%, then all 3 fit into the 15% cap,and can be funded at once... % doesn't slow down the queue, all things funded as fast as possible within cap constraint. Just throwing out ideas, that may be a dud even as I type it...

It may be "clumsier" but more useful to keep the % independent of the project. "X% going to Queue" This could flex depending on where all nodes stand at each block time, and could even be an average of all stated %... IT would be like a MN defined Difficulty, designating input based on value perceived in the queue at a given time. Making it an average would marginalize slow voting and ramp anyway.

The ncurses interface could even display current status of decision making. "28%Y - 0%N"

 

[strix]

Thanks for the kind words. Actually, I reside in the US and am located in the midwest. Any language misinterpretations are clearly from my engineering background and nearly unused right brain. :grin:

Well your left brain is certainly welcome, appreciated, and needed here. I am in FL near the Space Center, so I am quite comfortable rubbing shoulders with left brains. Please feel free to let your right brain know it is welcome to come along for the ride, if it so chooses.:wink:

 

[Solarminer]

It could initially just be FIFO, with organization bullet points added later.

As already discussed, fund rate, priority, etc...

Binary works well in layers. It keeps things organized.

1) Are we doing this shit? Y/N
2) How much of the block reward are we committing to this shit? 1/5/10/15
3) Is this shit more or less important than other existing shit we're doing? M/L/I'm Too Drunk To Make This Decision.

Things could go parallel... If 3 accepted proposals get 5%, then all 3 fit into the 15% cap,and can be funded at once... % doesn't slow down the queue, all things funded as fast as possible within cap constraint. Just throwing out ideas, that may be a dud even as I type it...

The proposal owner needs to set the % and time they need to complete the project. We would just vote for or against each project based on if it was worth the %xtime. Projects with the most yes votes go first - simple. Problem is that there needs to be a question/answer session for each masternode. Not easy to make a script to run. If you use a command line function that specifies the project and vote at the same time it would make voting on several masternodes easy. Plus coding a comandline entry should be easier than asking questions and recording the answer.

 

[camosoul]

The proposal owner needs to set the % and time they need to complete the project. We would just vote for or against each project based on if it was worth the %xtime. Projects with the most yes votes go first - simple. Problem is that there needs to be a question/answer session for each masternode. Not easy to make a script to run. If you use a command line function that specifies the project and vote at the same time it would make voting on several masternodes easy. Plus coding a comandline entry should be easier than asking questions and recording the answer.

We could extend the MN comms to include master/slave, where an owner of multiple nodes could have one control the voting for all nodes. Scripts are a band-aid, this is clearly a useful feature that could be integrated.

Better, an xtension of start-many becasue it already does this... This helps dodge the crashing daemon issue and verified funds at the same time...

I disagree with forcing the proposal maker to define these parameters. It shouldn't be up to them.

 

[Solarminer]

We could extend the MN comms to include master/slave, where an owner of multiple nodes could have one control the voting for all nodes. Scripts are a band-aid, this is clearly a useful feature that could be integrated.

Better, an xtension of start-many becasue it already does this... This helps dodge the crashing daemon issue and verified funds at the same time...

I disagree with forcing the proposal maker to define these parameters. It shouldn't be up to them.

I like the idea of the start many integration to just vote once.

Two project bids are on the vote:
Project A I can do it for 2% for 3 months.
Project B Other guy can do it for 3% for 3 months.
Both equivalent projects. Maybe I get votes because of my looks(yeah right). And the other gets votes because...it is Evan.
Market will determine who gets the project. Both owners know they can finish the project for the bid they gave. If they get less they can't do their project. As a smart masternode voter, it wouldn't make sense to pay above this amount either.

 

[camosoul]

I like the idea of the start many integration to just vote once.

Two project bids are on the vote:
Project A I can do it for 2% for 3 months.
Project B Other guy can do it for 3% for 3 months.
Both equivalent projects. Maybe I get votes because of my looks(yeah right). And the other gets votes because...it is Evan.
Market will determine who gets the project. Both owners know they can finish the project for the bid they gave. If they get less they can't do their project. As a smart masternode voter, it wouldn't make sense to pay above this amount either.

I think putting it on a schedule is too restrictive. Some projects that may not even apply, others may be too creative/involved to be certain. I think a minority of these projects will even be core code related...

 

[Solarminer]

I think putting it on a schedule is too restrictive. Some projects that may not even apply, others may be too creative/involved to be certain. I think a minority of these projects will even be core code related...

Out of all the people, Camosoul says adding a schedule and amount to a project is too restrictive...

Software projects are really hard to estimate. The project owner can give a good guess of the % and time it will take and then if it needs more funding it gets voted on again. Keep in mind the time is only to determine the amount of funds. So a 1% block reward for one month could be $x. The value is what we approve. If the actual project takes a week or 3 months, it doesn't matter.

For a smaller project maybe the project owner can add a %/mo and have it renewable automatically 3 times unless it gets a no vote to stop it.

 

[camosoul]

Out of all the people, Camosoul says adding a schedule and amount to a project is too restrictive...

Software projects are really hard to estimate. The project owner can give a good guess of the % and time it will take and then if it needs more funding it gets voted on again. Keep in mind the time is only to determine the amount of funds. So a 1% block reward for one month could be $x. The value is what we approve. If the actual project takes a week or 3 months, it doesn't matter.

For a smaller project maybe the project owner can add a %/mo and have it renewable automatically 3 times unless it gets a no vote to stop it.

I suggest we control the work queue, what goes in it, and make sure the funding method is not open-ended.

The rest should be left open so people can do the job we're paying them to do. Don't micro manage it. Lets not create a system that makes people say "my idea won't fit those constraints so I'm not even going to bother."

I want to keep the coin protected from open-ended pork, not go into every detail of the projects themselves.

If we buy a bad project with a bad dev/doer person, we made a msitake, screw us once, shame on you, screw us twice shame on us... I mentioned reputation, and using people we know already... If they fail, let it no becasue we kept getting in their way.

 

[Solarminer]

I suggest we control the work queue, what goes in it, and make sure the funding method is not open-ended.

The rest should be left open so people can do the job we're paying them to do. Don't micro manage it. Lets not create a system that makes people say "my idea won't fit those constraints so I'm not even going to bother."

I like the idea of a project proposal with a block % over x months. Then it can be sold off if needed to get funded immediately. This isn't possible without a defined stopping point.

So looking at your idea.

• We vote in projects based on % of block rewards. Highest yes vote projects with 51% of vote or better get in. Projects are kicked out if they are over a 51% vote but they go over the 15% project cap.
• Every 3 months we vote on projects again. If a project needs to get kicked out(non performing or bad idea) it can get knocked out of the queue by a 51% negative vote. Otherwise projects already in the queue continue at the same % until the owner says finished or it is voted out.
• New projects can be added to the queue every 3 months as long as there are additional funds not used by continuing projects.

I see that there would be an incentive to not finish projects and keep funding going. But this could happen anyway we do this. At lease, there is a mechanism in place to stop the funding for a dud project if this happens.

 

[darkchild]

I've read all of the posts thus far and weighed all the pros and cons from my own perspective.

I'm 100% behind this new initiative and I have the following comments and suggestions to make with the hopes that we can stop arguing like old house wives and keep DASHing.

We currently have three pillars that support DASH. Miners, Masternode Operators and Governance (Devs, Marketing, Legal, Entertainment, Travel, Accommodation, etc). More will be added, but my post is reserved for the three mentioned above.

Miners and Masternode operators have roles that are clearly defined and enforced through the logic in the code.

Governance however is a grey area which is subject to a wide range of human emotion, needs and sense of worth based on each individual's background, culture and expectations. We can not enforce or programme this in code and this is where faith and trust kick in.

We have all seen all the scams, scandals and collapses of different cryptos and foundations which have all provided lessons for all of us to learn from.

For this reason, I'm proposing that anyone who is going to participate in any Governance related project MUST be publicly identifiable.

Evan and a few others are already well known to the community. If you are going to be a public servant, who serves the DASH community and is paid by the community, then you can no longer live in the shadows.

DASH is not a joke. It is something I take very seriously and dedicate an enormous amount of my time in supporting and promoting both online and offline. I'm not the only one who does this. There are many others serving in silence and don't get paid.

Anyone who is going to be paid through the fruits of miners and masternode operators MUST have their identities in the public domain, so that when anything goes wrong, they can be identified and brought to justice if necessary. Any successful business or foundation is not always a democracy and this why we have a board that is elected to serve our collective interests until they let us down.

They are in effect our elected officials and until they fail in performing their duties, we MUST trust and put our faith in them because they operate in the grey areas vs the black and white world of miners and masternodes.

If anyone the Governance body fails to delivers or tries to scam the community, then we know their identity and we we take legal action, which in itself is subject to a vote by the community based on what the community stands to gain or lose or simply for the sake of setting an example to deter others from trying to f**k with the community in future.

So going forward, we put our faith and trust in the Governance pillar with the condition that we know all the public identities of the actors involved. This condition should be non-negotiatable, which means that when you decide to feed of the DASH community, it comes with a great degree of responsibility and accountability.

How far we want to verify each governance actor will be up to the community. If it's someone in legal or finance, we can require a police background check or ask to see that they are accredited with a recognized legal or accounting association in their respective jurisdictions. I don't know any business or organization that hires people without knowing who they are or their competence.

There should be no half measures when you decide to run for a public DASH office.

I don't want no secret government with black budgets and excessive discretionary spending.

Evan is already leading by example and it is time to know who the others are.

No more pseudonyms or hiding in the dark if you want to get paid.

We the community want to know you and support you, since you are part of the governance body.

The same thing will apply to any company we need to hire and outsource DASH services to. We need to know their names, references and this way the Masternode operators can make an informed decision.

If this advice is not heeded, Masternode operators will be left in the dark and we will argue and debate till the cows come home. We will not advanced as a united collective, but as a forced alliance.

I have to believe that anyone who is a Masternode operator is capable of sound judgement when presented with all the facts.

If we want to run DASH like professionals, let's do so properly. Evan has publicly stated on many occasions DASH isn't something created to support criminal activity but to provide transactional privacy among many other innovative features.

While I respect personal privacy, I do believe that those who represent DASH in any capacity as service providers within the Governance pillar should have their real identities made public and why the community and Masternode operators should vote for them.

Remember that is it these people who are going to do the work, so we are actually voting on their competence and ability to do the work and not just on the project. We have to be able to vote on a project and then vote on the assignees who have to be publicly known, so that they can earn reputation credits, which is potentially another DASH feature. Evan, Flare, Udjin, Crown, Fernando, Tungfa and others have already earned such reputation as credits in my books.

We can vote YEA on a brilliant idea, which doesn't get executed because it was assigned to people who were not competent, lacked reputation credits or got projects assigned to them through cronyism.

The DASH community is made up of people from all works of life and from every continent. They are a passionate bunch as I've seen from the many arguments for and against these proposed changes. If they had no interest they would have simply packed up their bags and left like some did when we switched branding. I have faith in the DASH community and that includes those who are for or against some of the new ideas.

Every major crypto foundation has failed and one of the key reasons hasn't been lack of skill, but lack of transparency and the desire to work in the shadows.

Let DASH be first crypto to take off without VC backing, bailouts, donations and with a transparent governance body.

Finally let us never forget who we are serving, the other 7 billion people who DON'T GIVE A SHIT about miners, masternode operators or the brilliant code that has been written. All they want is eye candy and something that works and solves their real world problems.

They will also recognize bad governance from a mile away and never come back and that starts with the public faces of DASH.

My two duffs.

DC