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

[Bridgewater]

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.

You mean it was not contentious as determined subjectively by community observers? Obviously the clear vote result proved that it was not contentious after-the-fact.

Perhaps the way to avoid contention when using the budget funding system to poll the network is to submit only binary choices.

 

[vazaki3]

Perhaps the way to avoid contention when using the budget funding system to poll the network is to submit only binary choices.

Binary options are misleading. At least 3 options. Yes/no/other

Would you like:
a) me to kill you
b) me to slaughter you
c) other

Dont forget the "other" option, otherwise you are doomed.

 

[Bridgewater]

Binary options are misleading. At least 3 options. Yes/no/other

Would you like:
a) me to kill you
b) me to slaughter you
c) other

Dont forget the "other" option, otherwise you are doomed.

I don't understand. Those would all be independent proposals. If the overall desire of the network voters was not to be killed, then they would vote NO on a) and NO on b) and a strong YES on the c) choice would indicate that another proposal needs to be submitted, which they might ultimately vote YES on (but that is already partially implied with NO votes for a and b).

 

[vazaki3]

I don't understand. Those would all be independent proposals. If the overall desire of the network voters was not to be killed, then they would vote NO on a) and NO on b) and a strong YES on the c) choice would indicate that another proposal needs to be submitted, which they might ultimately vote YES on (but that is already partially implied with NO votes for a and b).

"Kill you" or "slaughter you" are similar, thus obvious.
But some options are not obvious.
Some tiny details may result a very different outcome.
Devil is in the details.
Thats why the "other" option is very important, it can be used in case the A and B options are misleading.

Even if A and B are independant proposals, the possible votes should always be YES/NO/OTHER, where OTHER indicates that there is an alternative proposal that the electorate should investigate (and the proposal owner obviously censors its existance) or that there is a proposal that is about to arrive soon.
OTHER could also sign that the proposal is a troll one so we should not take it into account (although in that case you have better abstain rather than vote "OTHER").

 

[Bridgewater]

"Kill you" or "slaughter you" are similar, thus obvious.
But some options are not obvious.
Some tiny details may result a very different outcome.
Devil is in the details.
Thats why the "other" option is very important, it can be used in case the A and B options are misleading.

Even if A and B are independant proposals, the possible votes should always be YES/NO/OTHER, where OTHER indicates that there is an alternative proposal that the electorate should investigate (and the proposal owner obviously censors its existance) or that there is a proposal that is about to arrive soon.
OTHER could also sign that the proposal is a troll one so we should not take it into account (although in that case you have better abstain rather than vote "OTHER").

If you're saying that each proposal should have those three options (YES/NO/OTHER) then the NO and OTHER options should in theory produce the same binary result of NO. If the submitter wanted to know if he should take the positive action of "killing" versus not killing, only the YES gives that.

What you're saying is that the OTHER would equal a "NO, BUT...". However this opens the door to interpretation and contention, with the possibility of the submitter deciding to count the OTHERS as YES with any number of justifications.

I understand your point about not having a way to object to the poll question itself though. I don't know if that's possible with our current system. Maybe the ABSTAIN?

 

[vazaki3]

If you're saying that each proposal should have those three options (YES/NO/OTHER) then the NO and OTHER options should in theory produce the same binary result of NO. If the submitter wanted to know if he should take the positive action of "killing" versus not killing, only the YES gives that.

What you're saying is that the OTHER would equal a "NO, BUT...". However this opens the door to interpretation and contention, with the possibility of the submitter deciding to count the OTHERS as YES with any number of justifications.

The OTHER option is a social option. It signals to the next voter that there is not only a yes or no, but there is also another option that the proposal owner probably hides and censors.

#666

 

[stan.distortion]

I'd agree with you on the binary options, others could certainly work but it's hard enough to get MN's to vote so complications wont help. Platform certainly offers the opportunity for much more sophisticated and tailored voting but participation will always be tricky.

 

[vazaki3]

I'd agree with you on the binary options, others could certainly work but it's hard enough to get MN's to vote so complications wont help. Platform certainly offers the opportunity for much more sophisticated and tailored voting but participation will always be tricky.

An option (stupidly named "abstain") is already available in the budget system.
"Abstain" option should be renamed to "other" , as long as abstain means I do not vote at all.
So the "other" option already exists when voting in the budget, and should be used wisely.
It should be used as a social option, in order to inform the next voter for the case the proposal owner misleads the electorate or censors other alternative proposals-solutions in his proposal text.

 

[stan.distortion]

The situation in reverse could work out well, concentration of wealth is gonna happen regardless of how many MNs run, that's just how it works in the real world and for the MN's that might not be not a bad thing. They provide security and coordination, full duplication on high spec hardware makes sense, bulletproof security but it doesn't need massive amounts.

