Dash Nation Consensus Discussion
- Thread starter TaoOfSatoshi
- Start date
Thank you. I stand corrected. I completely forgot, but just making a point really - should read -> Core Devs... I remember during the RC forking incidents this was heavily discussed.
By the way, anything else to add? In your opinion am I off base somehow in my answers?
.
demo
Well-known member
Ok then.
Lets have a vote about who should have merge permissions on github. This it tottaly rational, because the role of the tester is tottaly different than the role of the developer, and the role of the person who we trust to commit is again a totally different role. Lets legitimate Evan's position on github, so that he will not be a benevolent (untrusted) dictator anymore, but a trusted person. Because money is trust and trust is money. I think this is the best to be done, to resolve that issue.
And then, lets talk about the issue of the space-time assymetry of Dash, and the crime core team has commit against future dash generations. Lets talk about basic income. Because if you refuse to take into account future dash generations, then future dash generations will refuse to TRUST dash, and in that case dash is going to be yet another geek coin designed to fail, like bitcoin and the others.
Last edited:
Big words from a person who joined just a few weeks ago and barely had time to distinguish Dash from Dashcoin.
Vote on who controls github? Are you out of your mind? That is the entire point of why github exists the fork button you ding-dong!
Space-time assymetry? Seriously? I'd love to hear more on your String Theories regarding cryptos.
Shroedinger and Satoshi walk into an bar, and they didn't.
Heisenberg, Gobel and Evan walk into a bar
Heisenberg looks around the bar and says, “Because there are three of us and because this is a bar, it must be a joke. But the question remains, is it funny or not?”
And Gödel thinks for a moment and says, “Well, because we’re inside the joke, we can’t tell whether it is funny. We’d have to be outside looking at it.”
Evan looks at both of them and says, “Of course it’s funny. You’re just telling it wrong.”
Basic income? ... This is not a Proof of Stake coin. It's a Proof of Service coin. Period.
This thread is getting beyond ridiculous at this point
.
TaoOfSatoshi
Well-known member
You are of course entitled to your opinion, but I would caution you to not make a generalization about the entire thread based off of the posts of one contributor.
As I have cautioned you to about the blatant agenda behind these constant nagging cyclic attempts to create divise where there is none.
I quite literally mean the entire thread, this last post accusing Dash of being a quantum-physics black hole is just the cherry on top.
We have discussed and discussed and discussed, and all we get is accusations. We have answered questions numerous times, but keep getting splattered with them as if they hadn't at all even been read. Numerous core team members and core devs have come here to set things straight, yet the same gang of 2 or 3 (now 4) keep coming back trying to sway public perception with what now is just complete nonsense.
At the start, this was a valid discussion. It quickly spun the other way. You 3 or 4 people do not represent the majority of anything.
Why don't you put your money where your mouth is and actually propose what you are proposing to actually see if there is any interest by the Masternode network?
But all of this is completely worthless at this point. It is getting absolutely ridiculous, to say the very least.
.
TaoOfSatoshi
Well-known member
Why do you have this attitude of "us vs. them"? Divise? Accusations? Straw men. Show me a post where I attempt to divide, in fact I've stated the opposite more than once. Where have I accused anyone of anything?
From where I stand as a community builder, it is your posts that are divisive. My goal is to obtain clarification, and try to build a more consensus-based system (decentralized governance), as I see us purporting to be in the media. If this concept only applies to budgets, lets clarify that. I for one would like to see it extended to other areas. That doesn't make me ridiculous...why this constant need to label everything?
Just let the discussion take its course. I'll see everyone tomorrow.
All you are saying/asking/proposing has been addressed and answered multiple times now.
Clarification only occurs when your questions are answered, as they have been multiple times already, and you acknowledge you've received such answers, which you don't. You may not like it, but that's another issue altogether.
It is you opinion what you're saying, and I respect that. You don't have to agree with them, but clarification has been given.
The perception you have about our DAO is not correct I'm sorry to say.
You can build your consensus-based decentralised governance system, absolutely,go for it, but your concepts about it clash with how Dash actually operates.
If you think I am mistaken, and everyone else, please prove us wrong - ask the Masternode OPs, why on earth aren't you doing it?
With this post I rest my case and leave you guys to keep discussing it.
.
This is a really good joke, featuring my favorite characters.
As far as the conversation as it is going, I always think about Dr. Marshall Rosenberg and his non-violent communication. Even if we're all just PPPPPTs - Pretty Poor Protoplasm Poorly Put Together - we all might benefit from his wisdom. (I promise, it's even funny)
TroyDASH
Well-known member
Part of the miscommunication here might be that what I am looking for is not so much an explanation of what the protocol is or what it allows. I am on board with you on everything you say about describing what masternode votes are and the concept of dgbb in the protocol. I also understand that the vision for the protocol for governance in the future may extend further than where we are now. All of that is great (and is worth being able to explain clearly and be able to point to some material so that newcomers, and existing community members, can understand this). But in addition to the explanation of how the protocol works, and how our self-organizing teams are formed, I am asking this particular self-organizing team if they are willing to voluntarily put forward a policy. You said that masternode votes on project direction issues are for information-only but that the core team would take the vote into consideration. That's a start, but it sounds a little weak and unclear for a policy. On the other hand, promising to obey the masternode vote would likely be too strong a policy. Can we explore this a little more?
One of us is misjudging the general amount of support for having this discussion. Since you think this is just an extreme vocal minority, I thank you for your patience with putting up with this. If you are tired of the discussion I'm not going to call you out or insult you, but conversely I would ask that you afford us the courtesy to not discourage others from continuing the discussion until we reach more clarity. I think we have already made quite a bit of progress here and encourage everyone to please stay positive -
demo
Well-known member
Of course we need a vote on who controls the official github of dash. And if the person who controls the official github of dash refuses to give the password to the elected one, community will fork. The threat of forking will force the benevolant dictator to surrender. Because if the does not, community will left and the benevant dictator will become a dictator without peasants.
Space-time symmetry in a coin means that old generations have the same chance to coin money than the new generations. Also it means that every newcomer gets a portion of digital cash whenever he arrives to the community, and recieves also an ammout of cash in time periods. Of course this requires the definition of online identities, so that no person have multiple accounts and receive more money than others. This can be solved by using a web of trust or by using any other proof-of-individuality scheme.
Last edited:
Solarminer
Well-known member
Stop referring to this as beating a dead horse. We are coming up with solutions to problems that we see with these new budget system changes.
The forking response is not the only solution(nor is accepting the release to see what is in it, or having faith in Evan). When the initial budget and voting system was first proposed, it received many comments to change it. It actually was changed before it went into the release. I think Evan and the other developers are very good at understanding the community and observing what is the ideal balance. So past history does provide proof that our comments are reviewed and used in each iteration of the budget.
This isn't about having a protocol that won't fail by testing it on testnet. This is about creating the best solution that will not give unbalanced powers to managers without any care about the future or Dash. If we order a sausage pizza, are we focusing on making a pepperoni pizza that is done perfectly and hot? Let's get the pizza choice right first, before we worry about how to cook it.
So what am I talking about the changes that I see are unbalanced:
- Multiple managers approve expense reports AFTER expenses are paid. This puts undue risk on the ones paying expenses, as they never can know for sure if their expenses will be paid. It also puts no priority on expenses....except by arbitrary decisions by the multiple managers.
- Multiple managers/employers managing each employee/contractor. This is really not an effective strategy. Employees don't understand which manager has priority over their duties or which duties are the most important.
- How is a group of managers going to decide if an employee is doing what they should be if they are all giving that employee different tasks. Some might get done on time, some not?
- Managers making funding decisions bypass the best aspect we have now, a collateral based funding mechanism. If 10 managers can make decisions on if a project gets vetoed or approved, then each will effectively have the voting same power as 350 masternodes(350,000 Dash). This is a big change from the system we have now! (I have already pointed out the problems this causes, and will refrain from posting that again.)
We need to be focused on building a decentralized system. Not centralizing the system we have now. I feel that a lot of the discussion was started because Terpin was voted out. Well, I think many are realizing that it was actually the right decision because the company was not performing. The goal shouldn't be to avoid a similar situation - this actually showed the system working.
If we start with the funding.....That comes from the masternode votes. So any funding decisions need to be voted in before work starts or materials are purchased. This is is what gives priority to which projects are worked on. The only management structure that can be built on that is to prepare and coordinate proposals that masternodes can vote on. There can also be advisory roles to give information about projects before they get voted on and offer advice to project submitters before submitting. We can tweak the system we have now to add some functionality that is missing. Any management roles should probably happen outside of the voting and budget funding protocol.
- Ability to split payments to individuals inside a project. That split can be determined by a principal project owner. This will help a contractor/company pay all employees at once.
- Ability to have a higher vote out threshold for contracts. There still needs to be a way to cancel a contract....it just should not be determined by 1 vote like it is now.
- Offer a way to change the duration(only can be lowered) or amount(only can be lowered) of a proposal without paying a new proposal submitter fee.
@Solarminer ,
I think it is a separate topic but I guess Tao don't to make a little off-top here. I believe you have made some wrong assumptions about the managers (therefore we need to wait for testnet release or specs - there are too many assumptions - including my assumptions):
I have to say I am really surprised to see this: "There can also be advisory roles to give information about projects before they get voted on and offer advice to project submitters before submitting.". Few weeks ago, when I proposed the same role (but called it "consultant" and it was more focused on serving MN owners) you were the biggest opponent of this idea. Good to see your opinion evolving
I think it is a separate topic but I guess Tao don't to make a little off-top here. I believe you have made some wrong assumptions about the managers (therefore we need to wait for testnet release or specs - there are too many assumptions - including my assumptions):
- "Multiple managers/employers managing each employee/contractor" - I have never seen this idea written and never heard about it. From where it comes from?
- "How is a group of managers going to decide if an employee..." - my understanding is that project managers are going to control projects (not employees) - this is a big difference. Why? Here is my understanding of the process:
- Sponsor (MN network) votes on the proposals submitted by vendors.
- Sponsor hires PMs to control approved projects (hiring PM = voting on his proposal too) - so from the sponsor perspective PM and vendor are "employees"
- Vendor works on the project delivery and cooperates with PM by providing status updates and sharing results
- PM controls project status (money, deliverable, schedule, time, quality) and reports it to the sponsor (MN network)
- Based on the report from PM, sponsor makes a decision about project continuation or cancellation (voting)
- Part with expense approvals is not clear to me at the moment so I do not write anything about it
- "Ability to split payments to individuals inside a project" - I believe that this should not be concern of MN network or PM. Vendor is a separate entity it is not our concern how the budget is split internally on the vendor side.
- "Offer a way to change the..." I think that there should be a change management process indeed (and not only to lower but also to extend project parameters). Each change could be voted separately but not necessarily as a new proposal
I disagree with this "The only management structure that can be built on that is to prepare and coordinate proposals that masternodes can vote on." - in my opinion this coordination is even more needed during the project duration - to provide independent, consistent and professional information about the project status (as an input for voting).
I have to say I am really surprised to see this: "There can also be advisory roles to give information about projects before they get voted on and offer advice to project submitters before submitting.". Few weeks ago, when I proposed the same role (but called it "consultant" and it was more focused on serving MN owners) you were the biggest opponent of this idea. Good to see your opinion evolving
Last edited:
demo
Well-known member
We dont have to wait for the release of any specs. This is a fundamental error. We have to discuss and vote about specs before their release, and the core team must come here, and discuss and vote also.
We do not make assumptions. Propositions is what we are making. We do not accept the core team to arrive suddently carrying the ten commandments, and command us. If there is some of you having the mentality of the slave who waits to be commanded, please try to understand that this is not all people's mentality.
So the procedure of specs production should be tottaly reversed.
Small decisions should be put into polls, and these polls should depend eachother.
For example:
Should we go to France? Yes/No/Other
|________result No/Other----> end
|________result Yes---> Should we go by plane? Yes/No/Other
|________result Yes---> Should we stay in a Hotel? Yes/No/Other
|________result Yes---> Should we go by plane? Yes/No/Other
|________result Yes---> Should we stay in a Hotel? Yes/No/Other
|________result Yes-----> In a double room? Yes/No/Other
From that tree of polls, the specs will be extracted automatically, according to the votes of the people.
Last edited:
TaoOfSatoshi
Well-known member
Great! See how discussing things first can change people's ideas? This conversation about Sentinel would have been better had before work began, IMHO, as it is a major change.@Solarminer ,
I think it is a separate topic but I guess Tao don't to make a little off-top here. I believe you have made some wrong assumptions about the managers (therefore we need to wait for testnet release or specs - there are too many assumptions - including my assumptions):
I principle I agree with what you wrote here:
- "Multiple managers/employers managing each employee/contractor" - I have never seen this idea written and never heard about it. From where it comes from?
- "How is a group of managers going to decide if an employee..." - my understanding is that project managers are going to control projects (not employees) - this is a big difference. Why? Here is my understanding of the process:
- Sponsor (MN network) votes on the proposals submitted by vendors.
- Sponsor hires PMs to control approved projects (hiring PM = voting on his proposal too) - so from the sponsor perspective PM and vendor are "employees"
- Vendor works on the project delivery and cooperates with PM by providing status updates and sharing results
- PM controls project status (money, deliverable, schedule, time, quality) and reports it to the sponsor (MN network)
- Based on the report from PM, sponsor makes a decision about project continuation or cancellation (voting)
- Part with expense approvals is not clear to me at the moment so I do not write anything about it
- "Ability to split payments to individuals inside a project" - I believe that this should not be concern of MN network or PM. Vendor is a separate entity it is not our concern how the budget is split internally on the vendor side.
- "Offer a way to change the..." I think that there should be a change management process indeed (and not only to lower but also to extend project parameters). Each change could be voted separately but not necessarily as a new proposal
I disagree with this "The only management structure that can be built on that is to prepare and coordinate proposals that masternodes can vote on." - in my opinion this coordination is even more needed during the project duration - to provide independent, consistent and professional information about the project status (as an input for voting).
I have to say I am really surprised to see this: "There can also be advisory roles to give information about projects before they get voted on and offer advice to project submitters before submitting.". Few weeks ago, when I proposed the same role (but called it "consultant" and it was more focused on serving MN owners) you were the biggest opponent of this idea. Good to see your opinion evolving
Back to the main topic:
I'm speaking for myself, but I've listened to your input. I now believe we need a core team (but still disagree on the implementation), I see what the roles and responsibilities of professional contributors are, and that the community is free to take initiative to contribute in their own way.
I still see vagueness in the role of Masternodes, however. Are they strictly for budgeting, or can they be used for technical input, as the precedent of the much-publicized blocksize vote established?
Cherry picking technical votes is not the answer. Can the Masternodes vote on technical issues or not?
Thanks for your patience with this discussion.
Solarminer
Well-known member
Now we are getting somewhere. I really appreciate this response. This is the dialog I am looking for.
The multiple managers are not assumptions. I actually derived them from the github posts. Let's go through the parts.
https://github.com/evan82/sentinel/blob/master/docs/rules.md
- Employees must work for an Employer (Probably a primary and secondary)
- Employers can fire employees, but there must be consensus among the project manangers
Ok so with your summary, a project is bundled with a project manager. The project manager still has control over funds in some way. If the funds are still coming from the blockchain, this is better. If the project manager is actually storing the funds this is really bad (then they would be taxed and subject to theft). I still have some issues with a project manager being able to stop funds. Maybe there is a way to allow an overthrow decision with a masternode vote to keep the product manager honest. This is really the part that needs to be clearly defined.
Actually, there was a change to the "expenses are paid by consensus" line. Looks like someone is listening. LOL. Anyway, this is phrased better, but I still don't understand how priority of paying expenses is set. Maybe it is only allowed under a specific project which is preallocated from the budget. So if the project can use 1000 dash, expenses up to that can be paid. If more is needed, the project needs to wait for another funding cycle or a new proposal with a vote. Feeling better about this part now.
Well, I am not saying splitting payments is the right way to do it....just a thought. I am thinking that if numbers get bigger distributing the funds in smaller chunks will have less risk. But you are right a supplier getting funds is under their control, we don't need to address that.
Well that is interesting. Implementing a change proposal option instead of a new proposal. Maybe this needs a lower voting threshold if certain things stay the same. No fee to change or something.
Yeah, there may be some value for coordination during a project - especially if it has a multiple month budget.I disagree with this "The only management structure that can be built on that is to prepare and coordinate proposals that masternodes can vote on." - in my opinion this coordination is even more needed during the project duration - to provide independent, consistent and professional information about the project status (as an input for voting).
I have to say I am really surprised to see this: "There can also be advisory roles to give information about projects before they get voted on and offer advice to project submitters before submitting.". Few weeks ago, when I proposed the same role (but called it "consultant" and it was more focused on serving MN owners) you were the biggest opponent of this idea. Good to see your opinion evolving
Ah, yes. See I don't always think everything is a bad idea.
You can read my posts on bitcointalk, I was in favor of a consultant and advisor service to inform masternodes. I was not in favor of voting for a consultant team that voted on behalf of masternodes.
Solarminer
Well-known member
Apologize for wandering off.
Technically, the masternodes can vote in/out developers that would be pushing a technical issue. So really the better way to set all of this up is to have each task tied to a budget. Then the budgets can vote in or out each issue/fix/solution and given highest priority. But the driver to work on any single item isn't always getting paid.
So if someone submitted a budget for 2000 dash to increase the blocksize to 16MB. Then got 80% support of the masternodes. You could say 2000 dash is getting spent on the blocksize change. Enforcing who works on it or how fast it gets done would be another issue. And technically, the network has already spent 5 dash to implement a 2MB blocksize.
AndyDark
Well-known member
"So really the better way to set all of this up is to have each task tied to a budget"
In my experience the solution you are proposing would be a terrible way to manage a software development project and typically leads to chaos in terms of trying to build a quality product and take it to market.
To give you an analogy, let's imagine Sony is building the PlayStation 5 and has a new system where the shareholders can vote on individual tasks and hire professionals to do that...
What is the CPU, GPU, sub system architecture? What is the OS? How many USB ports will it have? What is the backwards compatibility? What is the thermal solution? Where should it be manufactured? How should it be marketed?
Right now Sony's shareholders appoint a single team to achieve that which is internally organized and allocated basically a single budget. They work together internally and develop the product and take it to market and report to the shareholders at stages. This is essentially the same for every successful company on the planet.
But by opening up each part of that design / production lifecycle to different groups without a single lead you just end up with a mess, that's over budget and overtime and fails pretty much all the requirements in my experience.
Because by removing the brain of that project team and replacing it with the shareholders to manage, you are removing the professionalism, experience and knowledge required to do it effectively and replacing it with a disparate group each with their own interests / agendas and probably lack of experience, otherwise they would be doing the work and not be the shareholders in the first place.
What you end up with is a meltdown where shareholders would be constantly fighting to micromanage each part of the development and without any leaders who can view the whole lifecycle from the top down and make the correct/difficult decisions to balance all the various elements that need to be considered and resources that need to be directed (including human resources) to deliver a cohesive and quality product.
It's just a basic fact of engineering great products that you need leaders with the vision and experience in how to do that leading the show whether that's an iPhone, Ferrari, Operating system or space shuttle. How that is decentralized in Dash is that rather than a benevolent dictator at the top, we split areas of the project into teams each with their own benevolent leaders, and those leaders can be replaced - the core team is an example, Evan is leading it with the permission and funding of the network. If the network disapproved, it could cut off his funding and has $40k or whatever per month to hire a new team for that specific role, i.e. development of the core project. That is about as decentralized as any organization that wants to succeed should go as far as my experience goes.
So micromanagement of project is something that Dash needs to actually prevent to survive, same as in any company with shareholders (and i have invested in 1 medium-sized venture that failed largely because the shareholders gained too much power and were then able to use their voting rights to micro manage the technical development and it ultimately cost the shareholders a lot of money and with what you are proposing I can see a similar thing happening actually).
What tends to happen in that situation too is that developers basically end up downing their tools and saying 'this is ridiculous' with having the direction changed and disconnected ideas from different people who think they know what their doing but don't have the professional experience. One can imagine the same scenario in many types of project where creators are tasked to do something and the stakeholders don't let them 'get on with it' but instead jump in and try to change everything mid flow - it just ends up with a mess.
Another major thing that goes wrong with this model is you have a massive increase in inefficiency caused by the increase in reporting and communication required for developers forced to have to present everything they were doing at different levels and have this 'approved' by a mass of stakeholders constantly throughout the lifecycle, who are all fighting each other to get things done how they wanted.
Therefore the best way to develop a software product and take it to market is to appoint an experienced team that works well together and fund them to do that and get stakeholders to approve and fund that at a high level with control/reporting limited to intervals where deliverable / goals are pre-agreed and metrics are used to monitor that and asses that.
Hope I explained it well enough. I'd be interest to hear if anyone with professional experience in product development or team management would disagree with this and why.
Andy
itscrazybro
Active member
@AndyDark Well said. Here is an article from a lawyer who reviewed the Slock.it DAO governance model. Their model is similar to what we have now and he picks it apart pretty well. I think Evan is on the right track. http://www.cameronhuff.com/blog/slock-it-dao-paper/index.html