April 2016 Budget Proposal

[yidakee]

Is that correct though? If the masternodes refuse to update their clients to the protocol version that the devs release, then wouldn't that be the final say?

Definitely yes, if the testnet release is the equivalent of opening it up to feedback, then we'll do that, but I just think it would be a better usage of everyone's time if the development direction was hammered out *first*, and then implementation, and then bugfixing. Not implementation first, and then development direction and bugtesting at the same time.

Absolutely not. You're mixing up some fundamental concepts. Let me try to explain

If 12.1 is a protocol change, then MN ops need to update, otherwise they loose payouts and voting power. Nothing else happens to the network. If it's not a protocol change, then don't need to update. Could be a bug fix for something else. But obviously, 12.1 will be protocol change that affects masternodes.
If 99,99% of Masternodes do not update, 0.01% of those who update will earn quite a lot of Dash proportionally. We've had numerous occasions in the past where multiple versions of the cliente coexisted in the Masternode network. But essentially, nothing structurally happens to the network.

The opposite happens with miners. If Dash rolls out a version that the miners do not agree and don't update, then the network does not update, even if 100% of MN ops update. In that case a strange paradox happens. The original Dash (lets call it Dash-A) chain continues, and whoever wants to follow the shortest chain (Lets call it Bash-B) is welcome to do it. The longest chain Dash-A is left by itself with no one to code for it, as it is Evan who owns the repository. Then the miners would have to all get together and find someone they collectively agree on, fork the Dash repo, bring out a new client and fork the blockchain into another chain (Dash-C). The original Dash chain would essentially stop rolling. After some time, Dash-B would be longer than Dash-A, and network would reconciliate, simply orphaning all of Dash-B's invalid blocks, and all would be resolved.

Testnet is 100% about opening up to feedback. That is the whole point of testnet. You must understand that implementing is not as simple as "hey, how about this XYZ idea of mine?" - it involves massive amount of coding and dependencies between logics. One must absolutely do their thing in one way, and one way only, for code to behave as intended. Development direction is decided by Evan and whoever he believes are good councillors. They extensively debate on a idea, and start coding solutions for it. It is not rare (as precisely again with 12.1 and Sentinels) where while coding, new ideas pop-up in his head.

They weave it all together, and when the team is confident something is really close to final draft, it's released on testnet to see how it behaves in a controlled environment in the semi-wild. People pick it up and try to understand it and break it. It is THEN that you fully understand the implications of his words in interviews, and only then you actually see what is happening. And then you have direct access to debate with the devs.. not because they are ignoring (which they are certainly not) ... but because they are now available to look at what's happening and what people think. People find bugs, or they say "hey how about this feature to work with that issue" within the predefined logic... If an idea is possible and works for the direction and vision of the project, they may very well implement it for a future 12.2.

.

 

[yidakee]

I disagree with you on this one. Masternodes have the final say in anything, be it development, marketing, or anything else. That's why it's called Decentralized "Governance" by Blockchain. Evan gave up a lot of power creating this system, and as a DAO, we are better for it. The MN operators are the stewards of the project, they will outlive all of us. Anyone is free to voice their opinion on future course, and if the Masternodes agree (and it is possible to be done) it MUST be done by someone. That is the whole point of the governance system.

We just had a long chat on Slack about this between community and core members.

For Dash Nation to succeed, we must respect our decision-making process. Otherwise, it's just a sham.

You are correct Tao, in the future. Not now. MN ops haven't 1/1000th the clue of what is possible to achieve with blockchain than Evan and the devs. We are building that future. Lets not destroy it by building pillars of sand.

Governance mean "usage of funds" - not vision and direction.

Again, Apple is a great example. Board members outed the genius with the vision. Look what happened there.

.

 

[TroyDASH]

Absolutely not. You're mixing up some fundamental concepts. Let me try to explain

If 12.1 is a protocol change, then MN ops need to update, otherwise they loose payouts and voting power. Nothing else happens to the network. If it's not a protocol change, then don't need to update. Could be a bug fix for something else. But obviously, 12.1 will be protocol change that affects masternodes.
If 99,99% of Masternodes do not update, 0.01% of those who update will earn quite a lot of Dash proportionally. We've had numerous occasions in the past where multiple versions of the cliente coexisted in the Masternode network.