That will look like the dark ages of crypto someday and probably soon because this will inevitably turn into a performance race at some stage and inefficient tech wont stand a chance but the tried and tested (and unbroken) tech will still give a lot of confidence.

 

[GrandMasterDash]

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.

I'm glad you are recognizing the sensitivity of this proposal. Does it not make sense to hold such proposals to the highest of standards? - instead of advocating for a lower threshold because of personal bias.

Especially for living in Thailand, you should know to take the Middle Way and not take the extreme path.

The 500/1K path (or 250/1K) path) looks like the Middle Way to me.

 

[GrandMasterDash]

The situation in reverse could work out well, concentration of wealth is gonna happen regardless of how many MNs run, that's just how it works in the real world and for the MN's that might not be not a bad thing. They provide security and coordination, full duplication on high spec hardware makes sense, bulletproof security but it doesn't need massive amounts.

That will look like the dark ages of crypto someday and probably soon because this will inevitably turn into a performance race at some stage and inefficient tech wont stand a chance but the tried and tested (and unbroken) tech will still give a lot of confidence.

Do you know why Solana was not added to THORChain? It was rejected because of the extreme high node specs. Of course, Platform owners are rewarded but this reward system is intentionally designed to limit participation. For, if it were like the Lightning Network with truly optional participation, we would not have these problems.

 

[stan.distortion]

Do you know why Solana was not added to THORChain? It was rejected because of the extreme high node specs. Of course, Platform owners are rewarded but this reward system is intentionally designed to limit participation. For, if it were like the Lightning Network with truly optional participation, we would not have these problems.

I'm not talking about Platform, if that can't make efficient use of any and all resources available then it won't go the distance, just masternodes. It would apply to full nodes too ofc but that's the price you pay to handle craploads of (monetary) transactions with absolute security and it shouldn't be nesessary to run a full node for anything other than an MN.

 

[QuantumExplorer]

I'm glad you are recognizing the sensitivity of this proposal. Does it not make sense to hold such proposals to the highest of standards? - instead of advocating for a lower threshold because of personal bias.

I am more advocating for any solution that works. As for the threshold, I am also just explaining what we currently have for consensus. In the end DCG will have to chose a solution to code based on the most voted solution, and the network will either chose to activate it or not. And right now the power of choosing that solution is in the hands of the network.

As for the 250 MN/1K HPMN solution it does seem to actually work, but the estimated returns fall to about 4.2% as I showed before. If the network votes for this, well I think it's not in our best interest, but it definitely does work. It also has higher platform fees which is somewhat of a turn off.

500/1k costs the network enough to lower returns instead to about 5%. It also seems to work (but I need someone to verify).

In the end with these solutions we are paying for much more costs than we need with no advantage except having more people being able to participate.

I think the better solution is we start off with 1k/10K or 1K/4K (with masternode shares, so all those with 1K Dash can participate) and then once we have PoSe and can do sharding in a few years we go for 250/1k. If platform does take off it makes sense to do it this way because we can use all those extra nodes for horizontal scaling. Something that we can not do right now. Right now, having more nodes than 100 is not very useful other than for decentralization aspects.

 

[GrandMasterDash]

I dunno, I can't help you, your bias is too strong and seemingly unwilling to compromise.

 

[vazaki3]

Right now, having more nodes than 100 is not very useful other than for decentralization aspects.

In case your DashPlatform software cannot support more than 100 nodes, and in case you dont trust the individualities that mnowatch discovered (although you used them in order to do your math and support your cause) then why dont you run a lottery and give to 100 random masternodes the license to host the Dashplatform?

 

[QuantumExplorer]

I dunno, I can't help you, your bias is too strong and seemingly unwilling to compromise.

It's not about compromise, I am giving the numbers, are you okay with a 4.2% return? If so then make a proposal for that solution and vote on it. Maybe DCG itself will make the proposal because it does technically work. I will have to think about that and confer with other board members.

 

[xkcd]

An option (stupidly named "abstain") is already available in the budget system.
"Abstain" option should be renamed to "other" , as long as abstain means I do not vote at all.

Abstain is necessary because once you vote Yes or No, you cannot undo that vote, so Abstain is the only way to negate your vote at that point.

 

[DASHvestor]

@QuantumExplorer

You already made your intent clear by now, DCG feels no longer any need to honor the wishes of the MNO network and to respect whether a Governance Proposal (10% Supermajority) is passing or not passing.
I hope you understand what you are causing, because if you don't respect the outcome of Governance Proposals, you are responsible for Splitting the entire Network.
You are going to cross the point-of-no-return and once crossed, stay assured that a considerable portion of the MNOs will cast Automatic No Votes for all future DCG Funding Proposals until the outcome of such a raped Governance Proposal is again fully respected and fully restored.

