HIP xx: One Miner, One Vote

[cvolkernick]

This proposal suggests the constraining of HIP voting (heliumvote.com) to reflect the active "stake" network participants' voting wallets have in the form of onboarded hotspots.

Ed: rendered view for easy reading: https://github.com/helium/HIP/blob/1b9261602ee8c1f257cdf97bfe75937d9b9231e2/0060-one-miner-one-vote.md

[leogaggl]

Will there be a corresponding HIP channel for discussion on this? This is certainly an important change.

This "One Miner, One Vote" scenario has been mentioned in HIP-45 already. But there was no method to actually do this. And there have been a number of problems with HIP-45 identified already.

This seems like it will solve one of these issues.

[shawaj]

Nice work 👍

Should validators get a vote too and other network participants?

[cvolkernick]

Nice work 👍

Should validators get a vote too and other network participants?

I would personally say that any entity that is governed by or effected by the potential proposed changes resulting from a HIP should have a say in voting. That could hypothetically include miners, validators, and potentially console operators / routers.

I don't believe simply holding a wallet is a productive input into the ecosystem and therefore speculative forces alone should not be considered, as they inherently have no stake beyond value appreciation. If a holder prefers to have input in voting power, they can simply invest ("stake") their holdings in one form or another (miners, validators, routers), contributing to the operation of the network.

[cvolkernick]

Weighting of votes should be proportionate to each entity's contribution to the network utility. This can be measured by the DC equivalent of each to onboard & assert in the case of miners, stake in the case of validators, and DC balance loaded onto organization console for routers.

I believe that would put the weights, respectively, at:

[Full] Miners: 4,000,000 onboard + 1,000,000 assert
[Data Only] Miners: 500,000 onboard + 1,000,000 assert
Validators: A bit tricky and up for debate as 10,000 HNT DC equivalent would be variable, based on oracle
Console / Routers: Current balance of the organization at time of vote start

Console is less ideal however the upside would be that once the DC has been added to the console, it can only be used as data transfer...encouraging use or otherwise complete loss of any of the DC added as a means to vote.

[westonkershaw]

This looks really good!!

[cvolkernick]

This looks really good!!

Thanks @westonkershaw appreciate that. 👍

[edakturk14]

This HIP draft has been numbered and merged for discussion as HIP 60.

Please direct future questions & comments to the new tracking issue: #399

If you are one of the named authors, please include #399 in future pull requests to have them automatically merged.

[jamiew]

thank you @edakturk14 !

[deasydoesit]

@cvolkernick

I would personally say that any entity that is governed by or effected by the potential proposed changes resulting from a HIP should have a say in voting. That could hypothetically include miners, validators, and potentially console operators / routers.

Very much agree on this point