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.