April 2016 Budget Proposal

[yidakee]

Vision =/= Implementation


Lets hope Evan nails it.

Vision precedes implementation, so I don't really see where you're coming from. It's great to discuss the subject. It's even better to propose objective solutions. It's gold to commit changes to the code. How many features were proposed that failed to see the light of day?

If you know Xcoin/DRK/Dash's history, you know how many "impossible" feature Evan has nailed. Now the dev team keeps growing with numerous super talented guys. Also, how time and time again the direction of this project went with the community voice and opinion.

TroyDASH - everything can be reversed. You just need network consensus, plus Spork technology makes this a breeze. Others fear hard-forks, we eat them for breakfast.

I'm not hoping, just patiently waiting.

.

 

[TroyDASH]

Vision precedes implementation, so I don't really see where you're coming from. It's great to discuss the subject. It's even better to propose objective solutions. It's gold to commit changes to the code. How many features were proposed that failed to see the light of day?

If you know Xcoin/DRK/Dash's history, you know how many "impossible" feature Evan has nailed. Now the dev team keeps growing with numerous super talented guys. Also, how time and time again the direction of this project went with the community voice and opinion.

TroyDASH - everything can be reversed. You just need network consensus, plus Spork technology makes this a breeze. Others fear hard-forks, we eat them for breakfast.

I'm not hoping, just patiently waiting.

.

Good luck reversing it after we have already established contracts that we told our clients were immutable. What message would that send?

What we *need* is a way to protect against or mitigate scenarios like the Terpin fiasco. What we *don't need* is to rush to the first solution we see without thinking about the unintended consequences. Again, a "contract" that is binding on one party but not the other, isn't a contract. All you have to do is point out *ONE* situation where the network should be able to exit a contract, which is trivially easy, to completely invalidate the idea that we need to bake immutable budgets into the protocol. Clearly we should do something but immutable budgets isn't the answer.

 

[yidakee]

Good luck reversing it after we have already established contracts that we told our clients were immutable. What message would that send?

What we *need* is a way to protect against or mitigate scenarios like the Terpin fiasco. What we *don't need* is to rush to the first solution we see without thinking about the unintended consequences. Again, a "contract" that is binding on one party but not the other, isn't a contract. All you have to do is point out *ONE* situation where the network should be able to exit a contract, which is trivially easy, to completely invalidate the idea that we need to bake immutable budgets into the protocol. Clearly we should do something but immutable budgets isn't the answer.

We're not rushing anything at all. 12.1 is due preliminarily for August and that is exactly what testnet is for. It was exactly the Terpin "fiasco" that sparked Evan's imagination, just like all previous road bumps. Sporks were created exactly because of the RC1 RC2 and RC3 forking. Failure is a brilliant seed for innovation.

I don't think you fully understand how this works. Nothing is immutable. Everything can be reversed. Even the blockchain itself. Plus we have Sporks that make it easy peasy. These contracts are intended to be irrevocable, so in a sense yes, immutable you could say, given the specific network state. That does not mean if something goes wrong it's a doomsday scenario.

If someone was able to subvert the system, Spork is activated, protocol reversed, and the proposal nuked. That is certainly not nice, ideal, fun, or even wanted, but anyone is always welcome to keep that fork alive is they so wanted.

Again, it is exactly because an honourable contract was made with a contractor, and the project was unable to keep it's word, that this is happening. The only fiasco here is being unable to keep our end of a deal with someone.

.

 

[thelazier]

There is no reason this needs to be the case! Default server lists are easily updated in the electrum-dash client to add new volunteers, and servers interconnect via IRC to share their connection information (so each server can deliver this info to clients).

The current Electrum-Dash server database takes up to 24hrs to produce on SSD, and server operation is not uncomplex. This presents a significant barrier to new potential server operators.

In addition to producing a highly scalable, highly available network, we're producing ready-to-run databases, server docker images & start-scripts, and all the configuration for more operators to more easily run their own servers. Databases are already available via IPFS, and we'll have all the tools posted to github this week.

May I have any progress update for all the tools (ready-to-run databases, server docker images & start-scripts, and all the configuration for more operators to more easily run their own servers) posted to github ? How to access the database via IPFS ?
Possibly you may posted somewhere but I don't see it. Thanks.

 

[TroyDASH]

We're not rushing anything at all. 12.1 is due preliminarily for August and that is exactly what testnet is for. It was exactly the Terpin "fiasco" that sparked Evan's imagination, just like all previous road bumps. Sporks were created exactly because of the RC1 RC2 and RC3 forking. Failure is a brilliant seed for innovation.

I don't think you fully understand how this works. Nothing is immutable. Everything can be reversed. Even the blockchain itself. Plus we have Sporks that make it easy peasy. These contracts are intended to be irrevocable, so in a sense yes, immutable you could say, given the specific network state. That does not mean if something goes wrong it's a doomsday scenario.

If someone was able to subvert the system, Spork is activated, protocol reversed, and the proposal nuked. That is certainly not nice, ideal, fun, or even wanted, but anyone is always welcome to keep that fork alive is they so wanted.

Again, it is exactly because an honourable contract was made with a contractor, and the project was unable to keep it's word, that this is happening. The only fiasco here is being unable to keep our end of a deal with someone.

.

Rushing might not be the right word. The point is, from what I am able to gather there has been little or zero effort on the part of those who are actually developing the code, to discuss this here. All I am hearing are assertions about this is what we need, this is what is happening.

