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

Pre-Proposal: Separate the network layer from the vote layer

Should masternodes have privkey for voting separated from the one used for network identification?

  • Total voters
    13
demo

demo

Well-known member
flare said:
Define "risk".
Risk of loosing his 1000 Dash? Zero, as the key is not shared.
Risk of someone using his vote? Present, as the key is shared. But since the key can be revoked/changed i don't see a risk here.
If you read the manual/code, you will notice that there are TWO private keys:
1) private key for the 1000 Dash, known only to the coin owner (aka masternode owner)
2) private key for masternode, known to coin owner AND server owner
So someone who has the "masternode private key" does not possess the masternode - he has the ability to vote though.
Click to expand...
Having the same private key both for identifying the masternode in the network and for voting, this is a huge design deficiency. What happens between the time some masternode service provider steals the vote and the time the vote is revoked/taken back? What if this inbetween time is the budget payment time? And what about the lurkers, the people who dont care to vote. Dash network has a lot of them, and as long as they are lurkers I think they dont really care if someone uses their vote or not. Dash core team takes extreme precautions in order to protect your coins' privatekey, but they dont care at all for your votes' privatekey, they even recommend you to give it to the masternode service provider. This is tottaly wrong. Because by using the vote, someone may pass an appropriate proposal in the budget, which can send away the core team , or implant a black hat core team, or even change the Dash protocol itself, and that way confiscate coins.

This pre-proposal is about to have 3 private keys for every Masternode.
  1. One private key that holds your money
  2. One private key that manages your masternode and makes it recognizable into the network (which you can give it to the Masternode service providers (MNSP) )
  3. One private key that can be used to vote (which you should have the option either keep it safe or to give it to the MNSP)

Please vote "yes" if you like the idea masternodes to have a special privkey for voting, tottaly separated from the one used for the network identification.
 
Last edited:
Voted yes :)

To clarify: it's not smth we are not willing to make, it's smth we postponed for later releases because:
1) there were no precedences and once one of mn hosters tries to cheat that way - he loses his business, not so much incentive there;
2) vps hosters most likely have no idea that someone is running mn on their servers (I doubt if more than few of them even know what mn is at all), so not so much incentive there as well.

Right now we are focused on making sure we can build new platform which at least can mimic what the old one does to make transition smoother but which at the same time has way more flexibility to construct the most of buildings blocks in future releases. Voting/governance system is the one which was basically rewritten from scratch and we want to make sure it does its work correctly first, then improve it later in future releases.
 
<vote history>
Should masternodes have privkey for voting separated from the one used for network identification?
*yes 3 vote(s) 100.0%
no 0 vote(s) 0.0%
other 0 vote(s) 0.0%
</vote history>
 
UdjinM6 said:
Voted yes :)

To clarify: it's not smth we are not willing to make, it's smth we postponed for later releases because:
1) there were no precedences and once one of mn hosters tries to cheat that way - he loses his business, not so much incentive there;
2) vps hosters most likely have no idea that someone is running mn on their servers (I doubt if more than few of them even know what mn is at all), so not so much incentive there as well.
Click to expand...

One of the reasons it is urgent to create the third private key is this one. (@GrandMasterDash may explain it further)

The above reason is not only a political reason, it is also related to scam prevention. If the updates are decided by a small centralized core team (or even worst by paid employees :p), then one day the below scam may happen..
demo said:
I understand how the Dash protocol should work. And in theory yes, the private key of the coins is not compromised. This is what you claim. But I am cautious with your claims.

Dont take it personally, but I dont believe your claims, I dont even believe your opensource github code. It is not enough for me to read all your source code, then download it and compile it. There is also another step. Only after I download the executables you provide and pass them through an assembler and a packet sniffer searching for my private key, I will be convinced that your protocol works as it should work and as you claim it works. A few people compile their code from scratch , the vast majority uses the executables you provide without bothering with compilations. So if you want to cheat, the easy way is to keep the open source correct, keep the test versions correct, and infect the executables of the stable version with password stealer trojans.
Click to expand...
You may say that the above scenario is improbable, you may also argue about Gitian. But the fact is that the more the capitalization Dash has, the more the incentives for someone to cheat, so the more probable the above scenario becomes. And this is not the only cheat scenario, there are also other scenarios that are even worse.

