Viewing a response to: @blocktrades/qc1ekn
Though uncommon, this created an opening for malicious users to wait until the lockout period to issue punitive downvotes so that they couldn’t be countered with upvotes. Velocity will address this potential scenario by modifying the lock-out to a cool-down. After Velocity, upvotes and downvotes will both be allowed during the last 12 hours of the payout period, but their strength (for the same amount of voting power) will decrease linearly from 100% to 0% over that 12-hour period. In other words, it will take twice as much voting power to have the same impact on a post’s payout if the vote is done with only six hours left on the payout window instead of twelve. An upvote or downvote cast during the last minute would have virtually no impact on a post’s rewards. This change will help ensure that no matter when a post receives an upvote or downvote, users will be able to counter-vote. This will also help to stabilize the potential payout of posts during the last 12 hours by decreasing the strength of votes as it gets closer to the payout time https://github.com/steemit/steem/issues/1267
| author | bobskibob |
|---|---|
| permlink | re-blocktrades-qc1ga3 |
| category | hive |
| json_metadata | {"tags":["hive"],"app":"peakd/2020.05.5"} |
| created | 2020-06-16 21:42:03 |
| last_update | 2020-06-16 23:09:36 |
| depth | 2 |
| children | 1 |
| last_payout | 2020-06-23 21:42:03 |
| cashout_time | 1969-12-31 23:59:59 |
| total_payout_value | 0.265 HBD |
| curator_payout_value | 0.265 HBD |
| pending_payout_value | 0.000 HBD |
| promoted | 0.000 HBD |
| body_length | 1,106 |
| author_reputation | 9,906,780,416,788 |
| root_title | "Proposal to return the 12 hour voting window gate" |
| beneficiaries | [] |
| max_accepted_payout | 1,000,000.000 HBD |
| percent_hbd | 10,000 |
| post_id | 98,007,571 |
| net_rshares | 1,756,093,263,858 |
| author_curate_reward | "" |
| voter | weight | wgt% | rshares | pct | time |
|---|---|---|---|---|---|
| blocktrades | 0 | 1,734,346,843,040 | 1% | ||
| valued-customer | 0 | 21,746,420,818 | 25% |
Thanks for finding that! As far as I can tell, the reasoning is flawed, which is good, since I was concerned there was a better reason for the change that I wasn't aware of. It seems to ignore the inherent difficulty of countervoting a vote that is cast at the beginning of the last 12 hours, because someone finding that the post has been upvoted a couple of horus after the 12 hour period begins is at a serious disadvantage to the initial voter. The change that was made clearly favors the initial voter (either up or down) over later voters. IMO, the original behavior was better as it favors the distribution of the reward pool over more posts rather than less posts (because it favors downvoting over upvoting) and it served as a better mechanism against abusive voting by large stakeholders to enrich themselves.
| author | blocktrades |
|---|---|
| permlink | qc1p1f |
| category | hive |
| json_metadata | {"app":"hiveblog/0.1"} |
| created | 2020-06-17 00:51:15 |
| last_update | 2020-06-17 00:51:45 |
| depth | 3 |
| children | 0 |
| last_payout | 2020-06-24 00:51:15 |
| 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 | 822 |
| author_reputation | 1,278,355,776,041,298 |
| root_title | "Proposal to return the 12 hour voting window gate" |
| beneficiaries | [] |
| max_accepted_payout | 1,000,000.000 HBD |
| percent_hbd | 10,000 |
| post_id | 98,009,799 |
| net_rshares | 69,760,959,594 |
| author_curate_reward | "" |
| voter | weight | wgt% | rshares | pct | time |
|---|---|---|---|---|---|
| craigcryptoking | 0 | 69,843,864,587 | 100% | ||
| dein-problem | 0 | -82,904,993 | -1% |
hiveblocks