The opposite happens with miners. If Dash rolls out a version that the miners do not agree and don't update, then the network does not update, even if 100% of MN ops update. In that case a strange paradox happens. The original Dash (lets call it Dash-A) chain continues, and whoever wants to follow the shortest chain (Lets call it Bash-B) is welcome to do it. The longest chain Dash-A is left by itself with no one to code for it, as it is Evan who owns the repository. Then the miners would have to all get together and find someone they collectively agree on, fork the Dash repo, bring out a new client and fork the blockchain into another chain (Dash-C). The original Dash chain would essentially stop rolling. After some time, Dash-B would be longer than Dash-A, and network would reconciliate, simply orphaning all of Dash-B's invalid blocks, and all would be resolved.

Testnet is 100% about opening up to feedback. That is the whole point of testnet. You must understand that implementing is not as simple as "hey, how about this XYZ idea of mine?" - it involves massive amount of coding and dependencies between logics. One must absolutely do their thing in one way, and one way only, for code to behave as intended. Development direction is decided by Evan and whoever he believes are good councillors. They extensively debate on a idea, and start coding solutions for it. It is not rare (as precisely again with 12.1 and Sentinels) where while coding, new ideas pop-up in his head.

They weave it all together, and when the team is confident something is really close to final draft, it's released on testnet to see how it behaves in a controlled environment in the semi-wild. People pick it up and try to understand it and break it. It is THEN that you fully understand the implications of his words in interviews, and only then you actually see what is happening. And then you have direct access to debate with the devs.. not because they are ignoring (which they are certainly not) ... but because they are now available to look at what's happening and what people think. People find bugs, or they say "hey how about this feature to work with that issue" within the predefined logic... If and idea is possible and works for the direction and vision of the project, they may very well implement it for a future 12.2.

If that is how it works, then in my opinion this is a huge problem.
If 99.99% of the masternodes disagree with a change to the protocol, then that change needs to be not able to succeed no matter what the development team does.

Yes, implementing is not simple. As you said, it is very complicated and involves a ton of coding. Therefore, shouldn't we make sure that the network actually agrees on the intended functionality BEFORE anyone even lifts a finger to start coding?

 

[yidakee]

If that is how it works, then in my opinion this is a huge problem.
If 99.99% of the masternodes disagree with a change to the protocol, then that change needs to be not able to succeed no matter what the development team does.

Yes, implementing is not simple. As you said, it is very complicated and involves a ton of coding. Therefore, shouldn't we make sure that the network actually agrees on the intended functionality BEFORE anyone even lifts a finger to start coding?

If that happens, MN ops would be angry and sell their stake, plummeting the price and weakening the network. So there is an equilibrium of power there, don't get me wrong.

MN's ops are intended to give continuance to the project, as are miners.

.

 

[TaoOfSatoshi]

If that is how it works, then in my opinion this is a huge problem.
If 99.99% of the masternodes disagree with a change to the protocol, then that change needs to be not able to succeed no matter what the development team does.

Yes, implementing is not simple. As you said, it is very complicated and involves a ton of coding. Therefore, shouldn't we make sure that the network actually agrees on the intended functionality BEFORE anyone even lifts a finger to start coding?

This is how it should work, yes. We are going to have our growing pains getting there, though. The status quo is hard to break.

 

[TroyDASH]

If that happens, MN ops would be angry and sell their stake, plummeting the price. So there is an equilibrium of power there, don't get me wrong.

MN's ops are intended to give continuance to the project, as do miners.

It seems we have a fundamental disagreement over who controls the network.

 

[yidakee]

It seems we have a fundamental disagreement over who controls the network.

As it stands, only miners control the network. Its a technical thing, not an opinion. What we ARE trying to do is build this thing so that in the FUTURE this is not the case.

Remember, we are originally a fork o Litecoin, and now Bitcoin. This wasn't build from scratch. Evan has a clear idea how to give MN ops the same power to control the network in the future (as well as solving the 51% attack problem and centralisation of mining)

We're just no there yet.

.

 

[TaoOfSatoshi]

The devs should submit their development proposal to the Masternode operators, who will most likely approve it, as they are doing a great job. Some controversial proposals for development will not, such as the proof of labour. Maybe in the future it will be reconsidered. All key areas of Dash development should be approved by the Masternode owners, IMHO, as they are "governing" the project via largest stake in it's success.

 

[yidakee]

The devs should submit their development proposal to the Masternode operators, who will most likely approve it, as they are doing a great job. Some controversial proposals for development will not, such as the proof of labour. Maybe in the future it will be reconsidered. All key areas of Dash development should be approved by the Masternode owners, IMHO, as they are "governing" the project via largest stake in it's success.

I fully agree with you at a philosophical standpoint, but not technical. For example, I didn't understand 1/10000000th of the proof of labour proposal, so I'd be scared to vote, even if it was the best idea ever.

.

 

[TroyDASH]

