Should Platform run on all nodes or should Platform run only on High Performance nodes ?

[vazaki3]

See : https://www.dashcentral.org/p/decision-vote-improve-proposal-system-dc



I am asking DCG to respect the 10% treshold like it did with its above decision proposal 'Increase Proposal System Flexibility & Efficiency', specially on such an important topic of how to start Dash Platform and the limited options provided by DCG.

By the way, the alternative decision proposal that was launched by a group of masternode owners (MNO-Plan) also followed above mentioned process,
see : https://www.dashcentral.org/p/decision-vote-improve-proposal-system-mn

DECISION-VOTE-IMPROVE-PROPOSAL-SYSTEM-DC

MNOwatch - VoteHashGroups 2020-11-25-08-25-44 - 639 YES votes (approx 76 individuals)
MNOwatch - VoteHashGroups 2020-11-25-08-25-44 - 434 NO votes (approx 132 individuals)

The question is, how many among those who voted against the specific decision rule 2 years ago, are still active members of the Dash community now?
For how long the dash community shall respect a decision made by people who left the community?
And also back then, the Dash voters refused the new decision rule. They did not approved the existing status quo, did they?

 

[qwizzie]

And also back then, the Dash voters refused the new decision rule. They did not approved the status quo, did they?

No. The network simply rejected both decision proposals based on its topic and arguments. It was not a rejection of the process behind these decision proposals.
A process that was pretty clear from the start.

 

[vazaki3]

No. The network simply rejected both decision proposals based on its topic and arguments. It was not a rejection of the process behind these decision proposals.
A process that was pretty clear from the start.

It was neither a rejection, nor an approval of the 10% supermajority. Thats my point.
Not to mention the other point. For how long the dash community shall respect a decision made by people who left the community?
10% supermajority is the decision of Evan. For how long shall we respect it? Is Evan a god who gave to Dash the 10 commandments?

I think the 10% supermajority (as long as any other decision method) should be questioned.
And questioned again and again, in case those who support the method leave the Dash-game.

 

[qwizzie]

It was neither a rejection, nor an approval of the 10% supermajority. Thats my point.
Not to mention the other point, for how long the dash community shall respect a decision made by people who left the community?
10% supermajority is the decision of Evan. For how long shall we respect it? Is Evan a god who gave to Dash the 10 commandments?

I think 10% supermajority must be questioned, and re-questioned again in case those who support it left the game.

You can always create a decision proposal (for just 1 dash !) yourself, to question the 10% supermajority for decision proposals.
See how the network responds.

 

[vazaki3]

You can always create a decision proposal (for just 1 dash !) yourself, to question the 10% supermajority for decision proposals.
See how the network responds.

Yes...This is exactly the right (and first) thing @QuantumExplorer should do, if the questions the 10% supermajority decision rule.

But I am one step beyong, and I question all the decisions that were made by dead/inactives and that affect the lives of the active members of Dash.
This objection requires really hard coding in order to be implemented.
Because all the invalid rules that were decided by inactives and form dash's current workflow should be suppressed, and new rules that the active members support should be enacted. This requires a carefull classification of the currently valid rules and votes, and a heavy coding. It cannot be resolved by just asking an one dash question.

One rule to ring them all!

 

[xkcd]

@QuantumExplorer Don't even try to weasel your way around a passing Governance Proposal (10% Supermajority) on a matter of such importance, because if that´s what you plan to do, expect multiple plaintiffs bringing you personally (and everyone else in leading positions from DCG who overstepped by authorizing it without approval from the MNO network) before a U.S. district court for damages.

Please stop with these threats, Dash is not a security and any final decision on how the network re-configures to support Platform will be down to a network vote.

 

[GrandMasterDash]

@GrandMasterDash I wholeheartedly agree with your wish to allow participation from a broader and less-elite public. But we already have several Masternode Shares solutions, even such which offer fractional voting. Everyone can already participate in MN rewards with much less than 250 Dash right now.

