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

New Budgeting System manager/employer/employee discussion

oaxaca

Well-known member
Foundation Member
OK,

On the latest Dash Round Table podcast, Evan introduced some ideas that will be included in the new budgeting system. This thread is for discussion of these ideas. I would like to start by asking if any devs would like to help us understand the basic idea and any deep down specifics as to how the new system would work. After clarification, everybody please chime in on ways the idea is efficient/inefficient, more/less streamlined, easier/harder to game, etc.
 
OK,

On the latest Dash Round Table podcast, Evan introduced some ideas that will be included in the new budgeting system. This thread is for discussion of these ideas. I would like to start by asking if any devs would like to help us understand the basic idea and any deep down specifics as to how the new system would work. After clarification, everybody please chime in on ways the idea is efficient/inefficient, more/less streamlined, easier/harder to game, etc.

First and foremost; how do we ensure these" employers/employees" aren't colluding or being paid off? We are adding a lot of centralized points of failure with a setup such as this IMO.
 
I was looking for more information about the new methodology. If more specifics are known, then potential issues can be identified.

EDIT
-------------
Don't mind thedashguy, his heart is in the right place. He's basing his comment on incomplete information. That's what I'm trying to prevent by asking for a more complete framework.
 
Last edited:
This seems to be the core concept (correct me if i am wrong):

- masternode owners don't vote on proposals anymore
- masternode owners use their vote to elect multiple managers (e.g. one with expertise in marketing, one for legal issues, one for payment gateway implementation ...)
- managers are paid by the blockchain for their work
- managers can take suggestions from the community, but more or less decide on their own, which part of their respective field they want to develop
- example: "legal manager" thinks, we need new statutes for the DASH foundation. He hires a lawyer, negotiates the salary via Evolution system, lawyer writes new statutes. Lawyer is paid by blockchain after manager validated the lawyer (employee) work. Manager provides a reporting for all of his projects to the community.
- in case manager abuses the system (by hiring a friend) or just underperforms in development of his respective field, masternode owners downvote and thereby fire him

Each project manager can handle about 8-10 projects. So by adding new managers, the system scales very well and masternode owners don't have to decide on every small proposal anymore.
 
Last edited:
This seems to be the core concept (correct me if i am wrong):

- masternode owners don't vote on proposals anymore
- masternode owners use their vote to elect multiple managers (e.g. one with expertise in marketing, one for legal issues, one for payment gateway implementation ...)
- managers are paid by the blockchain for their work
- managers can take suggestions from the community, but more or less decide on their own, which part of their respective field they want to develop
- example: "legal manager" thinks, we need new statutes for the DASH foundation. He hires a lawyer, negotiates the salary via Evolution system, lawyer writes new statutes. Lawyer is paid by blockchain after manager validated the lawyer (employee) work. Manager provides a reporting for all of his projects to the community.
- in case manager abuses the system (by hiring a friend) or just underperforms in development of his respective field, masternode owners downvote and thereby fire him

Each project manager can handle about 8-10 projects. So by adding new managers, the system scales very well and masternode owners don't have to decide on every small proposal anymore.

Is this project voted by masternodes?
Or it is a manager who proposes it?

I find very strange the proposition that masternodes are prohibitted to vote on proposals.
Of course they should be allowed to elect managers as representatives, but this should be an available option and not something imposed to all masternode owners.
If a masternode owner wishes not to elect a representative and continue to vote on proposals, he should be allowed to do so.

The key point is in the last proposition:
- in case manager abuses the system (by hiring a friend) or just underperforms in development of his respective field, masternode owners downvote and thereby fire him

Someone who owns multiple mastenodes, he can always support his friends although corrupted ones.
You have to presisely define the conditions under which someone is fired and take into account that corruption may arrive due to the fact that someone may own many masternodes.
 
If I were you, I would wait for specification or testnet. Without this you will come to surprising conclusions


I dont have to wait for specifications like the hidden manna from heaven, I think I know what it is correct to be done, and what is wrong

For example if you insist of just allowing masternodes to vote yes-no and you prohibit voting with numbers, this is definitely wrong.

The specifications are always supposed to be discussed, so come here and discuss before posting them.
 