Absolutely not. As it stands, only miners control the network. Its a technical thing, not an opinion. What we ARE trying to do is build this thing so that in the FUTURE this is not the case.

Remember, we are originally a fork o Litecoin, and now Bitcoin. This wasn't build from scratch. Evan has a clear idea how to give MN ops the same power to control the network in the future (as well as solving the 51% attack problem and centralisation of mining)

We're just no there yet.

If we aren't there yet from a technical perspective, shouldn't we at least start acting like we are there? Wouldn't opening up those raw ideas to community feedback before implementation be the right thing to do regardless?
To me, governance doesn't just mean allocation of funds, it means decision-making.

 

[TaoOfSatoshi]

If we are to move forward in a cohesive way, and avoid these blowups like I witnessed on Slack today, we need to clarify who exactly is in charge of what, and stick by that decision. Are we "core-team" and community, or are we Dash Nation, all a team under the DAO? I really do think we need some form of constitution we all have to abide by. It's very important for unity.

 

[yidakee]

If we aren't there yet from a technical perspective, shouldn't we at least start acting like we are there? Wouldn't opening up those raw ideas to community feedback before implementation be the right thing to do regardless?
To me, governance doesn't just mean allocation of funds, it means decision-making.

I dont believe we should 100% start acting like that. Remember, some stuff already is, like the blocksize (which was yes) and the LP (which was no). And I'm sure more will come. But when MN ops are not fully qualified to understand structural concept of the basic building blocks of the original vision, then it's a huge risk to do it.

Imagine someone proposed to nuke x11 in favor of pure PoS, and the vote went YES because it benefitted big bagholders... this project would instantly collapse.

.

 

[TroyDASH]

I dont believe we should 100% start acting like that. Remember, some stuff already is, like the blocksize (which was yes) and the LP (which was no). And I'm sure more will come. But when MN ops are not fully qualified to understand structural concept of the basic building blocks of the original vision, then it's a huge risk to do it.

Imagine someone proposed to nuke x11 in favor of pure PoS, and the vote went YES because it benefitted big bagholders... this project would collapse.

That is a contradiction -- if the project would collapse then it wouldn't benefit the bagholders.
Money is quite the incentive. I think masternode operators are highly qualified to make decisions that will affect the value of their stake. I see zero downside to opening these things up to community feedback, unless the development team thinks that they will be able to detect every design flaw? Even if nothing else, having the discussion before implementation improves the relationship between the community and the development team, not to mention the previous point that the masternodes should be having the final say anyway.

 

[yidakee]

If we are to move forward in a cohesive way, and avoid these blowups like I witnessed on Slack today, we need to clarify who exactly is in charge of what, and stick by that decision. Are we "core-team" and community, or are we Dash Nation, all a team under the DAO? I really do think we need some form of constitution we all have to abide by. It's very important for unity.

I have no clue what happened in the open Slack as I'm not there. I also don't know what "Dash Nation" is or signifies. This is a financial payment processor project that looks to solve status-quo problems with hopes to promote a better tomorrow for the benefit of all. It's not a libertarian anti-institutional club. It's a an open-source decentralised project with an objective path, not a social experiment.

 

[TaoOfSatoshi]

I have no clue what happened in the open Slack as I'm not there. I also don't know what "Dash Nation" is or signifies. This is a financial payment processor project that looks to solve status-quo problems with hopes to promote a better tomorrow for the benefit of all. It's not a libertarian anti-institutional club. It's a an open-source decentralised project with an objective path, not a social experiment.

Feel free to post your opinion here, this is a talk we need to have before moving forward:
https://www.dash.org/forum/threads/dash-nation-constitution-discussion.8759/

 

[yidakee]

That is a contradiction -- if the project would collapse then it wouldn't benefit the bagholders.
Money is quite the incentive. I think masternode operators are highly qualified to make decisions that will affect the value of their stake. I see zero downside to opening these things up to community feedback, unless the development team thinks that they will be able to detect every design flaw? Even if nothing else, having the discussion before implementation improves the relationship between the community and the development team, not to mention the previous point that the masternodes should be having the final say anyway.

Exactly what I'm trying to get at. It doesn't make sense, at this point in time, to make the MN ops opinion dictate 100% of development vision. One bad decision could potentially collapse the project. When the project is mature enough, and miners AND MN ops have equal say, then everything changes instantly, and we'll be protected by a majority of both technical and developmental brainpower.

Right now how the funds are used, sure. If MN ops don't agree, they can always downvote the team's pay as protest. In the future, they'll be working with miners to actually force the direction if they don't like what is happening. But fact is that MN operators as a majority do NOT have an understanding as deep and Evan and devs. We are still a very very young project.