Understand that when enacting an unpassed (=rejected) Decision, it is your and DCG sole responsibility, and you will be held accountable to the full effect of the law before an Arizona district court.

 

[QuantumExplorer]

@QuantumExplorer

You already made your intent clear by now, DCG feels no longer any need to honor the wishes of the MNO network and to respect whether a Governance Proposal (10% Supermajority) is passing or not passing.
I hope you understand what you are causing, because if you don't respect the outcome of Governance Proposals, you are responsible for Splitting the entire Network.
You are going to cross the point-of-no-return and once crossed, stay assured that a considerable portion of the MNOs will cast Automatic No Votes for all future DCG Funding Proposals until the outcome of such a raped Governance Proposal is again fully respected and fully restored.

Understand that when enacting an unpassed (=rejected) Decision, it is your and DCG sole responsibility, and you will be held accountable to the full effect of the law before an Arizona district court.

Once again, DCG doesn't have the power to enact a change on the network. We can only supply software. It's up to masternode owners to run or not run that software.

 

[DASHvestor]

Once again, DCG doesn't have the power to enact a change on the network. We can only supply software. It's up to masternode owners to run or not run that software.

An Arizona judge will eventually explain you the fallacy of your assumptions before sentencing you to damages.
What you mention would only have merit if you would release software for all the different variants/solutions, only then MNOs would have a real choice.
Staying on outdated versions may not constitute having a valid choice.
Releasing only the software for 1 kind of solution equals taking the decision, even to the contrary of the will of the MNO network, as you made it already clear that you don´t need a passing Governance Proposal to enact whatever you like.

 

[peter]

Releasing only the software for 1 kind of solution equals taking the decision

IMHO you're completely wrong. You can modify the software, promote it, ask other MNOs to run your version, and so on. And every single MNO is free to do that.

 

[qwizzie]

The way i see it :

If these decision proposals do not pass the treshold of 10% but DCG still uses the yes votes of these failed decision proposals to declare a winner, it will most likely become a case for the Dash Trust Protectors. As it will be a situation where DCG for the first time explicitly goes against the wishes of the network, and with an existing precedent where DCG previously (2 years ago) did adhere to the treshold of 10% (and saw its decision proposal fail spectacularly in the end, during phase 2). I suspect it is the fear of failing again with their decision proposal(s), that is driving their decision to not adhere to the 10% treshold this time.

The Dash Trust Protectors have the power (if certain conditions are met) to reassign the DCG Board in case masternode owners request it and also have a duty to hold DCG accountable to the Dash network and ensure that DCG is working in the best interests of Dash.

See : https://zaimirai.com/dash-trust-protectors/

Hopefully it never comes to that. But seeing the current limited (and in my view rather low quality) DCG options to start Dash Platform and DCG firm decision to not adhere to the 10% treshold, i am not sure DCG is currently working in the best interests of Dash.

 

[TheNetworkIsBiggerThanYou]

after an initial reactionary response, where I was concerned about the perceived complexity of the proposed solutions, my concern now is reserved almost exclusively around censorship resistance of platform. If we can get any reasonable guarantee that platform can't be censored by a small handful of HPMNs then I think we have reason to be optimistic about this network upgrade.

My secondary concerns are more downstream and related to future optimizations and changes as new technology and the tokenomics of the network changes. Will we be able to make changes that are a) technically feasible (is the solution extensible) and b) socially appropriate (will there be damage, perceived or otherwise, from making changes to block rewards, etc. going forward)?

 

[DASHvestor]

IMHO you're completely wrong. You can modify the software, promote it, ask other MNOs to run your version, and so on. And every single MNO is free to do that.

Nobody who is lacking the technical expertise can do what you propose. And that´s probably everybody except a few Core/Platform developers.
You know that something like that could even cause one (or more) Forks of the project, which could seriously damage the projects market-cap.
We have the possibility of Voting (and Sporks) in order to prevent unintended Forks.
Why would you advocate something that could potentially result in a Fork?
Perhaps you don´t really advocate a Fork, because you know that only very few people would be technically versed enough to pull it off.

So basically all you say is "You can do nothing against DCG not respecting Governance Proposal outcomes" or "Defend yourself against DCG if you can".
Neat discussion we are having here.

 

[GrandMasterDash]

My secondary concerns are more downstream and related to future optimizations and changes as new technology and the tokenomics of the network changes. Will we be able to make changes that are a) technically feasible (is the solution extensible) and b) socially appropriate (will there be damage, perceived or otherwise, from making changes to block rewards, etc. going forward)?