Something like this is not a problem that can really be caught in testnet. It's not a bug, it's a design flaw that is going to get swept under the rug until we eventually run into one of those scenarios where the network needs to have a way to exit a previously-approved multi-month budget. In the meantime when we are providing info to clients, are we telling them that their contracts are immutable? Having subsequent protocol updates or using sporks is great for dealing with unexpected problems, but it's a terrible plan to deal with something when we already know that this is going to come up inevitably if we implement budget prioritization with no exit method.

 

[yidakee]

Rushing might not be the right word. The point is, from what I am able to gather there has been little or zero effort on the part of those who are actually developing the code, to discuss this here. All I am hearing are assertions about this is what we need, this is what is happening.

Something like this is not a problem that can really be caught in testnet. It's not a bug, it's a design flaw that is going to get swept under the rug until we eventually run into one of those scenarios where the network needs to have a way to exit a previously-approved multi-month budget. In the meantime when we are providing info to clients, are we telling them that their contracts are immutable? Having subsequent protocol updates or using sporks is great for dealing with unexpected problems, but it's a terrible plan to deal with something when we already know that this is going to come up inevitably if we implement budget prioritization with no exit method.

There is no talk about it because everything is still in Evan's head and on his private computer in embryonic state. He's just started to build the thing. So I guess there is nothing to do but speculate. I'm sure Evan has this in mind as this is both relevant and obvious. In the meantime, everyone else is busy doing what they're doing. This is definitely a valid point. And the more discussion on the subject the better, especially on possible implementation solutions.

.

 

[TroyDASH]

There is no talk about it because everything is still in Evan's head and on his private computer in embryonic state. He's just started to build the thing. So I guess there is nothing to do but speculate. I'm sure Evan has this in mind as this is both relevant and obvious. In the meantime, everyone else is busy doing what they're doing. This is definitely a valid point. And the more discussion on the subject the better, especially on possible implementation solutions.

.

Point taken, although I do have to question the order that these things are happening. It sounds to me like this is way further along than in an embryonic state in Evan's head -- apparently they are on track to release this in testnet in just 2-3 weeks? It might be better for the developers to have asked for more feedback before they started implementing. Based on what I heard in Evan's interview from last week, the implementation of this is actually going to be a bit different than anything I have even seen here on the forum. If it turns out the masternode operators don't like the direction they went in their development, then the dev team would have just wasted a lot of time and effort.

 

[yidakee]

Point taken, although I do have to question the order that these things are happening. It sounds to me like this is way further along than in an embryonic state in Evan's head -- apparently they are on track to release this in testnet in just 2-3 weeks? It might be better for the developers to have asked for more feedback before they started implementing. Based on what I heard in Evan's interview from last week, the implementation of this is actually going to be a bit different than anything I have even seen here on the forum. If it turns out the masternode operators don't like the direction they went in their development, then the dev team would have just wasted a lot of time and effort.

I beg to differ. Masternode operators do not control the direction of development. They do control how project proposal funds are allocated.
At any point can anyone, anywhere, fork the project and develop their own version of Dash based on whatever primitives they believe are best.
For example, anyone could even propose funding from them to pursue that route. All you really need is network majority. So ultimately, it is still the miners who decide where the longest chain goes.

Evan, as the founder and main developer of this project is not directly accountable to anyone. That does not mean he is a "dictator" and just does what the heck he feels like it. He's steered away from his path in favour of the community voice in the past. He proposed a vote on the block size increase through DGbB, and respected the vote. But ultimately, this is his baby.

Why not wait for testnet and do what all of us love to do? Try our best to break it! Find logic flaws. Engage in debate directly with devs. That's how things are actually built around here. Not that talk isn't relevant, but going round in circles speculating doesn't achieve much.

.

 

[TroyDASH]

I beg to differ. Masternode operators do not control the direction of development. They do control how project proposal funds are allocated.
At any point can anyone, anywhere, fork the project and develop their own version of Dash based on whatever primitives they believe are the best.
For example, anyone could even propose funding from them to pursue that route. All you really need is network majority. So ultimately, it is still the miners who decide where the longest chain goes.

Evan, as the founder and main developer of this project is not directly accountable to anyone. That does not mean he is a "dictator" and just does what the heck he feels like it. He's steered away from his path in favour of the community voice in the past. He proposed a vote on the block size increase through DGbB, and respected the vote. But ultimately, this is his baby.

Why not wait for testnet and do what all of us love to do? Try our best to break it! Find logic flaws. Engage in debate directly with devs. That's how things are actually build around here. Not that talk isn't relevant, but going round in circles speculating doesn't achieve much.

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.

 

[TaoOfSatoshi]

I beg to differ. Masternode operators do not control the direction of development. They do control how project proposal funds are allocated.
At any point can anyone, anywhere, fork the project and develop their own version of Dash based on whatever primitives they believe are best.
For example, anyone could even propose funding from them to pursue that route. All you really need is network majority. So ultimately, it is still the miners who decide where the longest chain goes.

Evan, as the founder and main developer of this project is not directly accountable to anyone. That does not mean he is a "dictator" and just does what the heck he feels like it. He's steered away from his path in favour of the community voice in the past. He proposed a vote on the block size increase through DGbB, and respected the vote. But ultimately, this is his baby.

Why not wait for testnet and do what all of us love to do? Try our best to break it! Find logic flaws. Engage in debate directly with devs. That's how things are actually built around here. Not that talk isn't relevant, but going round in circles speculating doesn't achieve much.

.

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.

 

[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