Futhermore...

It is not only the scam scenario, it is also about politics. Whatever changes the core team does, this reflects to political decisions. For example you said before:
UdjinM6 said:
Voting/governance system is the one which was basically rewritten from scratch and we want to make sure it does its work correctly first, then improve it later in future releases.
Click to expand...
Whatever has to do with voting/governance is primarily a political decision, so it should be approved by the community.

Finnaly..

The core team has the power to define the electorate (reduce or increase the masternodes collateral or give voting rights to the masternodes, or voting rights to those who own many dash (Proof of Stake), or to those who are part of the web of trust of dash, or even to everybody that can prove his individuality) and this is a political decision that can be taken by the core team at any time. Of course this critical decision should not be taken solely by the core team, and this is where it fits the need to control the updates of the core team.

For all the above reasons, it is urgent to secure the vote of the masternodes, and create the third private key.
 
Last edited:
<vote history>
Should masternodes have privkey for voting separated from the one used for network identification?
*yes 4 vote(s) 100.0%
no 0 vote(s) 0.0%
other 0 vote(s) 0.0%
</vote history>
 
I'd further expound by suggesting that MNs be identified in a way that a traffic obfuscation layer could benefit them... A mini-primitives system similar to the evolution facebook-of-crypto layer. Meaning, privacy for MN operators. It will still be known that MNs are operating, and likely, who they are. But, couldn't the payments be based upon a bip32 chain that was in not on the node, much like we don't store the collateral itself on the node? No information regarding the MN payment addresses even existing on the node, and definitely not using the collateral address as the identifier and payment address... Just some way to separate so it's not all hanging out...
 
Even though I do think an attack on voting by a VPS hosting company is unlikely, and you might be exaggerating the urgency of this, I do see this as a weakness that could grow more risky over time (due to price appreciation) and I would rather that this be on the radar to address sooner rather than later.

Here's a question - if there will be a separate key for voting, would we want to tie it to the private key for the collateral such that you cannot disclose your voting key to anyone without also disclosing the key to the collateral address? If we don't create that sort of dependency, then people will be tempted to for example, trust dashcentral with all their voting keys for convenience or privacy, which might partially defeat the purpose. Or on second thought...Maybe that's a really bad idea. Gnight :)
 
Last edited:
<vote history>
Should masternodes have privkey for voting separated from the one used for network identification?
*yes 6 vote(s) 100.0%
no 0 vote(s) 0.0%
other 0 vote(s) 0.0%
</vote history>
 
As long as everyone agrees, maybe we should ask the masternodes about it.
Unfortunately I have not 5 dash and I am not a masternode, so someone else has to add the proposal into the budget system.

By the way, happy new year to everybody, and I hope 2017 to be a better year than 2016.
 
Last edited:
demo said:
As long as everyone agrees, maybe we should ask the masternodes about it.
Unfortunately I have not 5 dash and I am not a masternode, so someone else has to add the proposal into the budget system.

By the way, happy new year to everybody, and I hope 2017 to be a better year than 2016.
Click to expand...

Asking the owners won't get the change through. It has to come via the core team of a developer


Sent from my iPhone using Tapatalk
 
<vote history>
Should masternodes have privkey for voting separated from the one used for network identification?
*yes 9 vote(s) 100.0%
no 0 vote(s) 0.0%
other 0 vote(s) 0.0%
</vote history>
 
acidburn said:
Asking the owners won't get the change through. It has to come via the core team of a developer
Click to expand...

It is a combination of both.
  1. The masternodes should vote it, approve it, then define a bounty for the job and for the testing of the job.
  2. An independant developer (or the core team) should code it.
  3. Finnaly the core team should test it, approve it, then give the bounty to the people who did the job and the testing.

Thats the procedure.

So someone has to ask the masternodes for an initial yes or no. If there is a yes, then several proposals should be added asking about the bounty (incrementally), and the SUM of the YES approved bounty proposals will be the final defined bounty.

So you have to add several proposals as shown below (I selected the bounty amount randomly, so dont yell at me if you think it is too big or too small for the specific case)

