Welcome to the Dash Forum!

Please sign up to discuss the most innovative cryptocurrency!

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

Discussion in 'Pre + Budget Proposal Discussions' started by demo, Dec 30, 2016.

?

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

  1. yes

    92.3%
  2. no

    0 vote(s)
    0.0%
  3. other

    7.7%
  1. demo

    demo Well-known Member

    Joined:
    Apr 23, 2016
    Messages:
    3,116
    Likes Received:
    262
    Trophy Points:
    153
    Dash Address:
    XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
    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.
     
    #1 demo, Dec 30, 2016
    Last edited: Dec 30, 2016
    • Like Like x 2
    • Useful Useful x 1
  2. UdjinM6

    UdjinM6 Official Dash Dev
    Dash Core Team Moderator

    Joined:
    May 20, 2014
    Messages:
    3,631
    Likes Received:
    3,532
    Trophy Points:
    1,183
    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.
     
    • Like Like x 3
    • Informative Informative x 3
  3. flare

    flare Administrator
    Dash Core Team Moderator

    Joined:
    May 18, 2014
    Messages:
    2,304
    Likes Received:
    2,435
    Trophy Points:
    1,183
    Voted yes as well - actually this is the first constructive thread/idea by @demo (as far as i can tell)
     
    • Agree Agree x 8
    • Disagree Disagree x 1
    • Funny Funny x 1
  4. demo

    demo Well-known Member

    Joined:
    Apr 23, 2016
    Messages:
    3,116
    Likes Received:
    262
    Trophy Points:
    153
    Dash Address:
    XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
    <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>
     
  5. demo

    demo Well-known Member

    Joined:
    Apr 23, 2016
    Messages:
    3,116
    Likes Received:
    262
    Trophy Points:
    153
    Dash Address:
    XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
    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..
    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:
    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.
     
    #5 demo, Dec 30, 2016
    Last edited: Dec 30, 2016
  6. demo

    demo Well-known Member

    Joined:
    Apr 23, 2016
    Messages:
    3,116
    Likes Received:
    262
    Trophy Points:
    153
    Dash Address:
    XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
    <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>
     
  7. camosoul

    camosoul Grizzled Member

    Joined:
    Sep 19, 2014
    Messages:
    2,160
    Likes Received:
    1,110
    Trophy Points:
    1,183
    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...
     
    • Like Like x 2
    • Informative Informative x 1
  8. TroyDASH

    TroyDASH Well-known Member
    Moderator

    Joined:
    Jul 31, 2015
    Messages:
    1,253
    Likes Received:
    793
    Trophy Points:
    183
    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 :)
     
    #8 TroyDASH, Dec 31, 2016
    Last edited: Dec 31, 2016
    • Informative Informative x 1
    • Useful Useful x 1
  9. demo

    demo Well-known Member

    Joined:
    Apr 23, 2016
    Messages:
    3,116
    Likes Received:
    262
    Trophy Points:
    153
    Dash Address:
    XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
    <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>
     
  10. acidburn

    acidburn Active Member

    Joined:
    May 26, 2014
    Messages:
    467
    Likes Received:
    175
    Trophy Points:
    113
    I'm up for this too


    Sent from my iPhone using Tapatalk
     
  11. demo

    demo Well-known Member

    Joined:
    Apr 23, 2016
    Messages:
    3,116
    Likes Received:
    262
    Trophy Points:
    153
    Dash Address:
    XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
    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.
     
    #11 demo, Dec 31, 2016
    Last edited: Dec 31, 2016
  12. studioz

    studioz Well-known Member

    Joined:
    Sep 10, 2014
    Messages:
    539
    Likes Received:
    464
    Trophy Points:
    163
    Demo you're ending the year with a great idea , Happy New Year with less trolling on Dash forum for 2017 .
     
    • Agree Agree x 1
    • Funny Funny x 1
    • Optimistic Optimistic x 1
  13. acidburn

    acidburn Active Member

    Joined:
    May 26, 2014
    Messages:
    467
    Likes Received:
    175
    Trophy Points:
    113
    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
     
  14. demo

    demo Well-known Member

    Joined:
    Apr 23, 2016
    Messages:
    3,116
    Likes Received:
    262
    Trophy Points:
    153
    Dash Address:
    XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
    <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>
     
  15. demo

    demo Well-known Member

    Joined:
    Apr 23, 2016
    Messages:
    3,116
    Likes Received:
    262
    Trophy Points:
    153
    Dash Address:
    XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
    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>
     
    #15 demo, Jan 1, 2017
    Last edited: Jan 2, 2017
  16. demo

    demo Well-known Member

    Joined:
    Apr 23, 2016
    Messages:
    3,116
    Likes Received:
    262
    Trophy Points:
    153
    Dash Address:
    XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
    <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>
     
  17. Solarminer

    Solarminer Well-known Member

    Joined:
    Apr 4, 2015
    Messages:
    762
    Likes Received:
    921
    Trophy Points:
    163
    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.
     
  18. GrandMasterDash

    GrandMasterDash Well-known Member
    Masternode Owner/Operator

    Joined:
    Jul 12, 2015
    Messages:
    2,629
    Likes Received:
    948
    Trophy Points:
    183
    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.
     
    • Agree Agree x 1
  19. t0dd

    t0dd Active Member

    Joined:
    Mar 21, 2016
    Messages:
    144
    Likes Received:
    132
    Trophy Points:
    93
    Dash Address:
    XyxQq4qgp9B53QWQgSqSxJb4xddhzk5Zhh
    I think you confuse "transparency" with "only transparent". These polls are so overly simplistic they don't offer anything really.
     
    • Agree Agree x 1
  20. demo

    demo Well-known Member

    Joined:
    Apr 23, 2016
    Messages:
    3,116
    Likes Received:
    262
    Trophy Points:
    153
    Dash Address:
    XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
    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.
     
    #20 demo, Jan 3, 2017
    Last edited: Jan 8, 2017
    • Trolling Trolling x 1
  21. demo

    demo Well-known Member

    Joined:
    Apr 23, 2016
    Messages:
    3,116
    Likes Received:
    262
    Trophy Points:
    153
    Dash Address:
    XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX
    Lets put a governance question asking whether the masternodes want to have a privkey for voting separated from the one used for network identification.

    Is anyone interested in creating a multisig address, and do a fundrasing in order to reach the amount of 5 dash proposal fee and be able to add this governance question?

    Lets start a list of the people who are interested in this fundrasing. Whenever the list reaches the 5 dash goal, we are going to vote for the person who we trust he creates the multisig address, and vote the minimum (m) number of signatures required to spend the money. Everyone may gives whatever he/she wants, even a single duff is welcome, and he/she may defines whatever terms or conditions he/she desires in order to give the amount. The only expected is to keep his/her promise.

    The list follows (it will be updated accordingly):

    1. Myself @demo ( XnpT2YQaYpyh7F9twM6EtDMn1TCDCEEgNX ) : I initially offer 7% of my entire fortune in Dash for this puprose ( 7% of my Dash fortune is currently set to 0.105 dash, since the above Dash address is the only non-empty I possess). Until the creation of the multisig address I keep the right to reduce or increase what I offer. But after the multisig address has been created, I hereby declare, on oath, that I will give the declared amount.
     
    #21 demo, May 25, 2017
    Last edited: Nov 19, 2017
  22. solarguy

    solarguy Active Member

    Joined:
    Mar 15, 2017
    Messages:
    868
    Likes Received:
    412
    Trophy Points:
    133
    Udjin's response suggests to me that the Core Dev team is aware of the issue and is working on it. Yes?

    And certainly, identifying and addressing weaknesses is a good thing. But is there any evidence that this has ever happened?
     

Share This Page