Dont get me wrong, I totally agree with you, again, we're just not there yet.

.

 

[UdjinM6]

I disagree with you on this one. Masternodes have the final say in anything, be it development, marketing, or anything else. That's why it's called Decentralized "Governance" by Blockchain.

TL;DR; I disagree.

Complete version:
No one should have final say in anything here, that's not how networks consensus works. Otherwise - you don't really need miners, merchants, exchanges, devs (wallet makers), users. Create your own masternode only network and live happy with it (if you can). How it really works is that majority of every group I mentioned + masternodes, all 6 of them must agree on smth in order for network to run as expected. It's Governance, not Government with a Prime Minister. I actually personally don't share Evan's vision of asking masternodes "every possible question", I think it's bad idea and 2MB block size voting was actually a fail which showed the weakness of Governance rather than the strong side imo. I stand from criticizing it because it actually doesn't really matter now, we are too small to hit even 1MB constraint currently so it basically won't hurt anyway. But technically speaking it was a weak decision which if implemented straightforward right now could make network more vulnerable to spam attacks without bringing anything positive to the table. I'd like to see masternodes voting moving towards funding decisions while technical decisions priority should be shifted to developers imo. This doesn't mean however that 2Mb block decision should be made by developers only - it's all about consensus, all 6 groups must participate and bring their pros and cons so that everyone would understand the possible outcome of implementation/adoption of such solution.

So imo network consensus in Dash should be smth like this:
Masternodes: which projects should we fund so that it benefits the whole ecosystem?
Developers: which technical solutions should we implement so that it benefits the whole ecosystem?
Miners: which chain should we secure so that it benefits the whole ecosystem?
Exchanges, Merchants and Users: which chain should we accept value from so that it benefits the whole ecosystem?

Bitcoin is missing the Self-Funding part and that what we should address, network consensus should still be a complex thing where everyone has it's voice.
So I'd say we should go with a greater degree of DF(unding)BB rather than pure DGBB. You still should be able to ask masternodes' opinion on some question that is not directly linked to funding itself via this (or similar) mechanism however, but that should/could be more a nice side effect rather than "The one and only mega Oracle that rules them all".

So again:
- Mining pools can vote via including some specific info into coinbase of the block the mined while individual miners can vote via selecting mining ports or switching pools completely
- Masternodes have a way to directly cast their vote via network protocol
- Developer can "vote" via code rollouts (which everyone else decide to use or not to use)
- Exchanges, Merchants and Users vote by simply using network to accept/move value (or not using it anymore)

The devs should submit their development proposal to the Masternode operators, who will most likely approve it, as they are doing a great job. Some controversial proposals for development will not, such as the proof of labour. Maybe in the future it will be reconsidered. All key areas of Dash development should be approved by the Masternode owners, IMHO, as they are "governing" the project via largest stake in it's success.

Development proposal of Core Team is already there: "Salary for DASH core team". If masternodes doesn't like what team is doing - "dash-cli mnbudget vote-many eac6392cd0d63e4b2ebd3c60da2d3e13137c892cd4cd1a8f3885077ac86b7487 no". That's easy
So basically, I disagree on the highlighted part of your post for the reasons I just described above. Plus one more thing: I hate to see this project to move from permissionless innovations to permissioned ones - that's boring and that's dead end imo.

I have no clue what happened in the open Slack as I'm not there. I also don't know what "Dash Nation" is or signifies. This is a financial payment processor project that looks to solve status-quo problems with hopes to promote a better tomorrow for the benefit of all. It's not a libertarian anti-institutional club. It's a an open-source decentralised project with an objective path, not a social experiment.

+ 1
@TaoOfSatoshi I'm fine with all excitement and social/community activities as long as you keep it to yourself (by "you" here and below I mean those who are interested in such activities, not you personally, of course). I had enough of so called patriotism here in real life and I don't want to be the part of the masses or whatever it's called. I never liked nationalism, I doubt I would like crypto-nationalism now but if someone needs some kind of unity or whatever - I'm not going to stop you but don't expect me to sign smth or swear on some kind of a constitution or whatever you are writing, just leave me alone and play your games without me.

 

[fible1]

I'm with @UdjinM6 and @yidakee. Masternodes hold the purse strings, but technical decisions should be led by the technical arm (devs). If extremely controversial, stakeholders can respond to these by several methods, such as cutting funding, forking, etc.

Pablo.

 

[rustycase]

My thanks to all participants in the discussion. It helps me learn.
My newbie opinion... I am coming around to seeing the inherent value of PoS.
Miners are free to vote with their feet, at any time.
Vote of a stake holder is proportional to the investment,
Best
rc