HPMN create tokenomic complexity down the line. For example, say the network wants to further expand the number of masternodes, this would no doubt impinge on HPMNOs.

Also, who's to say DCG might want to later introduce a third node class, perhaps archive nodes, or smart contracts or something else. No one is going to provide guarantees, for even if they did, a few years down the line they will say, "I'm not responsible for other people's promises".

I don't know why they can't just build it like the Lightning Network, which has no upper limit to the number of nodes.

 

[DASHvestor]

HPMN create tokenomic complexity down the line. For example, say the network wants to further expand the number of masternodes, this would no doubt impinge on HPMNOs.

Also, who's to say DCG might want to later introduce a third node class, perhaps archive nodes, or smart contracts or something else. No one is going to provide guarantees, for even if they did, a few years down the line they will say, "I'm not responsible for other people's promises".

I don't know why they can't just build it like the Lightning Network, which has no upper limit to the number of nodes.

What makes no sense is to increase collateral for aiming at relatively few Platform Nodes, when the criteria should rather be based on Hardware resources,
like bandwidth score, ping latency score, available space etc.
They want platform to be fast-as-hell, but have obviously totally forgot how to enforce just that.
It would require masternodes to internally have at least a 24hour benchmark score (average) for bandwidth, ping latency, available space etc.
so that masternodes could compete on a hardware-based level.
Coding something like that (hopefully without it requiring another 8 GB of RAM memory) could be tricky only for the reason that bandwidth and latency is usually measured between two destinations (IP addresses), but such fair scores would have to be assigned to single masternodes, in order to distinguish the fastest from the lamest Nodes.

 

[stan.distortion]

It's worth having a read over GNUnet, it already has a lot of those aspects covered and a whole host of other security, storage and networking features. Not saying it's the ideal solution, I'd imagine Platform would need something far more tailored to its needs and there are probably far better starting points out there but it may offer solutions to some of the problems.

https://grothoff.org/christian/habil.pdf

 

[TheNetworkIsBiggerThanYou]

What makes no sense is to increase collateral for aiming at relatively few Platform Nodes, when the criteria should rather be based on Hardware resources,
like bandwidth score, ping latency score, available space etc.
They want platform to be fast-as-hell, but have obviously totally forgot how to enforce just that.
It would require masternodes to internally have at least a 24hour benchmark score (average) for bandwidth, ping latency, available space etc.
so that masternodes could compete on a hardware-based level.
Coding something like that (hopefully without it requiring another 8 GB of RAM memory) could be tricky only for the reason that bandwidth and latency is usually measured between two destinations (IP addresses), but such fair scores would have to be assigned to single masternodes, in order to distinguish the fastest from the lamest Nodes.

it is not that is makes no sense. It is that it is suboptimal. So the network has to decide does it wait for the capabilities to do this in an optimal more elegant way or does it take the risk of trying to manipulate the blockreward to counter the centralization risk from whales. That is supposing that the HPMN plan doesn't allow for censorship. In that case, it makes no sense.

Basically neither decision is great. I don't know if I'd rather wait any longer or have a suboptimal initial rollout.

 

[vazaki3]

What makes no sense is to increase collateral for aiming at relatively few Platform Nodes, when the criteria should rather be based on Hardware resources,
like bandwidth score, ping latency score, available space etc.
They want platform to be fast-as-hell, but have obviously totally forgot how to enforce just that.
It would require masternodes to internally have at least a 24hour benchmark score (average) for bandwidth, ping latency, available space etc.
so that masternodes could compete on a hardware-based level.
Coding something like that (hopefully without it requiring another 8 GB of RAM memory) could be tricky only for the reason that bandwidth and latency is usually measured between two destinations (IP addresses), but such fair scores would have to be assigned to single masternodes, in order to distinguish the fastest from the lamest Nodes.

Nope...this benchmark race does not make sense.It is a waste of cpu and bandwidth resources.
What makes sense is a "proof of Service" from the point of view of the client.
The client asks a paid service, the masternodes compete eachother under the rules of the protocol, and the one capable to offer the service to the client the faster, provides the service and gets the reward.
This can be implemented, but of course someone has to propose it to the budget and define how much the developers should be paid for implementing it. The more the bounty is, the better developers you will attract.

 

[Bridgewater]

Since per-node PoSE has proven to be so difficult to implement on Platform, why not have the Core masternode quorums perform a simple check on Platform's reachability? If Platform is up, they get paid. When it is down, that Dash which would normally get burned/locked to create Credits and pay the HPMN would simply get generated as regular Dash to the Core nodes as usual.

That way, the network wouldn't be continually rewarding these proof of stake nodes purely based on their stake even when Platform goes down.