Is this project voted by masternodes?
Or it is a manager who proposes it?

I find very strange the proposition that masternodes are prohibitted to vote on proposals.
Of course they should be allowed to elect managers as representatives, but this should be an available option and not something imposed to all masternode owners.
If a masternode owner wishes not to elect a representative and continue to vote on proposals, he should be allowed to do so.

The key point is in the last proposition:
- in case manager abuses the system (by hiring a friend) or just underperforms in development of his respective field, masternode owners downvote and thereby fire him

Someone who owns multiple mastenodes, he can always support his friends although corrupted ones.
You have to presisely define the conditions under which someone is fired and take into account that corruption may arrive due to the fact that someone may own many masternodes.

My understanding is that MN owners will have the option (nobody is forced to do anything) to vote on projects (formerly known as proposals) and project managers -- and that this voting is an independent process.

That's what I heard but I may have misunderstood which is why the best course of action is to wait a few days for testnet and the specifications.
 
My understanding is that MN owners will have the option (nobody is forced to do anything) to vote on projects (formerly known as proposals) and project managers -- and that this voting is an independent process.

That's what I heard but I may have misunderstood which is why the best course of action is to wait a few days for testnet and the specifications.


What you dont undestand is the tricky point in this so called "manager proposition".
Some people do own many masternodes, and that way they control dash.
They discovered that with the voting procedure, they will have to work and vote for propositions, in order to maintain the control over dash,
But they dont want to work, they want to keep gaining dash coins with no pain.
So they decided this manager system, so that they get keep gaining proffit from dash without work, and keep controling dash whithout working either.

So you have to be cautious when people want managers, it is probably the corrupted ones who want this. The ones who gain the 1 third of dash when dash was initialized, and they want to keep control over it whithout even work on voting a yes or no.

This is the bad scenario of course, we dont know if it is true, so you can always believe in another scenario, the good scenario where nothing of the above is valid.
 
Last edited:
There is absolutely nothing that can objectively be discussed at this point. All we can do is speculate. We only had a brief explanation on the podcast and a one line example on BCT. Testnet is right around the corner. Very soon we will have specifics to discuss.

@demo - what you're proposing is an entirely different project, and undermining 2 years of development. All the issues you pose have been addressed. The biggest bag holder who are MN and vote, are also the people who have more to loose. It is in their best interest that the project evolves in a healthy manner. It is a bit naive to think they'd rig the system for their own benefit, as what they'd gain is peanuts compared to their holdings. That would also raise huge red flags and the entire community would loose confidence, we would probably fork to fix the issue, and done deal. There is no drama.

So far it's been working great. Nothing is perfect, but it's been working fantastically well. Lets wait before we actually have something concrete before criticising this and that please. It's been a constant thing this past month, in the voice of very few. And it's not productive.

Wait for testnet and try to break it please!


.
 
Last edited:
What you dont undestand is the tricky point in this so called "manager proposition".
Some people do own many masternodes, and that way they control dash.
They discovered that with the voting procedure, they will have to work and vote for propositions, in order to maintain the control over dash,
But they dont want to work, they want to keep gaining dash coins with no pain.
So they decided this manager system, so that they get keep gaining proffit from dash without work, and keep controling dash whithout working either.

So you have to be cautious when people want managers, it is probably the corrupted ones who want this. The ones who gain the 1 third of dash when dash was initialized, and they want to keep control over it whithout even work on voting a yes or no.

This is the bad scenario of course, we dont know if it is true, so you can always believe in another scenario, the good scenario where nothing of the above is valid.

I don't understand. There is nothing stopping a fatcat MN owner from not voting and just collecting coins right now. Some owners probably are as only about 30%-40% of the MNs vote on average. So this issue is neither here nor there with regards to the new system.

Plus, even with the addition of managers I am pretty sure Evan said MNs will still vote on "proposals". There are just called "projects" in the new system.

Again, this is why this discussion makes more sense after the testnet release as then we can actually discuss facts. After we get all the facts then we can discuss what parts of the system need to be changed. ;)
 
  • Like
Reactions: jpr
Why would I give my voting power to a bloody manager? I invested the money and want to make my own decisions. I really hope loosing privileges is not the case.
 