1) Do you want the third private key? (yes/no) (in case of a yes result, the 5 dash proposal fee is reimbursed)
2) In case of a yes in the proposal 1, do you agree to pay 50 dash for the job? (in case of a yes result, the 5 dash proposal fee is reimbursed)
3) In case of a yes in the proposal 2, do you agree to pay another 100 dash for the job? (in case of a yes result, the 5 dash proposal fee is reimbursed)
4) In case of a yes in the proposal 3, do you agree to pay another 200 dash for the job? (in case of a yes result, the 5 dash proposal fee is reimbursed)
5) In case of a yes in the proposal 4, do you agree to pay another 130 dash for the job?(in case of a yes result, the 5 dash proposal fee is reimbursed)
6) In case of a yes in the proposal 5, do you agree to pay another 3000 dash for the job? (in case of a yes result, the 5 dash proposal fee is reimbursed)
7) In case of a yes in the proposal 6, do you agree to pay another 200 dash for the job? (in case of a yes result, the 5 dash proposal fee is reimbursed)

Suppose the result of the vote of the masternodes is:
proposal 1) yes
proposal 2) yes
proposal 3) yes
Proposal 4-7) no

Then the defined bounty will be 50 +100 =150 dash.
The first who manages to finish the job (either an independant developer or the core team), he gets the bounty.

This procedure, although cumbersome, it is isomorphic to the alternative budget system and to voting with numbers.

Unfortunately I have not 5 dash and I am not a masternode, so someone else has to add the proposal(s) into the budget system.

<vote history> Should masternodes have privkey for voting separated from the one used for network identification? *yes 10 vote(s) 100.0%, no 0 vote(s) 0.0%, other 0 vote(s) 0.0% </vote history>
 
Last edited:
<vote history>
Should masternodes have privkey for voting separated from the one used for network identification?
*yes 11 vote(s) 100.0%
no 0 vote(s) 0.0%
other 0 vote(s) 0.0%
</vote history>
 
Now that coinfirm is tracking Dash transactions it will only take a little time before they start connecting the dash address used to start a masternode with the IP that is hosting it. If any of the funds in that address are spent through a gateway that monitors identity, the masternode owner is known. Then the IRS or any government can tally all the reward payments and start reporting as income. At that point knowing that a dash address has income, knowing the identity for a transaction, a reasonable suspicion can be used to request a warrant to get the owner of the IP.

So adding a private key for voting.....probably not going to change much. If votes on your node change without you doing it, you can just vote again.

The focus should be on IP blinding now. Or as Camo suggested using a different address in a bip32 chain to register each Masternode. Even better would be to have every masternode payment go to a new bip32 address. Then there isn't a trackable way to find rewards linked to the IP of the masternode. I would think this would be top priority for Evan and the whales. Maybe the the big Evolution Revolution Solution will solve it all.
 
Dash's future (or lack thereof) has been decided. MNOs agree that transparency-first is the way, they want to be law-abiding tax paying people. Being transparent is the way to gain mainstream attraction, apparently haha.

MNOs think the little people (end users) will accept hypocrisy; that transparency-first for end users is acceptable yet MNOs should be privacy-first. This is why people already think of MNOs as elitists.. a "them and us" situation exactly as it is with greedy bankers.

Those that voted yes for transparency-first have yourselves to blame.
 
I think you confuse "transparency" with "only transparent". These polls are so overly simplistic they don't offer anything really.
 
Solarminer said:
The focus should be on IP blinding now. Or as Camo suggested using a different address in a bip32 chain to register each Masternode. Even better would be to have every masternode payment go to a new bip32 address. Then there isn't a trackable way to find rewards linked to the IP of the masternode. I would think this would be top priority for Evan and the whales. Maybe the the big Evolution Revolution Solution will solve it all.
Click to expand...

You can follow a similar to this procedure, in order to define the bounty to be given to the developer who will manage to develop bip32 addresses for the masternodes.

The above mentioned procedure (along with its two variations, this one and this one) is copyrighted by me. You owe me 1 dash if you decide to use it in the budget system, for purposes I do not agree with.
 
Last edited:
You must log in or register to reply here.
Back
Top