You are viewing a single comment's thread from:
RE: Curation reverse auction changing from 15 minutes to 1 minute in hard fork 21
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!