I don't understand. There is nothing stopping a fatcat MN owner from not voting and just collecting coins right now. Some owners probably are as only about 30%-40% of the MNs vote on average. So this issue is neither here nor there with regards to the new system.

Plus, even with the addition of managers I am pretty sure Evan said MNs will still vote on "proposals". There are just called "projects" in the new system.


A lazy fatcat MN owner who gained the 1 third of total dash during the initialize process two years ago, he is oblidged to vote, because if he does not, then a decision could be made and the community could decide for example to change the protocol and take money (as a form of taxation) from fatcat MN owners. Thats why fatcat MN owners tend to hire managers, and tell them to vote against any such decision.

This is the bad scenario of course, we dont know if it is true, so you can always believe in another scenario, the good scenario where none of the above is valid.

Again, this is why this discussion makes more sense after the testnet release as then we can actually discuss facts. After we get all the facts then we can discuss what parts of the system need to be changed. ;)

We dont have to wait for specifications like it is the hidden manna from heavens. We have to discuss and vote for specifications. Specifications should be decided by active MN owners, not by managers hired by the lazy fatcat MN owners.
 
Last edited:
A lazy fatcat MN owner who gained the 1 third of total dash during the initialize process two years ago, he is oblidged to vote, because if he does not, then a decision could be made and the community could decide for example to change the protocol and take money (as a form of taxation) from fatcat MN owners. Thats why fatcat MN owners tend to hire managers, and tell them to vote against any such decision.

This is the bad scenario of course, we dont know if it is true, so you can always believe in another scenario, the good scenario where none of the above is valid.



We dont have to wait for specifications like it is the hidden manna from heavens. We have to discuss and vote for specifications. Specifications should be decided by active MN owners, not by managers hired by the lazy fatcat MN owners.

You clearly do not understand how the new system works. No one really does as it is not out yet. 2 or 3 week of Evan coding since that podcast and I guarantee he's come up with new stuff.

First of all, your first sentence is just pure innuendo and very dodgy. No one is obliged to do anything. No one can change the protocol except Evan, not even if 100% of Masternodes kicked and screamed about it. Where does it say Project Managers get to vote on anything? They'll, apparently, be managing funds and people and reporting expenses. Managers also do not decide on any specification in the Dash protocol.

"hidden manna from heaven", "discuss and vote specifications"? By "lazy fatcat MN owners" who probably don't know code, nor want to?

You clearly have no idea what's going on here.

.
 
First of all, your first sentence is just pure innuendo and very dodgy. No one is obliged to do anything. No one can change the protocol except Evan, not even if 100% of Masternodes kicked and screamed about it.

.

You ignorant, of course we can change the protocol !!! It is open source, remember? We get the code and form another community!
Like we did with stupid ignorant bitcoin owners, who didnt understand what the public account satoshi told them!!!

And let Evan alone, together with his dash protocol that implements a useless coin.
The power is in the community, the power is in trust, this is exactly where money's power resides.

If you dont understand that simple thing, you are just stupid.

Where does it say Project Managers get to vote on anything? They'll, apparently, be managing funds and people and reporting expenses. Managers also do not decide on any specification in the Dash protocol.

Managers are supposed to be the elected representatives of the lazy fat MN owners (who gained the one third of dash during the initialization process two years ago) and now they want to rest, not work at all, and only get profit from that .

Those lazy fat MN owners feel that they have to loby, in order to become stronger and protect the protocol from decisions that may change it.

Thats why they propose the elected manager scheme. It is their way to loby eachother, as long as they feel insecure (even if they own the 1 third of dash and many Masternodes).

This is the bad scenario of course, we dont know if it is true, so you can always believe in another scenario, the good scenario where none of the above is valid.
 
Last edited:
I originally asked for somebody who knows how the "new" system is supposed to work to post some more specifics in order to stop runaway speculation. This has not happened yet. Can everybody please stop posting wild guesses as to the workings or motivations until there are more facts presented?
 
There is absolutely nothing that can objectively be discussed at this point. All we can do is speculate. We only had a brief explanation on the podcast and a one line example on BCT. Testnet is right around the corner. Very soon we will have specifics to discuss.

A thousand times this.
 
Back
Top