Below is a list of some Hive-related programming issues worked on by BlockTrades team during the past few weeks:
Hived work (blockchain node software)
Code cleanup and investigation of support for Ubuntu 20
Separate from our hardfork 25 changes, we’ve been doing some general code cleanup to make the code more maintainable, and we also started a task to get the code to compile cleanly under Ubuntu 20 without requiring “fiddling” with the build process.
HF25 changes (these are described in detail in our Hive roadmap post)
Expiration of old governance votes
We’ve completed and written tests for all changes related to handling expiration of governance votes (votes for witnesses and Hive Fund proposals).
Curation rewards calculation changes
We completed analysis and implementation of voting window curation changes for HF25. We’re also writing some tests for the curation calculator, as we found the current tests were inadequate (our changes only triggered one fail of existing tests).
During the process, we also discovered an error in the implementation of the square-root function used by the current curation algorithm for unsigned 128 bit integers, but we’re removing use of this square-root function in the new curation calculation, as part of our removal of the convergent-linear curve code (this is the code that weakened small votes).
The new curation reward algorithm works as follows:
- first day (24 hours) linear rewards (equal weight to all voters in that window)
- second window (24 hours to 72 hours/3 days) with reward weight/2
- remaining votes in 3rd window with reward weight/8
Under the new algorithm, anyone voting with the first 24 hours of the post receives the same proportional rewards. In other words, for any given voting strength, the voter will get the same percentage return-on-investment as any other voter during that period.
Voters voting during the second and third window receive a smaller proportional curation reward (and voters who voted during the first 24 hour period receive a little more reward when voters vote during the 2nd or 3rd window). Note that if no one votes during the first window, then 2nd window voters will receive the same amount of curation as if they had voted during the first window.
The basic idea behind the new algorithm is to encourage voters to find good content, but to put them on an equal footing with voting bots. Under the current algorithm that we’re replacing, voting bots have an advantage because there’s a short window in time to cast a vote for optimal curation rewards.
Note that author rewards are not affected by this change: this change only affects how curation rewards are distributed among voters.
Hive to HBD conversion operation
The only code we’re still working on in hived for hardfork 25 is the new operation that allows users to convert liquid Hive to HBD. We’re still researching some issues associated with the existing code that computes the median price for Hive, but we expect to have the conversion code completed and tested this week.
Hardfork code freeze in middle of this month
We expect to do a code freeze on 4/15 (middle of this month) so that witnesses can launch a testnet and begin evaluating and testing the code changes for hardfork 25.
Testnet to operate for at least one month
Barring any problems, we expect the testnet to operate for at least one month, then we’ll begin final prep for HF25.
This will allow time for Hive API libraries and frontend web sites to make changes to provide notifications related to vote expiration and to enable the use of the new Hive→HBD conversion operation and the recurrent payments and rc delegation functionality implemented by @howo. But strictly speaking, most of such frontend functionality can be implemented after the hardfork is executed without causing any problems, so the primary reason for this time interval is to allow for testing and evaluation of the performance of the new algorithms and features.
Modular hivemind (application framework for 2nd layer apps)
Syncing modular hivemind from SQL account history plugin
We were able to successfully sync a hivemind instance from the data injected by the SQL account history plugin (with the syncing taking place as the SQL data was injected by the plugin), but we encountered a problem at the end when some of the indexes were being recreated by hivemind as hivemind exited full sync mode and entered live sync mode. We’re investigating this issue now and we expect a fix in the next couple of days.
Performance measurements for hivemind sync with SQL account history plugin
Despite the issue when exiting full sync mode, we were able to collect some useful performance measurements.
On the regular hivemind sync version, where we first do a hived replay to fill hivemind’s database, and where we then do a hivemind sync where indexes and foreign keys are dropped automatically and rebuilt at the end), the hivemind sync process took 50983s (hivemind sync) + 4047s (index creation) + 1998s (foreign key creation) = 57028s
On the modified version of hivemind sync, where indexes are created before the sync begins, the hivemind sync took 67947s (regular version was 10918s faster).
Despite the increased time for the modified version (10918s/3600s = 3.03 hours), this allows for an overall decrease in the time to fully sync the hivemind node using the SQL account history plugin, because it means that the hivemind sync can be started while the hived node is being replayed to fill hivemind’s database.
In the “regular method”, the total time would be hived sync (~8 hours) + hivemind full sync time (15.84 hours) = 23.84 hours. With the modified method, it looks like we can get this time down to just hivemind modified sync time (18.87 hours).
Note that all these times should ultimate be compared with the existing time to do a hivemind sync without the SQL account history plugin (~90+ hours). So it seems possible we could be looking at a 4x or better speedup in the time to do a full hivemind sync of a new node with the SQL account history plugin, if I haven’t messed up any where in my assumptions (I didn’t want to delay this report any longer, so it’s not been “peer-reviewed”).
Hivemind (social media middle-ware)
Significantly reduced memory usage by hivemind process
We fixed an issue in hivemind where a dictionary was used as a cache for post ids, and this dictionary was progressively consuming more memory as the blockchain grew in size. We spotted this issue during some our performance testing of hivemind syncing using the data provided by the new SQL account history plugin (but the problem exists for all existing hivemind implementations).
Unfortunately, we haven’t had a chance to measure the exact memory savings for the fix yet, as we were focused on other tasks, but I should have those numbers for our next report.
Testing hivemind syncing on a low-end server
We’ve setup a low end computer (8GB of RAM and only a conventional hard disk drive, no SSD drive) to see what the minimum requirements are for a full hivemind node are, and to see if we can lower those requirements. In our tests, the hivemind process did manage to finish the full sync process, but it hit some problems during creation of indexes, so we’ll be digging into this issue further in the upcoming week.
Testing performance of hivemind with Postgres 13
Currently postgres version 10 is the recommended version of the database for use with hivemind, but we did some tests this week to check if hivemind was compatible with the latest version of postgres (version 13) and to measure the relative performance.
It’s all good news: no code changes were required to support postgres 13, and as an extra bonus, we saw a 5% speedup in full sync time in our test. We didn’t make any comprehensive tests yet of API response time related to SQL query speed, but signs are good that we can only expect performance improvements and no regressions.
Miscellaneous hivemind bug fixes and documentation
We fixed a couple of small bugs reported by users and frontend devs, such as a pagination issue with a community-related API call and an issue with community name validation: https://gitlab.syncad.com/hive/hivemind/-/merge_requests/488
https://gitlab.syncad.com/hive/hivemind/-/merge_requests/489
And we have an open merge request for the code to generate openapi documentation for the various hivemind API methods: https://gitlab.syncad.com/hive/hivemind/-/merge_requests/486
Another progress update soon
I’ll probably be putting out another progress update early next week, after we have more performance numbers. I kept delaying this one hoping to include those numbers, but we were caught up in too many tasks and small issues spoiled a bunch of our measurement attempts, and then the Easter holiday hit.
[EDIT] Several people have misinterpreted the function of the weights in the new algorithm, and this has led to a misapprehension about curation rewards for late voters. The weights are used to allocate the rewards between the curators. So if there are few strong voters in the first period and most in a later period, the late voters will receive roughly the same rewards as if they had voted in the early period.
Total post reward amount (author + curation rewards) will be calculated based on total rshares with the new algorithm, not the weights. In pretty much every case, this new algorithm is designed to be MORE favorable to late voters than the current algorithm. So if this leads to people only voting in the first 24 hours, it's only due to misinformation. We'll be presenting more data later to explain how the new algorithm distributes curation rewards.
I'm concerned that removing the curve is going to invite back the high-volume low-value spam comments we've had in the past but mostly gave up since it became impossible to earn a reward with most low-HP votes.
But with the curve removed, you can, in an automated manner, spin out a very large number of comments all over the place at very low cost and if even 1% of users are fooled into thinking that your bot-posted "Great post!" is sincere or just reflexively want to reward "engagement" then you can make a profit.
Downvoting can work to counter this but it relies on already overworked and under- or un-compensated abuse fighters. Most people don't bother. The balance of effort and payoff very much favors the spammer.
I guess we can see how it works out and then reassess, but IMO removing it and replacing it with nothing is a mistake.
I never really understood this argument. HIVESQL is our friend here and a list could easily be maintained like the current blacklist that can slap down comment abuse of this nature in a similarly automated way.
It just means that our abuse fighters need to be tech savvy and use some automation tools of their own.
They can, but it's adding more targets and workload on to an already thankless task.
Also, downvoting isn't really the ideal solution either. It adds even more spam to the chain, driving up RC costs for legitimate use. It also gets controversial in gray areas (and sometimes not even gray areas but just disagreement with the spammer who feels they should be entitled to do whatever they want with their stake) which further adds workload (and sometimes outright harassment) to what abuse fighters have to deal with.
If downvoted consistently like that, the spammer might give up (though not necessarily right away), but also may just switch to another account or accounts and keep going. It becomes a game of whack-a-mole (which it already would be to the extent that if incentives exist, and I'm pretty sure they do, it won't be one or two spammers doing it, many will).
All else being equal, not having the incentive be there in the first place is much, much better than needing to counter, which is what the curve has done. Now all else is not equal, and there are other factors, but there is definitely a cost to consider.
Adding even a relatively small real cost to post would also kill all of this spam immediately since, as with most spam, the incentive depends on posting being nearly free which justifies the return from a relatively low to tiny success rate. But of course I doubt anyone wants to do that since it would get it the way of normal social use.
Yes, though most abusers fairly quickly stop when they get punished, rather than rewarded for their effort so the RC and chain spam argument is not that strong either.
It does not matter what system is envisioned there will be a way to game it. I question whether we are just shifting goalposts again....even going full circle, but I was wrong about the free downvotes so maybe I'm wrong about this too.
Stakeholders need to provide support to the abuse fighters IMHO as they are the beneficiaries of a more valuable chain. It can be tough for abuse fighters to get the balance just right, but it IS worth fighting abuse and the chain IS improving in quality and integrity as a result of their efforts.....so we should be rewarding them.
No, that's repeated a lot in many contexts here but it is a wrong argument and I'm pretty sure @blocktrades would agree on this. You set up the system to reward the behavior you want and/or penalize the behavior you don't. Sometimes those can be cleanly separated and the end result is easy to predict, but even when they can't, you can understand the tradeoffs and still set up the rules accordingly.
Throwing up your hands in some fatalistic "no matter what we do it will be gamed" makes no sense when designing and implementing a system like this. The entire premise of all blockchains is based on setting up incentives for certain behavior and (in most cases) getting exactly that behavior.
The free downvotes are a pretty good example. They have worked out more or less exactly as predicted (which included things like retaliation and apathy). They're not perfect but also not getting gamed to any significant degree. The curve too for that matter. It has greatly reduced spam comment and votes. Getting rid of it will likely bring those back. Maybe worth it, but important to think about the consequences and what will be done about it.
Another counterexample would be adding a small direct cost (not just RC which is negligible at this point) to post. I'm quite certain that can't be gamed and wouldn't be gamed. It would simply kill most if not all spam (good) while also discouraging legitimate use (bad). So that's a tradeoff, but it isn't an issue of gaming at all.
Unrelated question :)
Does the HIVE sent to the DHF is being instant converted to HBD, or it is in a slow mode conversion 0.05% per day?
Instant
.
Not even close to accurate. As an account linkage detective, you are really, really bad.
.
..
ROFL, just saw this while replying to your other messages. You are really, really bad at this linkage stuff.
You obviously have no idea how funny this sounds to anyone who's familiar with both smooth and berniesanders to suggest that they are the same individual. That would be a true case of a Sybil attack :-)
..
Is this that big of an issue? I find spam in the hope of some small reward on every social platform. Whether it is Instagram accounts hoping to follow/like people at random in the hope of bringing some % back to their page where they have some affiliate links or products, or Facebook friend requests with links to scams.
Imo, it would be a mistake to trade of any improvement to user experience in the effort to fight abuse. It would be better to lower the barriers of entry as much as possible, to increase user retention as much as possible, and make our "product" easier to understand and use as possible, even if it meant allowing for some more abuse.
We have far bigger problems to solve than any of the worst abuse that our chain is currently experiencing, or has experienced in the past, namely how we can attract, retain and sustain a growing userbase with properly aligned economics to benefit the token value. We can min-max efforts to limit bread crumb farmers after we've solved that.
I don't think we can compare the comment spam on traditional social media to hive. The reward system changes everything. Although I agree that we have bigger issues I feel that removing the economic barriers to comment farming will exacerbate rent seeking behaviour. The real question is if the tradeoff is worth it.
That's the question I am asking. And the only point I was making. Namely that the tradeoffs in terms of added barriers to entry of new users, and added difficulties of growth for grassroots communities, is not worth the small benefit of less abuse.
The big picture that we need to look at is that hive is a value extracting platform. That is the reality of our situation as exemplified by the flow to exchanges.
At the end of the day hive is mostly purchased to speculate on it (like 99.9% of all cryptos). More than 42% of the available supply (total supply minus the DAO) is on exchanges. For example bitcoin only has ~13%...that is a big difference.
The potential increase in spam may turn out to be a "nothing burger". I am not convinced that changing the convergent linear rewards curve is necessary but I am not opposed to be proven wrong.
I'd be more interested in comparing with numbers for other smaller blockchain projects rather than bitcoin.
The convergent linear reward curve devalues the tokens of anybody without enough to over come the tax.
It also killed comment rewards.
If it isn't removed it needs to be lowered to 100hp, or less.
160k hp is unrealistic.
Anybody that buys in at less than ~80k usd gets a diluted stake?
Who buys that?
It's not about how much HP you have, it's about how much is payed out per post. I have ~20k and if I vote on content that does not get to the point where the payout becomes linear it is worth about half of what it could be but it is worth more than that on higher rewarded posts.
One the one hand the convergent curve discourages spam but as you pointed out the tradeoff is that accounts that do not get regular votes from high powered accounts have a lower incentive to post or comment.
If we had millions of users with a more even distribution of stake it would not be much of an issue. Content creators with a large following similar to what we see on regular social media could make bank without the support of large stakeholders. But we are not there yet.
I do think the spam hurts user experience. It's not so much the rewards themselves I'm concerned about it is the secondary effects. 1. Spam itself is distracting, and insufficiently controlled can be an outright denial of service. 2. Comments are very expensive operation on the blockchain (vastly higher than votes, transfers, etc.). Out of control spam comments will drive up RC costs and become an impediment to the value adding user experience we want.
We mostly lack the abilities that centralized platforms have to shut down (some, probably the vast majority of) spammers programmatically, or at all, by identifying bots and such (since it violates their ToS, and we don't have one), and to some extent to delete it or block it (since most UIs are on board with the "decentralized" ethos and don't want to be censors, and again, because it isn't violating a ToS), so we face a fundamentally bigger problem than they do.
The rewards incentive also changes the picture a lot (for the worse in terms of spam), as @onthewayout stated earlier.
Give authors free downvotes on comments on their posts?
Seems plausible.
Sounds like a decent idea and gives the author a little more sense of control over their own blog.
Is it possible to remove Tax Curve from the posts and leave it as it is on comments? Comments under $20 will be automatically taxed and it will be easy to find comments over $20 (abusers will have to vote during the first window, otherwise they will be taxed by 2nd or 3rd window rules)
I think part of the intent of removing it is to encourage small votes on comments, so this wouldn't be effective for the goal.
In the past, I've seen posts on Steem with 5 cents pending payout value and 10 comments under the post with $15 pending payout each (upvoted on 6th day from publish date). Code should protect us from situation like that.
Alternatively, there are many engagement bots like misterengagement, beer, wine... not a perfect solution to promote engagement but if one of them had a strong token price...
I agree, also within Communities if a community mod notices bot comments they can easily mute that account and preserve UX within that community and I think communities will have the most traffic in the end anyway so I think the damage of spam comments in the grand scheme would be minimal.
If I understood correctly only the curation curve is being modified. So this change would only affect how the curation is distributed but the logic behind how posts are rewarded is intact. Payouts below 20 hive will still be none linear.
It's actually something I'm planning to review.
We are taking out the code that is called out as the linear convergent reward curve. This code has a clear impact on curation rewards for small votes (less curation rewards). I reviewed the associated algorithm changes as far as it impacted curation rewards and was involved in the final algorithm selected.
When I asked about impacts on author rewards, I was told there wasn't any (and there's not as far as authors haven't got extra rewards for early votes since HF14), but I plan to double check that it has no impact on author rewards for small votes. Even if does allow for a little more author reward for small votes, I don't think it's likely to cause any problems, but it's good to know all effects of the change.
Yes that is the impact was suggesting. It does impact author rewards (they're increased for small votes).
I do like the idea of getting rid of the extra complexity and buggy sqrt code for something that may not be all that important.
EDIT: I removed the comment I made about the curation curve, since I'm not sure how that will work with the three-piece curation strategy. So I assume someone is working that out.
Is the code change setting the reward curve back to linear or something else?
If it's the former then again it will become more profitable to mine/extract value via comments. Although this would not be the same situation as before (when comment farming was rampant) due to the "free" downvotes. I predict it will be an issue.
The immediate impact of the change will be to increase the curation ROI for the bigger accounts and viceversa. Essentially front-running wont be a "thing" anymore.
Rewards will be strictly linear with total rshares.
I'm not particularly worried about comment farming. Not only can downvotes be employed to counter that, such accounts can also be added to popular mute lists that will likely be subscribed to by "newbies" who might potentially vote on such spam comments.
Yes, the larger impact will be that it ends the use of bots to front run for curation rewards, putting manual voters back on an even footing with the bots.
.
The effects were figured out to the best understanding of the coder doing the work. But he's working on code he didn't write, and the code is difficult to understand and has no comments. In such cases, you don't always know if you've understood the code properly until you write tests to check its functionality.
This is doubly true because the code can simply have errors that make it operate in a way that wasn't even intended. We already found a case of this, where a manually written sqrt function contained a bug. So testing and third-party review of both the code and the test results is important. You can't just stare at the code and be sure you understand it entirely. That kind of "ivory tower" programming is a recipe for disaster.
As to witness voting, I vote for witnesses on different criteria. In abit's case, despite the fact that he devotes most of his time to BitShares, I vote for him because he has more knowledge of the core code than most of the other witnesses. This can be very valuable at times. But note that my vote alone doesn't keep him in the top 20. He's fallen out at various times, and I think he's only on the edge of being in now.
/
As far as I know, he does handle his own witness. You're the only one to claim otherwise, and after some of your previous claims, you probably can understand why I'm doubtful as to their accuracy.
But even if you are correct, and he does hire someone to do his IT work, I don't consider that a big deal. He's the one that is responsible for its operation, his reputation is on the line, and I believe he will act appropriately.
The convergent linear curve affects total post value so that's both author and curation.
This is separate from the curation change, at least for the most part (there may be some interaction, not sure).
The plan is that post rewards will be a strict function of total rshares voted (including downvotes, ofc) with the new algorithm.
Yes, understood. That's a change from the convergent linear curve.
Because rewarding is always in context, I don't think they should be taxes like the current system.
In general, I see no problem.
spread hive in many hands is better as cycle jerk around. The best thing to do is with comments.
I love to upvote comments. And I do, doesn't matter the extra tax. But I would more like to see no extra barrier for it.
If there will be comments with 50$, they get downvoted and all is fine.
My logic behind this is, if many people have a 1-5 hive it is better as a little group has Millions for the long term.
The 5 hive people are less likely to wait 13 weeks for power down. So it's more like a burn. Sure some do, but most will sit on it forever.
So this should be long-term more beneficial to the network.
Nobody disputes that comment engagement is good. And in fact my concern isn't even about the rewards themselves, but about the negative side effects of having a lot more spam. That's bad for (sincere) engagement in a lot of ways. I'm sure we've all seen comment sections and such on the internet which have been heavily polluted with spam, or tried to use email services which don't filter spam well, etc. None of these are enjoyable or sometimes even functional at all. They also don't have the additional challenges of a blockchain with finite shared resource capacity.
So I'm really not sure what is the best solution. I'm not even proposing that the curve not be removed, I'm simply raising an additional concern to be considered, and I'm reasonably sure that it a valid concern in terms of the bad side effects I mentioned (again, primarily not the rewards themselves, but rather the potentially large damage caused by spammers chasing those rewards, even if the rewards are very small)
Spam will come in anyway. The problem is easy to see on steem. The rewards doesn't matter. There will come link spam if no active curation happens.
That's what on steem happens.
IMO on hive the problem is not that big as on steem. Because the community manages it.
If the first SEO tools include hive, like gsa T2 /T3 and other ping/spam tools, there will also spam happen here.
But this is not linked to rewards. It's all because of search engine optimization. Special SINA ( China search engine and the Russian one).
The algo doesn't penalty spam links in the same way as google does.
to prevent, the easiest way would be:
Reputation under xyz = link is blank, no hyperlink, or link + low reputation = comment doesn't show up.
So downvotes matter in the case of reputation busting from spammer.
Reward farms get easily downvoted IMO. And are not worth the effort. There is more money made by spammers with affiliate spam + hide link direction via buffer side.
Noobs will always try :) No matter what we do :D
I don't think the proposed strategy would be a successful means of getting rewards.
And if someone does employ that strategy, and it is working, I think there are ways to mitigate it without another reward change, such as suggestions by frontends to new users to follow black lists and mute lists that lookout for abusive bot accounts.
Implementation of user chosen mute lists are coming for peakd so hopefully that helps (they do depend on people creating good lists that are also labeled well so that users understand the list and want to use it). If needed we could consider something like a statistically driven automated badge that indicates a user as a heavy repetitive commenter. Even perhaps possible to put that badge on comments. This gives an option to be made aware while not going as far as muting their experience. #ideas
The current reputation serves a similar function, but I like your idea based on spam level (although we'd have to work out useful metrics), as something like that could be a more objective indicator.
It was successful enough in the past that people did it. It costs effectively nothing to post comments, so if you get anything, even a little reward once out of 1000 comments, it's a gain. You need HP, but you can still use your HP for voting or whatever else (as long as it doesn't use too many RCs).
Or for that matter, even if it isn't quite all that successful but shows enough promise (occasional rewards), people may do it, which is still harmful. It's not something where you lose a lot of money by being wrong, you either make some or make none, but either way spam up the chain, cause annoyance on the social layer, and increase everyone else's cost for RCs.
As for the other mitigations, yes that could work, we can try that if needed.
it's true that gains are possible through this change, but let's don't forget the positive developments that could occur from this as well... engagement of users! I think it's worth a try
I don't disagree.
I agree on the other hand.
I agree on the other hand.
If you are looking for a way to earn some extra income every week. Look no more! Here is a great opportunity for everyone to make $82/per hour by working in your free time on your computer from home. I've been doing this for 6 months now and last month I’ve earned my first five-figure paycheck ever! Learn more about it on following LINK.......>>>>>>>>>>>>>> https://www.Nifty2.com
Regarding new curation reward algorithm, I am not sure there is a need for second and third windows. If the first window linear rewards is 24 hours, why not make it for the entire 7 days. Most posts already lose attention after first 24 hours. In my opinion, this new change will discourage all from engaging with posts after 24 hours and create a new norm of posts becoming irrelevant after 24 hours.
I agree, keep it simple like leofinance did, linear one 7 day window, easy to explain and to use.
I don't think it's going to be that big of a disincentive. But I think just having one windows might be a good idea as well
Good point. I wonder what the proposed benefit was of having 3 curation windows.
This. Plus the fact that having one window rather than 3 makes it one less thing to have to explain to new users. Keep it simple.
We need much more simplification. Not more clever tricks.
I think you're suffering from a misapprehension: the updated algorithm actually gives more rewards to late voters than the existing algorithm does.
point is compounding. IF no curve after a timeframe, it's more worth upvoting day 5 posts for faster payout and compound it.
It can be end up in a way to farm the network in a super-fast way.
If we have to solve this, then the curation rewards should be distributed to the authors only after 7 days from the time of their vote. That can prevent this compounding issue.
it's already solved, because of lower rewards at the end.
but it cant be flat over the full time.
Im in full agreement with you @geekgirl
Why to penalize those that curate later than 24h. This will discourage to even visit any post older than 1 day.
So lifespan of all posts on hive would become ... just one day. After that one day - no more upvotes, no more visits, no more comments (who would do any of it on post which is already older than 24h?)
I once watched a video posted eleven years ago. Didn't earn a dime.
I must be crazy.
Hi @blocktrades, I agree with @geekgirl @crypto.piotr and @bala41288.. why not a linear curve over 7 days? linear from 100% to 0% or 100% to 20% ?
The three curation windows and steep reward cliffs do not make any economic sense to me!
If you would vote after 24h with a linear 7 days reward slope you would still get 85 % and after 48 h still 71% of those curation rewards compared to the the first 24h window of the "fcfcf "( flat cliff flat cliff flat) - slope...
IMHO 85% or 100% would not change a lot in regards to incentives but /2 and /8 is prohibitive...
and yes.. its the right calculation as no one will vote after 24h! So no benefit to early voters from late voters..
please consider to change this! I fear it has the potential to turn a good idea into disaster!
As I told @geekgirl, the new algorithm is considerably more favorable for late voters than the current one.
Thank you very much for your reply @blocktrades
Thank you.
The soon to be 5 year manual voter in me is happy with the curation changes. Especially the tax curve being removed as that was one thing I was not in favor during the EIP, or at least felt it was being placed too high. Looking forward to see these changes take effect and I think we're all better equipped to nip bid bot actions in the bud this time around to not do the same mistakes again, especially if you happen to look at the trending of our corrupted twin every now and then.
I think it was set too high originally too and becomes even more pronounced as Hive increases in price. However, I think that it had to be included in the EIP in order to ensure there was a clear difference made - it was a kind of backup plan. I am not sure if it did more harm than good overall, but at least now we have a chance to test without.
I have exactly the same thoughts as @geekgirl. There is a high possibility that after 24 hours most of the posts become useless and there would be no one to check them. This also reduces the opportunity for an individual to get rewarded after 24 hours. If the author doesn't grab any votes in the first 24 hours, his efforts are wasted. It is more unlikely that anyone would be interested to vote on a post by compromising their curation reward when they can vote for another post that is less than 24 hours and get the full curation reward.
I'm also wondering why it cannot be made flat for the entire 7 days and why there should be a penalty on curation rewards a user gets for voting after 24 hours.
You are right with this, post with more than 2 days won't be giving more attention again. This is really bad I must admit. It is as if you are penalising the bloggers.
This won't go well, I don't think this should not be implemented.
The new algorithm is more favorable to late voters than the current algorithm.
In reality, the author will most likely have the next page of their never ending saga prepared and posted before the previous page even gets a chance to melt away into the long lost history of space and time, never to be rewarded again.
I'm seeing far too much focus being placed on individual units rather than the entire picture. The reality of this business model is each effort builds upon the previous efforts. No such thing as waste. We're not creating books and movies here. It's not all or nothing.
The rewards one earns today has very little to do with what they actually did today.
I haven't seen the code but I don't think this is right. If no one votes in the first 24 hours then you still get all of the curation rewards if you're the only one to vote. The only thing that gets cut after 24 hours is the weight, but weights determine the share of curation rewards, not the total.
EDIT: From the additional information added at the bottom of the post I'm now sure this is correct. There is no penalty to voting after 24 hours as long as the post isn't already heavily voted.
I fully agree with @bala41288
2021 is massive year for us!
I'm really looking forward to it! It's nice to be moving out of the cleanup and optimization phase ,and into the "new ideas" phase in a big way. I'm particularly eager to start work on the 2nd layer information rating app.
Any plans for the powerdown period?
One of the proposed options was to introduce an option for instant powerdown with a penalty (10%, 20%?), and the penalty rewards going to the ones that are powered up .... I see this model in some other projects introduced as well.
I'm personally against anything instant cause hackers/phishers won't care about the penalty. Anything under 4 weeks (the account recovery time) would mean a great loss to many who may get their keys stolen which we've seen happen quite easily on pretty dumb tactics lately.
Personally I think a week or two is enough to recover your account in most cases due to phishing and such. Not 100%, but enough to consider that it could be good enough.
What about if instant powerdown was an opt-in process and the powerdown went to a different account?
For example, when opting in for @smooth - it requires setting up a secondary account called @smooth-####### with another set of keys to save.
I know this is possible already in various ways, but if it was "the" process, perhaps it would protect many under normal conditions too.
Who knows, the entire idea of instant, or even just faster, power down is just a concept that overall has been raised and consistently had a lot of pushback and failed to achieve any sort of consensus. The objections are multifaceted, from security to also believing that forced longer-term staking is just inherently better in terms of having stakeholders who are longer-term focused.
I can't stop anyone from continuing to advocate for it but personally I don't think its a good use of my time and effort at this point.
lol, that is fair - I don't need it personally - but it might be interesting to have a burn/stabilizer fee on it for those that think they can beat the market.
The response that is often given is that if you think you can beat the market, just don't power up. Which, if looking at the portion of supply on exchanges, is already widely used in practice.
Yes, I have heard this beffore as a con ... I agree to a certain degree ... would like to see some proposals how to get around this, maybe aproval first etc ...
Also people are holding millions in metamask, doesnt seems they worry much ... securing ypur funds should include some personal responsability as well .... we just need to provide the options
agree.
Powerdown is something it should be an option but not a must-have.
It must be enough exchanges don't use user funds.
If you can generate a multi-sig 1-week power down, it should work the same way as today.
So you can power down 1 week with multi-sig or 13 weeks.
Or a collateral version, you can lock up your Hivepower to generate a stable coin.
It's like instant too, can be managed with a new "money key". so it's also secure.
Will this require a hard fork?
It will be included in the upcoming fork.
Its part of the upcoming HF.
Congratulations @blocktrades! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :
Your next target is to reach 87000 upvotes.
You can view your badges on your board and compare yourself to others in the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPCheck out the last post from @hivebuzz:
Me parece excelente. Gracias por su valiosa información. Siempre tiene algo nuevo para todos. Felicidades
The curation changes are great. And as always keep up the good work!
This HF25 is really very promising with all the improvements it brings, the developers who contributed can be proud of their work 👍 Can't wait to see the effects of the new curation reward algorithm on voting distribution and timing.
Sounds like some great changes and updates. I think the 24 hours time frame for people to vote leaves plenty of time to be active each day and do your full curation without having to do a rush job in fear of missing out on a full curation reward. This gives EVERYONE a clean playing field when it comes to curating content but also keeps up demand that you should be doing it on the daily and engaging with that content.
The difference in curation is decisive at the time of publication, this may be good for now, as some people do or Upvote at a near-curation time (6-7 days) for personal gain. 👍👍
It is good to see dates now being set. I hope unlike HF24 that people take the time to really test out HF25. One month should be plenty o time, and I hope they do not wait for the last two days and then say, "Uh...oh...we found this issue.....here's our quick fix solution" lets try to avoid quick fix solutions, they never work, and they never get tested except in the field.
I think the process that has been undertaken to prepare HF25 has been excellent, and perhaps it will let outsiders see that when it comes to HIVE block Chain, you guys want to do it right and make sure the improvements are needed and serve a function.
Will there be some sort of notification when your votes are about to expire? (or shortly thereafter?)
Yes, this type of notification will be done by the frontend web sites. We've been discussing methods for this in the past few days with the frontend devs.
That will get rid of bid bots more hopefully. I hope with all the ( appreciated ) work you did have a great Easter , we will inform many of the new HF date.
Please add RC delegations into this HF.
@howo has recently indicated that he thinks he will able to include RC delegations into the upcoming HF>
That's super nice. RC delegations will make hive much more efficient. I write today something about it, how I think it will work out.
Leverage factor on everything now we have. Super cool.
That is being worked on by someone else not blocktrades
I know, but his team ultimately deciding if code is ready, right
These are great updates !
I just personnaly find the 1 voting window pretty short, I hope this will not lead into a voting system where no post will be upvoted after 24 hours
Happy day @BlockTrades, I congratulate you on your hard work, I would like to know why I have not received rewards from great curators for so long, every day I try to create new content, but I have not had any luck. A big hug from Venezuela.
I don't see the advantage anywhere, because it is condemning the posts to last only 1 day, because after that they are the fruit of the penalty. Instead of decreasing it would be alarming the amount of bots that would be trying to share the curation and in the end the post would be just as relegated, not to mention what I said at the beginning, that the author would be subject to the fact that his publication must be seen in 24 hours, but would get paid 6 days later, serving as a filler, like a waste in a landfill.
Personally, and this is my humble opinion, the posts should not be penalized and leave the proposed distribution for the 7 days.
See my additional notes at the bottom of my post. Several other commenters have misunderstood the function of the weighting, which only controls how curation rewards are distributed. The new algorithm is actually better for later voters than the current one. Depending on circumstances, you can actually receive little to no curation penalty for voting on a post that is several days old.
Interesting change. Im lukewarm on it.
I think spam can be maintained at a reasonable rate.. The community managed to get rid of bots, most of them whale owned, so I'm almost certain it will be able to deal with those spamming, hoping to get 10 cents every 1000 comments.
Good to hear, I've been waiting for some of these changes for several years.
Can this curation rewards post have the 50/50 split applied and the same ratios be accurate?
To address @smooth's concern, I would suggest that the 4 post soft limit on rewards return in some way.
Once x number of posts have been made then rewards are reduced by an increasing penalty.
This can limit bots from massively flooding the chain, yes?
At least putting a top on rewards from the attack?
If we can find from the data, that this chain consists of, what a bot looks like, then perhaps an algorithm can be devised where only edge cases will be impacted, and they can be addressed by whitelisting, or what not.
Any authors can learn that this is the new reward normal and adjust.
Just as we did when the 4 post soft cap was in place.
Most 'normal' users don't create spam bot levels of content.
Math can solve this, imo.
Perhaps we could set the target of the curve to something more reasonable, like 1mv?
Reducing the value of a much smaller segment of the community, while incentivizing powering up all rewards until the account has 1mv.
I support going back to the linear reward curve for both author and curation rewards and removing the time window for curation rewards completely like @leofinance did.
Instead of having 3 time windows like proposed I would prefer having one big, flat 7 day window.
Keep it simple. Looking forward to HF25 :)
Excellent!
How come the image uploader does not work for me on any community whether I am banned / muted or not? I think that is an issue.
There's no way I know of that an issue with the image uploader can be related to being on any list. Maybe there is some specific issue with the image you're uploading? I know some particular older samsung phones produce an a buggy image that is incompatible with the image uploader, for example. Can you give some more details about how often and under what circumstances this occurs?
Semangat
Please help me, I try to enable my Portfolio View but whenever I click on that icon it shows me an error message of "Error updating profile settings, please try again a few moments". Please help me in solving this issue. 🙏
Dear @blocktrades
I spoke to few friends on hive and we discussed this topic. So far everyone I talked to seem to have strong opinion, that upvoting anything that is older than 1 day will be out-of-question.
Personally, Im afraid that this will only push people even more towards usage of bots.
Looking for quality content, while knowing that it HAS TO BE maximum 24hours old (otherwise we would be penalized with reduced curation rewards) would be even harder than it has been now (window to upvote posts were much higher).
That is just my own small feedback. Not complaining. Just sharing my concerns.
Aren't you concerned, that content discovery will be limited from 7 days to 24h? Noone will care and pay attention to posts older than that.
Yours,
Piotr
I'll finally say it because no one has been considerate enough to tell you yet.
Starting all your messages with "Dear" is really quite weird to us. Maybe i can't speak for all english speaking cultures. I fully fully understand you believe it to be some sort of respect thing but just wanted to inform you that it is quite strange to many of us as it seems like something reserved for letters between people that are more intimate and have a more storied relationship, or for really really formal correspondences. There are of course other use cases but the point is that at the very minimum it seems very out of place in a comment section about code stuff. Also out of place on wallet memos if you were wondering.
I recognize it's almost become part of your brand and I would say you do you... but maybe also consider your audience. Do they do it themselves? If so perfect match I suppose. Are they programmers, americans, come from languages where it doesn't translate well or even just more casual type people in general?
I assume you know what "dear" means it is quite intimate and thus that's why it is used traditionally in more personal letters and then strangley got used for very formal letters... but is not used for the in between. Maybe you do not intend to assume this level of intimacy but that's what the word means and so if people see it they also think "ok this guy thinks he's really close to me or it's obvious he wants something" which is kind of the case because usually you do in fact use "dear" and then to proceed to ask for something. (No issues with you wanting to ask for something)
Also "yours," ... its not a letter it's a comment section. Read the room.
I believe strongly that you care very much about being good at communication and I think that English may not be your first language so I'm just chiming in to help. I hope it comes off as helpful.
Dear @jarvie,
You don't think he's just trying to be a condescending prick?
Love,
Joshman
Dear Joshman
Very professional
Yours affectionately, Belemo.
LOL
🌈
I choose to believe he actually thinks it's a good way to communicate and doesn't know how poorly it translates in English. How downright irritating it actually is to many English speakers who don't have a personal relationship with him. Maybe he is also awkward communicator in his own language but I do not know do i am just going with the opinion that no one has told him yet and hopefully he reads this.
I think a bit of it is an attempt at misdirection. He's a schemer and spammer from way back, and part of his defense is this sickeningly sweet aura he attempts to create for himself. He has a large number of unsophisticated followers who rally to his defense due to this style, which is why your advice will probably fall on deaf ears.
Just missing “sir” and “kindly” for the complete package.
Dear @enforcer48 sir,
Kindly piss off you wanker.
Kisses,
Joshman
That would never be the case @joshman
I've literally no intention in wasting my limited resources (time and my own life) on trying "to be a condescending prick".
Regards, Piotr
Hi @jarvie
I'm not a native english speaker, however based on my knowledge it is very appropratie way to open a comment.
Half of the time it is indeed towards someone I already know, value and respect, and sometimes it is as you've mentioned "for really really formal correspondences.".
My comment above I consider to be such exactly that: a formal feedback.
Perhaps you may have noticed, but I didn't send any mass memos on HIVE pretty much since it's existence. It has been a year or more if I'm not wrong.
Not necessarily. I spoke about it with 2 separate professional english teachers and both confirmed, that it is absolutely alright to start emails or messages this way. Apparently it's even more appropriate than to start with "Hi".
So allow me please to put my trust in their teachings.
I appreciate your time which obviously it took to write this comment. I really do. And I will do my best to remember not to start comment by saying "dear" to you if it does bother you.
Cheers :) Piotr
I started the response multiple times referencing several points and then I just realized you don't even care. You do you. Appeal to whatever source that will give you the answer you want to hear.
Interesting why would you say that? If I wouldn't even care - then why would I bother to reply in the first place?
Anyway
because... disappointment
Check the bottom of my post for full details (I added clarifications to correct some misunderstandings about how the weights function), but the new algorithm is much more beneficial for late voters than the current one.
See my addition comments at the bottom of my post to see why this isn't the case. You will actually likely get more curation rewards under the new algorithm, based on the description of your voting pattern.