Curation reverse auction changing from 15 minutes to 1 minute in hard fork 21
View this post on Hive: Curation reverse auction changing from 15 minutes to 1 minute in hard fork 21
View this post on Hive: Curation reverse auction changing from 15 minutes to 1 minute in hard fork 21
This change favors bot voting, who the fuck proposed this? (excuse my french).
Not only bot voting but bots in general (often owned by whales).
The bot votes happen anyway. The idea is to get them over with in one minute and then people can vote without needing a stopwatch.
With the increase in curation rewards from 25% to 50% we expect that curation, including bot/autovotes, will get more competitive with more votes during the timer on known authors and more of those happening earlier in the timer. Which means that more of those curation rewards will return to the pool and result in higher payouts elsewhere. It also means that humans will be increasingly shut out by waiting or by trying to jump ahead.
Bots can play their games easily enough within one minute on the sure thing votes and everyone else benefits from both a more intuitive voting experience and more rewards returned to the pool and up for grabs elsewhere.
It does remove the cognitive load of trying to time the votes. Popular authors are setup for autovotes from big accounts anyway but with this change it will be difficult to front-run them. With the change to the rewards curve smaller accounts will have two options: either set earlier autovotes and forfeit on curation or vote on other not so popular posts and also lose some rewards with the non-linear portion of the new curve. Intuitively it seems to me that bot voting will have an advantage. I will give you guys the benefit of the doubt until we have enough data to analyze the change in behaviour that this adjustment will produce. Thanks for the explanation.
Wow, still can't believe that I missed this news. I've been out from the crypto scene for some time to start my platform 247couponcodes - It feels good to be back.
If people access their feeds often enough AND utilize notifications for their favorite authors it'll be a good change, otherwise there'll be other kinds of frustrations.
Thanks for getting the word out! Definitely this helps many cases where I hesitate to vote early. I do suspect that many current voting services do not have the granularity to vote exactly where they want though hmm..
It will be harder to beat the auto votes with a one minute window. Steemauto, for example, is only granular to the minute. I wonder if they'll change it to seconds.
Well, it is kinda stupid and pointless. It's easy enough to get a bot to wait. It's actually more frustrating when you read a new post or comment and have to come back in 15 minutes to upvote it. Sometimes you'll even forget.
It's a bit disconcerting how many major changes are happening at once though. Some of these should have been put into their own hard forks and given time to determine their effect.
So, HF21 is out for testing and there are still features to be implemented?
Shouldn't there be a code freeze?
It was frozen, but this was a hot topic before that was missed on the final chopping block. Because it is a simple three line change, it was added. Each additional hard fork introduces risk so on one hand, you want to do as much as you can each hard fork, on the other hand, you don't want to change too much so it becomes a balancing act.
I don't remember this being discussed here anywhere.
It my be only a 3 line change, but this can have huge impact.
Anyway, no one did any end user testing yet, AFAIK, so it shouldn't matter
Continuous improvement, I guess... development should not stop because a specific version of the code is being tested. But I am not sure how much time it’s agreed as safe here.
Posted using Partiko iOS
Even with ci, there are certain delivery dates, with approved targets, features, etc.
But this seems just random.
Then I would prefer to delay the HF then having a bad experience, like on the last one. If that needs to get into the HF.
This isn't really a code change it is just changing a constant. Due to some other bug fixes that were needed there will be a respin on the release candidate offering an opportunity to get this in. It had been previously discussed but the ball got dropped along the way.
AZ-5 is also just a button...
:)))
Let's hope for nothing like that Ж)
So if i watch a video, or read a five minute read, or listen to a song.... I have to vote, first?
Could somebody please think about this.
If you want to be competitive for curation rewards, yes that will be the case.
Only if you are confident the video or five minute read will actually by voteworthy sight unseen. If not then you may vote first only to find that those free downvotes end up turning your blind vote into a waste, or at least low return.
If you are confident it is votewothy without examining it first, others will be too and much of the curation rewards will be returned to the pool and used elsewhere, which is good; this is not valuable curation.
Interesting. This pushes the competition for curation rewards into a period between 21 seconds (block 7 after the post - equivalent of 5 mins currently) and 48 seconds (block 16 after the post - equivalent of 12 mins currently). A total of ten blocks.
That could mean a lot of votes in each block for popular authors where curation rewards are high.
Out of interest, how many votes can fit into one Steem block?
Also, what happens if someone sends through a huge post, very close to the block limit, at 30 seconds (or a number of smaller posts of an equivalent size)? Would the votes push into the next block?
Asking for a friend.
Votes are 100 bytes more or less (depends on the size of the permlink), so theoreticaly hundreds can fit in block (64 kbytes). I doubt this will be a major constraint, as very little content even gets that many votes total.
Also, is there a mathematical reason it doesn't make sense to vote earlier than 5 minutes, or is that simply a property of system conditions? Whether the linear penalty curve is really ideal is something I've been meaning to look at and may become more important if the window is shorter.
I think it's because you lose rewards linearly as you get earlier in the reverse auction period, but the post payout has to grow at n-squared to regain them. So in a simplified example under which you are voting first:
The post payout becomes the limiting factor.
Is there a potential attack vector through which a group of accounts spams the blockchain with very large posts through blocks 7-16 (counting from the popular post publication) blocking anyone else from voting? They could tuck a vote on the end of their spam to grab the curation rewards at block 16?
Currently it would be hard work, since there's 150 blocks in that key voting period, but if you take that down to 10 blocks it seems more feasible. Even if you only hit 5 of them (equivalent to 3.5 mins delay in voting currently) there would be a fair increase in curation rewards.
Thank you for pointing out the potential attack vector. After bringing it to the attention of the devs, they have decided to back off a bit and recommend 5 minutes for now instead of 1 minute. In the future there may be some better protections against flooding attacks making it safer to reduce the timer further.
Cool! Glad to have been of use!
We typically have around 20 votes in a block, but we could do a lot more than that.
If two votes are in the same block, they act as if they voted at the same time regardless of where they were in the three seconds.
Anything that doesn't fit in a block will go in the next one but as far as I have seen we don't typically fill the blocks.
So in other words, after Hf 21 ... start curating the top people at 1 minute 🤦🏼♂️🤷🏼♂️🤣
Posted using Partiko iOS
I suspect that will happen a lot, but it will be a race to zero as many people will be doing it and trying to one-up each other by going earlier and earlier. This will result in more curation rewards being returned to the reward pool or people moving off to find authors who are not as competitive they can push above the curve and get good rewards. Some will vote as they always have, just earlier.
when does this go into effect?
When and if Hard Fork 21 gets approved. There is no execution date at this point.
thanks !
Well, I guess it was a bit annoying having to wait 15 minutes to upvote a comment and regarding people just voting posts for maximum profits, its really just the same when it can be done automatically with a bot at the right time so in my opinion there's no difference between a vote at the 1st minute and on the 15th minute.
I think the wait time is counter productive. Those who know it and how it works wait to vote etc. Those who don't know it most likely are giving up rewards and have no idea they are doing so. Keeping the reward the same throughout the period of time makes sense to me.
There should be less confusion and a simple system that is friendly to new community member of steemit. Again 50/50 rewards makes sense. No waiting to try and get an advantage u are simply rewarded equally.
Posted using Partiko Android
I think no one will upvote comments much after hf21 with the new curve.
Posted using Partiko iOS
Not necessarily. Look at the nether region of the new pseudo-linear curve and a small upvote could be worth just half what it would be under linear, yet the upvoter gets 50% curation rewards on it - comes to the same 25% return... just the author gets a lot less, like one third (ouch!)
I don't think the bots are so accurate, are they? I don't really know as I have never used them.
They are precision accurate to 3 seconds!