Viewing a response to: @spknetwork/pzblscua
*TLDR: The code may be fine but the voting rulebook is demonstrably flawed.* At 12:30, the speaker (disregardfiat?) shows the variable voting is apparently done by [stake-weighted] averaging (*a voter with 1% stake changes 200k to 1M and the result moves up 8k*) and explains "no big fluctuations" as the advantage of this system, apparently compared to (stake-weighted) median. (*a system that I understand to be used on Hive to decide consensus witnesses' vote for HBD Savings APR*). While that may be true, the method only (somewhat) works as long as the voters stay naive (*=ignorant of the rules and their practical consequences*) and enter their preferred value as their vote. Let's say all other voters want instant powerdown so 99% of the stake is voting for 0 on that variable. End result: 10k (blocks). In my book, that's a failure (I want the ruleset to declare the result as 0). Am I allowed to "correct" and vote a negative number? (*minus 1M if I have 1% stake in this particular case*) In practice someone has to set an upper and lower bound to valid votes. Often an arbitrary one. Although at times there are natural boundaries that work out poor - such as the zero lower bound here - those may favour one side (*the long powerdown camp in this example*). Do we vote on the bounds first? Do we settle the vote with averages? Wait, why is that? Well, most voters should vote for the minimum/maximum allowed unless they either (1) possess a large stake or (2) are lucky to have the current result close enough their optimal value. If you are this rare voter, you can calculate a value to get your dream result but you need to follow any changes and recalculate when a vote is changed. Total mess. There is a correct way. Keep using median. The way to deal with rapid changes is to look at the current value in addition to the vote result and mildly push the new value in the direction of the result of the vote. Think of an ELO rating changing after a game - towards the 1-game performance rating but no overreactions.
| author | jelly13 |
|---|---|
| permlink | re-spknetwork-rpsaab |
| category | hive-112019 |
| json_metadata | {"tags":["hive-112019"],"app":"peakd/2023.2.1"} |
| created | 2023-02-08 22:54:12 |
| last_update | 2023-02-08 22:54:12 |
| depth | 1 |
| children | 14 |
| last_payout | 2023-02-15 22:54:12 |
| cashout_time | 1969-12-31 23:59:59 |
| total_payout_value | 0.148 HBD |
| curator_payout_value | 0.149 HBD |
| pending_payout_value | 0.000 HBD |
| promoted | 0.000 HBD |
| body_length | 2,044 |
| author_reputation | -23,210,583,863,489 |
| root_title | "Novel Voting Mechanism - SPK Network Team Meeting" |
| beneficiaries | [] |
| max_accepted_payout | 1,000,000.000 HBD |
| percent_hbd | 10,000 |
| post_id | 120,609,213 |
| net_rshares | 536,604,854,697 |
| author_curate_reward | "" |
| voter | weight | wgt% | rshares | pct | time |
|---|---|---|---|---|---|
| disregardfiat | 0 | 536,604,854,697 | 100% |
You're mostly right here, but at the end of the day I don't think it matters. Staking didn't stop the Sun takeover, and median values are exceptionally unlikely to be ideal values. The moving average here is done to give the most number of people the ability to vote, as a system that calculates median values would need to store and calculate all accounts votes at every vote, which won't scale. What seems like a median on Hive really is the median of 20 accounts who have a few key votes, a barely decentralized plutocracy. The number of people who have left Hive is just shy of all them. Let's not stretch our imagination too much and think 90% of accounts hold 20% of the stake. On Hive there is nothing they could do even together to get a single witness voted from outside the top. At least with this system they could exercise 20% of the vote toward governance. The top 20 in this paradigm are the people who vote for all the apathetic accounts... which would have prevented the Sun takeover. It also disallows the biggest accounts from exercising more than 5%(hopefully closer to 2.5% with 50% apathy) votes as well, which addresses the last point: Any single vote won't effect a variable more than 5% in the arbitrary range. The code does have vote range limits, so a negative vote will just be counted as a minimum. At this stage at least most of the range limits are fairly natural. Interest rates can't be negative, key holders are limited by Hive code, power-down voting range is something like 1 to 100 days... (which translates to 4 to 400 days for a full powerdown). The flip side is the 13 week power down on Hive is almost kinda voted on when there is a hardfork... but as much as people want it to drop in line with the rest of the market, there isn't even a path to do so. To sum Pros: * Scalable * Non-exclusionary * Same or better whale influence limit as Hive. * Same of better arbitrary vote range limits as Hive Cons: * Less plutocratic(?)
| author | disregardfiat |
|---|---|
| permlink | re-jelly13-rpsgwf |
| category | hive-112019 |
| json_metadata | {"tags":["hive-112019"],"app":"peakd/2023.2.1"} |
| created | 2023-02-09 01:17:06 |
| last_update | 2023-02-09 01:17:06 |
| depth | 2 |
| children | 13 |
| last_payout | 2023-02-16 01:17:06 |
| cashout_time | 1969-12-31 23:59:59 |
| total_payout_value | 0.000 HBD |
| curator_payout_value | 0.000 HBD |
| pending_payout_value | 0.000 HBD |
| promoted | 0.000 HBD |
| body_length | 1,978 |
| author_reputation | 345,191,366,639,512 |
| root_title | "Novel Voting Mechanism - SPK Network Team Meeting" |
| beneficiaries | [] |
| max_accepted_payout | 1,000,000.000 HBD |
| percent_hbd | 10,000 |
| post_id | 120,612,416 |
| net_rshares | 664,355,388 |
| author_curate_reward | "" |
| voter | weight | wgt% | rshares | pct | time |
|---|---|---|---|---|---|
| sqhell | 0 | 664,355,388 | 100% |
I appreciate your response but I am going to mindfully ignore the most of it as it deals with voting the consensus witnesses and we might as well join/bump the discussion in [Dan's post](https://peakd.com/hive/@theycallmedan/why-20-witnesses-are-better-than-insert-arbitrary-number) for that. I am sticking to variable voting here. I am going to quote my premises. As someone who cannot read the code, I can be easily misguided there so anyone is welcome to point out any misconceptions I have. > The variables on SPK are voted by validators not all token holders. Even when the number of validators goes through the roof, it is still like hundreds or thousands, not millions (of all token holders). > Hive exhibits an arbitrary decision in (1) limiting the variable voting to 20 consensus witnesses (*maybe 21 including the backup-witness-lottery-winner?*) AND (2) voting by headcount rather than weighting by the HP backing the witness votes. Even if you want to avoid using all witnesses' input, it is probably easy to pick up Top 50 or 100 instead of Top 20 (the further you go, the more important is to weight). > The system needs to store all the votes anyway (you need to look up the previous vote of the account that changed the vote) so you can only avoid recalculating every single vote. If storage were a problem, imagine a system that only allows you to vote for (1) increase the current value OR (2) decrease the current value (plus an option to stop voting and abstain if the value is right). That's equivalent for all rational voters and you can have 3rd party tools that voters enter their dream value in and have it monitor the results to see if a change of vote is needed. Recalculating under such system is easy. It seems to me that at least under the non-weighted system the median can be recalculated in a similar fashion. The old vote was either UNDER the old resulting value or OVER. If the new vote stayed the same, result stands. If it changes camps, you lookup the new result as the neighbouring vote value (probably not cool for weighted votes if that means recaluclation a few million "vests" the changed vote represents). BTW, if you still prefer averaging over medians, you can at least save some space by storing vote values as one of (min, max, something_wierd_pls_look_it_up_over_here) if it is validators voting (as opposed to general public voting naively). > One account holding 20.1% stake should have more say than 90% of accounts holding 20% stake combined. This is actually not subject to the prove-me-wrong request. It is a personal political view. If you change my 99% of zero, 1% of 1M example to 80-20, different people will have substantially diferent legitimate opinions on what the result should be. What a challenge! While I am not trying to change anyone else's view, I think it is useful to know what the spirit of the SPK Network is. If negating stake-weighting is as basic part of the project as negating DVs is for Blurt, I want to know (foot voting is legit and not necessarily an all-or-nothing dilemma on blockchain as compared to IRL). FTR, I have never noticed other core personalities positioning themselves where you seem to. People do not leave Hive as a consequence of losing an election and therefore having no say on DEX fee size. If it was like that, their "20% say on governance" would not help at all. That can prevent extreme values being voted in. Unfortunately, "exercising your 20% vote towards governance" can totally override the other 80% at times (using the bounds you call "fairly natural"). It does not sound a well-thought concept to me. I could write a full post to illustrate but I do not see any audience ITT. Anyway, on Hive, dissent leaves because the winners can execute a financial penalty on them for voting wrong.
| author | jelly13 | ||||||
|---|---|---|---|---|---|---|---|
| permlink | rpt9ws | ||||||
| category | hive-112019 | ||||||
| json_metadata | {"links":["https://peakd.com/hive/@theycallmedan/why-20-witnesses-are-better-than-insert-arbitrary-number"],"app":"hiveblog/0.1"} | ||||||
| created | 2023-02-09 11:43:42 | ||||||
| last_update | 2023-02-09 11:43:42 | ||||||
| depth | 3 | ||||||
| children | 12 | ||||||
| last_payout | 2023-02-16 11:43:42 | ||||||
| cashout_time | 1969-12-31 23:59:59 | ||||||
| total_payout_value | 0.000 HBD | ||||||
| curator_payout_value | 0.000 HBD | ||||||
| pending_payout_value | 0.000 HBD | ||||||
| promoted | 0.000 HBD | ||||||
| body_length | 3,818 | ||||||
| author_reputation | -23,210,583,863,489 | ||||||
| root_title | "Novel Voting Mechanism - SPK Network Team Meeting" | ||||||
| beneficiaries |
| ||||||
| max_accepted_payout | 1,000,000.000 HBD | ||||||
| percent_hbd | 10,000 | ||||||
| post_id | 120,623,320 | ||||||
| net_rshares | 0 |
Again, lots of great points. So I'm going to respond to your premise's here to get a little closer to a consensus. > The variables on SPK are voted by validators not all token holders. This isn't true. We are trying to build a system where everybody CAN exercise their stake. Hive stake is exercised through delegates and this simplifies many of the problems of scaling. 20 accounts or 20 million accounts will only ever have 20 recent witnesses to average votes across. This also means that @ blocktrades with millions of hive power and @ guiltyparties with only couple thousand have an equal vote in the governance. In the proposed system we still have this max influence built in by having the top 20 (who are also responsible for other things) vote with 1/20th of the apathetic stake... and not their own. This bicameral scheme should limit many of the attacks for pushing a variables one way or another. This is a relatively arbitrary number of validators. As the content storage network scales, it is likely that we can have the number of validators scale in a votable range as well. 20 to a max of something limited by a number of highly scored accounts... this is a first step and this future consideration has also been discussed. > The system needs to store all the votes anyway (you need to look up the previous vote of the account that changed the vote) so you can only avoid recalculating every single vote. What is stored in this paradigm above is the time of your last vote. Nothing else. This is 5 bytes per account. And this number goes into the weighting calculation to prevent a vote from driving averages thru multiple immediate votes. So the memory required here is a global current variable, a global total stake weight, the accounts stake, and a last time vote per account. The calculation will always be a few cycles per vote; scaling at O(1), while space scales at N. > One account holding 20.1% stake should have more say than 90% of accounts holding 20% stake combined. I almost completely agree here. However, there is a minimum decentralization that we are trying to achieve. What happens when the account that holds 20.1 buys 30 more. This is actually an attack of any decentralized system. This paradigm allows the 20% to exercise their vote... at full weight; Which is more decentralized than the current paradigm. Unfortunately you can Sybil accounts to overcome any limitation we place here, perfection isn't achievable and any system is nothing more than a hopeful compromise. But if anyone is hard set on 1 token 1 vote, the stock market and traditional finance might be your thing.
| author | disregardfiat |
|---|---|
| permlink | re-jelly13-rpth01 |
| category | hive-112019 |
| json_metadata | {"tags":"hive-112019"} |
| created | 2023-02-09 14:16:51 |
| last_update | 2023-02-09 15:02:57 |
| depth | 4 |
| children | 11 |
| last_payout | 2023-02-16 14:16:51 |
| cashout_time | 1969-12-31 23:59:59 |
| total_payout_value | 0.000 HBD |
| curator_payout_value | 0.000 HBD |
| pending_payout_value | 0.000 HBD |
| promoted | 0.000 HBD |
| body_length | 2,630 |
| author_reputation | 345,191,366,639,512 |
| root_title | "Novel Voting Mechanism - SPK Network Team Meeting" |
| beneficiaries | [] |
| max_accepted_payout | 1,000,000.000 HBD |
| percent_hbd | 10,000 |
| post_id | 120,626,551 |
| net_rshares | 0 |
hiveblocks