I am okay with trustless masternode solutions but not everybody wants to be go through the hassle of finding reliable participants, even if there is a fine for early withdrawals. I know I personally want to be the one in control and taking responsibility for host selection etc.

I think it's okay to offer both options, shares or direct participation.

 

[GrandMasterDash]

Please stop with these threats, Dash is not a security and any final decision on how the network re-configures to support Platform will be down to a network vote.

I dunno, perhaps not a security but the Dash DAO is a recognized legal entity. I would need legal advice but there might be a case for reasonable expectations by long term holders.

 

[stan.distortion]

It's a recognised legal entity that's had a long-standing vulnerability where a small number of large stakeholders can gain veto power over the decision making process (and that's built in so I guess that makes it legitimate).
Now we have a proposed update that's would allow a few large stakeholders complete control over what's supposed to be our killer feature and is optimised for a small number of high end servers.
Add to that tampering with intellectual property that could constitute evidence in the event of a dispute (technical pre-proposal thread deletion) and the possibility of a Blockstream style takeover of the project just went from remote to likely.
In the Darkcoin days "distributed and permissionless" went without saying but failing to state it clearly may have introduced a major vulnerability.

 

[QuantumExplorer]

I am sorry that many here do not understand the difference between network consensus and funding consensus. Network consensus is anything 2/3rd (or so) believe it to be. That's that. At the beginning of Dash we used the BIP9 consensus mechanisms, now we use the https://github.com/dashpay/dips/blob/master/dip-0023.md mechanism giving more power to masternode owners.

There has never been a +10% supermajority in consensus decisions. The protocol has changed countless times. Thinking that it's now needed because we have a more contentious issue is wrong.

Funding consensus is for funding. We are not going to stall the project because we have 10 or so solutions and none get 85% of the vote.

 

[vazaki3]

We are not going to stall the project because we have 10 or so solutions and none get 85% of the vote.

I also faced the same problem, and I solved it that way..

Each method in order to be selected should initialy respect itself, then the most loved method is selected.

Let me explain further....

In case you are stalled you put the 85% decision rule under question.

If the 85% decision rule is NOT supported by 85% of the voters, then this decision rule is obviously not valid because it does not fullfill its own prerequisites. In that case alternative decision rules should be put into vote and the most voted one should be selected (provided that it fullfills its own prerequisites).

If the 85% rule is supported by 85% of the voters, then the rule remains valid and the project is legitimately stalled. It should remain stalled until some of those who support the 85% rule change their mind or become inactive/dead, or until new voters are subscibed to the electorate and change the 85% balance.

 

[qwizzie]

There has never been a +10% supermajority in consensus decisions.

For the second time, see :

https://www.dashcentral.org/p/decision-vote-improve-proposal-system-dc (DCG)
https://www.dashcentral.org/p/decision-vote-improve-proposal-system-mn (Alternative solution by group of MNO's)

Both following the same process, both respecting the 10% treshold.

2. Process

The voting and proposal process consists of two phases:

• Phase 1 - the two proposal options are evaluated against each other
• Phase 2 - the favored option from Phase 1 is evaluated against our current system

In Phase 1 (this phase, this month) you are asked to vote for which option you prefer. Regardless of degree, the option with the most net (yes minus no) votes will proceed to the next phase (next month). DCG will implement the Phase 2 upgrade option if it exceeds the normal 10% net vote criterion in Phase 2. In the unlikely event the higher ranked proposal exceeds the 10% net yes votes during Phase 1, Phase 2 would not be necessary.

Edit for clarity: "net vote" means "yes" votes minus "no" votes.

Both decision proposals were put on the network by the Dash Trust Protectors, who submitted these two decision proposals on behalf of DCG (DCG plan) and a group of masternode owners (MNO plan), DTP acted as a neutral third party here.

If you want to disregard or ignore DCG own decision proposal, where DCG specifically refers to the +10% supermajority, then so be it.
I find it very dishonest behavior from you, stating that there has never been a +10% supermajority in consensus decisions, even after me showing you that there has been precisely that.. by DCG.

Link : https://www.dash.org/forum/threads/...h-performance-nodes.53374/page-21#post-232910

If you don't even want to admit this, then what is the point of this all ?

 

[QuantumExplorer]

@qwizzie Now I get the confusion. This was not a protocol consensus decision. DCG leadership at the time had decided to use that threshold the following way:

"Regardless of degree, the option with the most net (yes minus no) votes will proceed to the next phase (next month). DCG will implement the Phase 2 upgrade option if it exceeds the normal 10% net vote criterion in Phase 2."

That is not a network consensus decision. That was DCG polling on what to code. I did not participate in this discussion, but I would imagine it was done this way because the two options were do it this way or do nothing and DCG leadership at the time wanted an overwhelming consensus to do this. And at the same time the do nothing was a viable option.

There have been other times where the polling happened in a different way if I'm not mistaken.

 

[qwizzie]

@qwizzie Now I get the confusion. This was not a protocol consensus decision. DCG leadership at the time had decided to use that threshold the following way:

"Regardless of degree, the option with the most net (yes minus no) votes will proceed to the next phase (next month). DCG will implement the Phase 2 upgrade option if it exceeds the normal 10% net vote criterion in Phase 2."

That is not a network consensus decision. That was DCG polling on what to code. I did not participate in this discussion, but I would imagine it was done this way because the two options were do it this way or do nothing and DCG leadership at the time wanted an overwhelming consensus to do this. And at the same time the do nothing was a viable option.

There have been other times where the polling happened in a different way if I'm not mistaken.

It was both a polling of the network and a decision proposal, split in two phases.

Phase 1

Decision Vote: Improve Proposal System [DCG-Plan]
https://www.dashcentral.org/p/decision-vote-improve-proposal-system-dc (DCG)

Decision Vote: Improve Proposal System [MNO-Plan]
https://www.dashcentral.org/p/decision-vote-improve-proposal-system-mn (Alternative solution by group of MNO's)

This is a decision proposal to increase the proposal system’s spending limit (i.e., its flexibility) and incentivize increasing the value of funded proposals (i.e., its efficiency).

Phase 2 : which most likely involved voting on 'Decision Vote: Improve Proposal System [DCG-Plan]' looking at above voting results.

www.dashninja.pl/proposaldetails.html?proposalhash=d41000486d6da24dd1e339e8340b24d52131ea6212f09de81e97f00c4d582318
(??)

It looks like Phase 1 was just the polling part, and Phase 2 had the requirement to pass the 10% treshold. Since Phase 2 proposal was most likely also downvoted, it is difficult to find that specific proposal back on dashninja. I suspect it was either above (heavily downvoted) decision proposal i found on dashninja, or maybe it no longer exists.

We currently have the same situation where the network will need to make a decision on how to start Dash Platform. The same conditions apply here (the options need to pass 10% supermajority) and if the network rejects all options presented, then that means DCG will have to come up with a new option that is acceptable to the network. Even if that means DCG having to take the time to think about such a new option and/or researching it.

So i do hope DCG takes that extra time they recently got (+1 month) to come up with an option, that will have less of a problem passing the 10% supermajority, besides just those centralised 4K / 10K HPM solutions or that Platform on all nodes solution (with its severe safety issues). Or DCG risks seeing its solutions get bypassed for alternative solutions from Dash community members or risks seeing none of the options pass....

Also i would still like an answer on my question what a 500MN 1K HPMN looks like with regards to yield, masternode count and HP masternode count ?

 

[QuantumExplorer]

The same conditions apply here (the options need to pass 10% supermajority) and if the network rejects all options presented, then that means DCG will have to come up with a new option that is acceptable to the network. Even if that means DCG having to take the time to think about such a new option and/or researching it.

It will be impossible to find a solution that will please everyone. The goal is network consensus.

Saying "the same conditions apply" is disregarding the original statement I made. It doesn't matter that there was once a proposal that DCG made like that. That's not our consensus mechanism for network upgrades. If you go by "code is law" then code has always been that you don't need +10% supermajority, you need a majority of miners and a supermajority of Masternodes. If previous DCG management decided to require a 10% of total nodes (yes - no) supermajority that was their purview. But to say it's required by our system is wrong. It is not and it has never been.

 

[qwizzie]

So if the decision proposals each have less then 100 voters (way below 10% treshold, no matter how people vote) you just gonna look at the yes votes and declare a winner ? Or if there are a lot of participants, but they heavily downvote the decision proposals (forcing it under the 10% treshold), you just gonna look at the yes votes and declare a winner ? Well, good luck with that.

This is not network consensus, this is just focusing on yes votes to declare a winner.
This has nothing to do with Dash Governance. It will most like break consensus acceptance, among the Dash community.

At least knowing how you view this, there is little point voting ABSTAIN in the upcoming decision proposals. Also little point to voting NO it seems.
It has a very handy fixed YES outcome for DCG, no matter what.

Why even participate ? I guess we should still participate for the alternative solutions and hope that they receive more yes votes.
What a mess.

My trust in DCG has dropped to a seriously low level.

 

[QuantumExplorer]

So if the decision proposals each have less then 100 voters (way below 10% treshold, no matter how people vote) you just gonna look at the yes votes and declare a winner ? Or if there are a lot of participants, but they heavily downvote the decision proposals (forcing it under the 10% treshold), you just gonna look at the yes votes and declare a winner ? Well, good luck with that.

This is not network consensus, this is just focusing on yes votes to declare a winner.
This has nothing to do with Dash Governance. It will most like break consensus acceptance, among the Dash community.

At least knowing how you view this, there is little point voting ABSTAIN in the upcoming decision proposals. Also little point to voting NO it seems.
It has a fixed YES outcome for DCG, no matter what.

Why even participate ? I guess we should still participate for the alternative solutions and hope that they receive more yes votes.

You are jumping to conclusions. 100 yes votes would not be enough. That is not our consensus mechanism. You need more than 60% of EVERY masternode, not just 100 nodes. This means of the 3900 or so nodes you would need about 2340.

For protocol decisions the network votes, just not through the governance system, they vote by running or not running the software.

I am stating facts on how our system works, it's in the code and is written like that. If you would like to change how the system works you can propose a change.

Obviously DCG does not want to take time building software that people won't start, so we poll our network in advance to make sure we don't get into these situations.

 

[qwizzie]

We will see how this strategy works out for DCG, personally at this point i am done with DCG.

Not taking into account the 10% treshold on decision proposals = no support for DCG from me, from now on (no point for me on waiting on the upcoming decision proposals and its possible outcome before making such decision, when DCG already formulated its position and intentions so clearly).

DCG is not only taking a path away from decentralisation, but is also taking a path away from establishing broad voting consensus among masternodes on important topics.

That is not a path i am willing to follow or support.

 

[QuantumExplorer]

@qwizzie This is factually wrong. We are not actually changing anything. Look at the code, see how it is written. We are going by how the code is written. If you want to change it you need to propose a proposal that can gather enough support.

I believe right now we have one of the most decentralized projects needing the most people to enact a new version in order for a change to occur. If you can find me a more decentralized project you should tell me which one it is.

I have shown the math around decentralization, I have done everything I can to explain things, but if you want to continue to believe something that isn't true there is nothing I can do at this point.

 

[vazaki3]

I have shown the math around decentralization, I have done everything I can to explain things, but if you want to continue to believe something that isn't true there is nothing I can do at this point.

For the glory of Rome!!!!! You have not shown the math around decentralization. Where are the individuals in your math?

I think the calculations of @QuantumExplorer and @virgile do not take into account the number of individuals, do they?

 

[QuantumExplorer]

For the glory of Rome!!!!! You have not shown the math around decentralization. Where are the individuals in your math?

In the part about stakeholders. Top whale has 270k Dash, next whale has 220 Dash, etc. This is taken into account.

 

[vazaki3]

In the part about stakeholders. Top whale has 270k Dash, next whale has 220 Dash, etc. This is taken into account.

Lets suppose that the individualities you discovered in mnowatch.org (and on which your math was based ) are 100% accurate.

How many individuals include the 10k HPMN solution, how many individuals include the 4k HPMN, and how many individuals include the 1k solution? Can you give us the number of individuals for every solution? If you cannot, I can give it.

23 individuals for the 10k solution
34 individuals for the 4k solution
122 individuals for the 1k solution.

Which solution is the most decentralized?

 

[QuantumExplorer]

My definition around decentralization is on how many individual bad actors does it take to take the system down. This is the point of decentralization: to have a robust system that can not be easily taken down.

You are talking about ease of access to being able to run Platform. I do get why you think this way, in PoW system the more nodes there are the harder it is to take down the system. But this is not the case for PoS.

 

[vazaki3]

My definition around decentralization is on how many individual bad actors does it take to take the system down?. This is the point of decentralization: to have a robust system that can not be easily taken down.

You are talking about ease of access to being able to run Platform. I do get why you think this way, in PoW system the more nodes there are the harder it is to take down the system. But this is not the case for PoStake.

And according your calculations, how many bad actors can be found among the specific 23 individuals of the 10k HPMN solution?

Row	Name	Node(s)	Technique	Votes?	Date created
1	binance	270	Manual	No	-
2	weejohnny	229	Manual,Blockchain,TemporalAnalysis	Yes	-
3	bluewhale	128	Manual	Yes	-
4	bottles	120	Manual	No	-
5	masterblaster	103	Manual,VoteHistory,TemporalAnalysis	Yes	-
6	august	089	Manual	No	-
7	spirit	082	Manual	Yes	-
8	crowdnode	072	Manual	Yes	-
9	gerry	052	Manual	No	-
10	genesis	042	Manual	Yes	-
11	tendies	034	Manual	Yes	-
12	randy	032	Manual	No	-
13	axe	027	Manual	Yes	-
14	BrazHelpAllo	026	Automatic	Yes	Sun Feb 27 02:05:54 PM UTC 2022
15	toby	025	Manual	No	-
16	DIFSHelpMall	024	Automatic	Yes	Sun Feb 27 02:05:54 PM UTC 2022
17	xnx1v	023	Manual	No	-
18	strider	022	Manual	No	-
19	euvo	019	Manual	Yes	-
20	incuplatElec	015	Automatic	Yes	Sun Feb 27 02:05:54 PM UTC 2022
21	grower	014	Manual	No	-
22	coloBrazElec	011	Automatic	Yes	Wed Mar 9 01:26:33 PM UTC 2022
23	barny	010	Manual	Yes	-

And how many bad actors can be found among the specific 122 individuals of the 1k solution ?

And what about the agents?
Are the agents good or bad actors?
Is it easier for the agents to shut down a system controled by 23 individuals, or a system controled by 122 individuals?

 

[QuantumExplorer]

@vazaki3 To be clear what 1k solution are you referring to?

 

[vazaki3]

@vazaki3 To be clear what 1k solution are you referring to?

Whatever 1k solution. Although I prefer the 1k opt-in solution, as long as the 4k and 10k solutions are by default opt-in.

Lets analyze.
(1k, 10k both mandatory). How can 10k be mandatory? We dont know the 10k whales, so we cannot force them to participate in the Platform. We may have a clue about them, but it is just a clue.
(1k, 10k both opt in). This is a possible scenario.
(1k opt in, 10k mandatory). Again, how can 10k be mandatory? We dont know the 10k whales, so we cannot force them to participate in the Platform.
(1k mandatory, 10k opt in). This is also a possible scenarion.

So the 10k solution is always opt in. And if we do not set a mandatory total collateral for the Platform to start, then the 10k solution may become tottaly centralized, because maybe we will have very few 10k whales that they will be interested.

 

[QuantumExplorer]

Okay, let's talk about the 1k Opt in Solution, what % will the top whale control of the network? In the 10k opt in solution what % will the top whale control of the network?

It's exactly the same.

So why so I say the system is more secure with 10k? With higher collateral there are less HPMNs in the system which makes it less likely to have rare events occurring.

What is important in a PoS system isn't the amount of individuals, it's the distribution of power of the individuals. In fact... with stronger nodes we could afford to increase the tendermint consensus threshold parameters to put more nodes in a validator set.

The more nodes per validator set the more the system is hungry for resources. This is not possible on the weak machines that many have currently running core software.

 

[vazaki3]

Okay, let's talk about the 1k Opt in Solution, what % will the top whale control of the network? In the 10k opt in solution what % will the top whale control of the network?
It's exactly the same.

That is obvious. I wonder why we even mention it.

So why so I say the system is more secure with 10k? With higher collateral there are less HPMNs in the system which makes it less likely to have rare events occurring.

So you admit that the current DashPlatform system cannot run with more than 23 synced databases? Have you tested it? At max, how many synced databases the tendermint+groveDB chorum supports?

Have you ever tried to test DashPlatform+groveDB by simulating quorum members that have low or irregular bandwidth? Where is your testbed? Are you sleeping on it?

If this is the case , and you cannot support a tendermind+groveDB chorum of many synced databases, and as long as a PoSe is not yet implemented, why dont you run a lottery and give the DashPlatform+groveDB to as many random masternodes as the system can handle?

What is important in a PoS system isn't the amount of individuals, it's the distribution of power of the individuals. In fact... with stronger nodes we could afford to increase the tendermint consensus threshold parameters to put more nodes in a validator set.
The more nodes per validator set the more the system is hungry for resources. This is not possible on the weak machines that many have currently running core software.

This is a problem of proof of Service. You may have a 1k masternode who offers a wonderfull PoSe, and an 10k masternode whose PoSe is a mess.
The quality of services is not a strong argument, as long as no PoSe is implemented.

Still my most important question remains unanswered...

And what about the agents?
Are the agents good or bad actors?
Is it easier for the agents to shut down a system controled by 23 individuals, or a system controled by 122 individuals?

 

[Bridgewater]

so we poll our network in advance

Wouldn't the gold standard for doing this be the 2MB block size increase? We touted that particular "vote" as a major DAO success to the entire crypto world as something Bitcoin could not do.

The budget system is set up to distribute Dash to a winning proposal. It also happens to be able to be used to gauge network sentiment in more subjective ways that do not have binding rules attached to them. Unless DCG or the Trust actually have specific policy as to how a network poll must be conducted and what type of results adhered to, I think I agree that anybody -- including DCG -- can use the budget voting data however they want to. It does clutter up the system and cloud its purpose a bit though, so some consistency in DCG polling would be good for the good of the community, so the voters can have a better idea of what to expect and if/how they should vote.

 

[QuantumExplorer]

Wouldn't the gold standard for doing this be the 2MB block size increase? We touted that particular "vote" as a major DAO success to the entire crypto world as something Bitcoin could not do.

The budget system is set up to distribute Dash to a winning proposal. It also happens to be able to be used to gauge network sentiment in more subjective ways that do not have binding rules attached to them. Unless DCG or the Trust actually have specific policy as to how a network poll must be conducted and what type of results adhered to, I think I agree that anybody -- including DCG -- can use the budget voting data however they want to. It does clutter up the system and cloud its purpose a bit though, so some consistency in DCG polling would be good for the good of the community, so the voters can have a better idea of what to expect and if/how they should vote.

The 2MB block size increase was not contentious. And there was also a binary choice. We sadly have a multiple choice question that is highly contentious.

As soon as platform goes live we can have contracts for voting, and we can perform these types of votes with ease, until then we can either use the voting system used for trust protectors (that has very little engagement), or we can use the dao system that was made for funding.