• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

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

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.
 
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.
 
Last edited:
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).
 
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").
 
Last edited:
"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?
 
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
 
Last edited:
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.
 
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.
 
Last edited:
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.
 
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.
 
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.
 
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.
 
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.
 
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.
 
Last edited:
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.
 
@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

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.
 
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.
 
Back
Top