The hardfork that created the Hive blockchain was coded by contributors from the community.
In the past few months, we've seen Hive's ecosystem grow to include a wealth of community members contributing to the open source core code and beyond. It's been an exciting time to watch people stepping up to help bring Hive to life! There are an increasing number of devs working on making a better blockchain every day. If you'd like to learn more about the source code, how to contribute, or even just how to watch and comment on what's happening, please check out the core development post for a walkthrough. We're fast approaching being ready for the first Hive hardfork, and there are more than twenty developers who have contributed to the blockchain and library changes for this version.
With that being said, work on the core code for this hardfork addresses a lot of areas that aren't super flashy or necessarily very easy to follow along with, even if you know where in the repos to look. To help get everyone up to speed on the impending hardfork, here's some information about the release candidate, testnet creation, what potential timing will look like, and an overview of what's included in HF24.
What is a hardfork release candidate? When can we expect HF24?
When software is being developed, eventually a set of upgrades are chosen to be the "final version" of the next release. There are still some steps to take to make sure that this final version is working correctly and covers off everything it needs to! As a release candidate, the code is stable, ready to go, and no further work will be done unless a problem is found. The code is frozen (which means new features stop being added to the version) and enters a period where it is thoroughly tested. This is why it's called a candidate: as long as no significant bugs are found during wider testing, it's ready to be the version run by everyone.
The @HiveIO account will make a post with details on the release candidate and testnet for HF24 on Monday, June 8th.
While a number of people have contributed to the code, it's time to get even more people trying to break it! 💪 Everyone's invited (and encouraged!) to jump in for testing, and the next post will talk a little more about how you can get involved at any level- whether you're an end user, project manager, node operator, or developer.
As testing progresses, we'll learn a bit more about an accurate time frame for the actual hardfork date. If things look smooth and no big bugs are found right away, then exchanges will be notified and the chosen date could be as early as two to three weeks later. Should a problem come up immediately or really heavy final vetting needs to be done, the chosen date could be closer to four to five weeks away. The more people testing and giving feedback, the faster things will move! Part of choosing the date for a hardfork is giving a sufficient amount of notice to exchange teams so they can prepare their nodes to support the upgrade. It's important to give them an advance window and be ready to assist if they need it to help make sure that wallet maintenance downtime is minimal.
What sort of changes are included in HF24? What will this hardfork do?
The most important parts of the first Hive hardfork involve making sure that it's easier and faster for everyone everywhere to use and support the Hive network. Many of the devs working on the hardfork have been personally documenting their progress. Here is a quick layman's overview of the biggest things that this hardfork will change:
- Changing the blockchain ID.
- To help existing frontends and dApps migrate quickly and easily, the chain ID was not changed at the time of Hive's creation. However, this is an important part of improving secure access to the blockchain going forward, and needs to be done now in preparation for even more projects joining the ecosystem.
- To help existing frontends and dApps migrate quickly and easily, the chain ID was not changed at the time of Hive's creation. However, this is an important part of improving secure access to the blockchain going forward, and needs to be done now in preparation for even more projects joining the ecosystem.
- 30 day cooldown time on newly powered up HP for governance voting.
- The Hive governance system is made up of both witness voting and DHF voting. When additional new funds are powered up, their weight will NOT count towards governance voting for the following 30 days. This adds a healthy buffer period to any potential malicious coordinated takeover attempt which allows the community a chance to respond, and is an important yet reasonable safeguard to help prevent attacks via funds stored on exchanges without impacting funds in any way.
- The Hive governance system is made up of both witness voting and DHF voting. When additional new funds are powered up, their weight will NOT count towards governance voting for the following 30 days. This adds a healthy buffer period to any potential malicious coordinated takeover attempt which allows the community a chance to respond, and is an important yet reasonable safeguard to help prevent attacks via funds stored on exchanges without impacting funds in any way.
- A huge number of preliminary changes to make running a Hive node easier.
- This is a simplified statement that covers a ton of work and portions of the core code. One of the most restrictive parts of growing Hive has been the cost, amount of resources needed, and the difficulty of running infrastructure to support the blockchain. It's meant that helping further decentralize Hive with more seed nodes, witnesses, and RPC nodes has been a lot harder to do than it should be. Exchanges running nodes have needed longer maintenance times and more direct help with Hive. Projects, dApps, and developers who want to build on Hive have found it can be hard to get started because they can't afford their own nodes or that public options are still limited. While this sounds very technical, it translates directly into a poor experience for end users and investors too. Making Hive easier, faster, and more affordable to run allows for better decentralization, from blockchain level to the diversity of projects and users in the ecosystem.
- This is a simplified statement that covers a ton of work and portions of the core code. One of the most restrictive parts of growing Hive has been the cost, amount of resources needed, and the difficulty of running infrastructure to support the blockchain. It's meant that helping further decentralize Hive with more seed nodes, witnesses, and RPC nodes has been a lot harder to do than it should be. Exchanges running nodes have needed longer maintenance times and more direct help with Hive. Projects, dApps, and developers who want to build on Hive have found it can be hard to get started because they can't afford their own nodes or that public options are still limited. While this sounds very technical, it translates directly into a poor experience for end users and investors too. Making Hive easier, faster, and more affordable to run allows for better decentralization, from blockchain level to the diversity of projects and users in the ecosystem.
- Correct the incorrectly excluded Hive airdrop recipients and include any additional users supported by the community via proposal voting.
- The list of corrections can be found in a previous post. Also, while the group of excluded users as a whole were voted against being included, some individual proposals have been supported by the community and will be airdropped during the first block of the hardfork.
- The list of corrections can be found in a previous post. Also, while the group of excluded users as a whole were voted against being included, some individual proposals have been supported by the community and will be airdropped during the first block of the hardfork.
It would be great if you can introduce a downvoting facility along with the current upvoting facility to the proposal system. The value of the proposal can be calculated based on the sum of both upvoted and downvoted stake.
I personally feel that it is one of the most needed change right now. I guess there is already a feeling that the proposal system is being exploited or there there is a possibility to exploit it.
I know that there is already a feature in pipeline to introduce a facility to amend the value. Along with that feature it will be great if you can introduce a downvote feature for proposals. I guess then it will be a lot more fair.
I feel many people would agree to this. 😀
There was talk of making proposals cost 1HBD per day to propose instead of just 10HBD total.
I think this could stop junk more than downvoting and it would burn more stuff too.
What if someone don't want a proposal to pop up at all. Reducing the cost won't help much. But it will definitely help but not for what we are trying to achieve with a downvote.
There are a few proposals that run for years or months that are just annoying to see. If it costs 1 HBD a day, people may think twice before running it for years when it isn't necessary.
I don't particularly like the idea of downvoting proposals unless it also comes with the option of being able to downvote witnesses.
Yes, I will also be very happy if a witness downvoting is also introduced. Ideally, when we moved to the new chain, it would have been fair if all the witness votes were cleared and new witness votes were made. That would have been a fair thing.
Apparently there was a major exploit with downvoting proposals on Bitshares (Steem predecessor.) I don't know the details and would like to read a write-up on that if anyone is willing to explain the risks of having proposal downvotes? From an intuitive point of view, it seems like a good idea at first glance.
I'm also just saying that from the top of my head. I'm finding it hard to foresee any problem with this. I believe that it can create a fair distribution of the resources. I guess many people did not initally like the idea of downvote system for the posts. But today we live with that. So why not experiment it.
Think of the refund proposal(s) as a way to downvote every other proposal
That's a work around and by the way voting a return proposal and downvoting are two different things.
Like ausbitbank said, if you upvote the "refund proposal" then you are essentially downvoting every other proposal to an equal amount of your upvote. If you want to also support a specific proposal, then upvote the refund proposal as well as the individual proposal you want to support, thus negating the "downvote" (return proposal).
I still think upvoting the return proposal is not the same as downvoting an existing proposal. Both are two different things. The return proposal is unnecessarily creating a huge bench mark for the proposals to even get listed. A small guy who is just starting with an idea will not even be able to come to the benchmark.
With the current system, we don't even have an option to bring a proposal down. If something is overrated, the community should have a facility to reduce the rating of a proposal. I'm sure return proposal is not a solution. It is just preventing to some extent but unnecessarily creating a huge benchmark like I said.
This system needs to be fixed and I think downvote would be an ideal solution.
For a moment forget the small guy who is just starting, and imagine the rich guy who is exploiting. He upvotes his exploit and downvotes everyone else thereby doubling his power. The small guy is even more screwed than when he had to face a return proposal, particularly when more than one rich guy is pulling the same shenanigans.
A return proposal is not an ideal solution to the small guy's predicament, but it is a solution to keep things moving without doubling the risk of centralization.
We already have a fair amount of centralization here already. We cannot help much. And yes return proposal helps but it definitely is not a solution.
By doing this you are also harming proposals you don't care about or don't know about. The return proposal is not ideal.
I disagree that downvotes are the answer to the problem you raise.
With downvotes in the current system a whale could upvote the return, upvote the ones they like, and downvote all other proposals. Then the barrier to entry for a new proposal would be FAR FAR worse than it currently is.
You can't just slap on downvotes and say "yep everything will be fixed now". You will have the same issues, only exaggerated.
There's nothing to disagree on regarding downvotes as I never said downvotes were the solution.
One account should not be able to vote on more than a certain amount of proposals and there could be a predetermined floor instead of relying on the return proposal to fulfil two functions. The return proposal was necessary to ensure the pool didn't get robbed by selfish proposals, however, allowing whales to actively control its level is neither fair nor ideal.
A fork could say proposals will not pass if they don't get at least x votes from at least y people, considering active hive. Everything below the floor will be returned to the DAO. The return proposal was a stop-gap measure to cover an oversight in the SPS/DAO and should be made permanent and fixed, or floating on some level based on some pre-determined function of active hive.
This is not really good, because if someone wants a certain proposal to get funded whereas not the others one, then this will not work
This this this this!
They tried the same approach on another blockchain but they abandoned it preety soon because they exploited it using or presenting an attack vector.
What is this other Blockchain that you are talking about? Don't you think the current system is also in such a way that it can be exploited?
bitshares
Great and exciting news! Starting a new chain was a huge step, but this feels like a first step towards a completely separate Hive identity where our chain will work a little differently than Steem's. Can't wait to start testing, I have my boxing gloves ready to punch the Release Candidate to see if I can break it. Cheers!
Awesome stuff! I especially like the 30 day cooldown to prevent hostile takeovers in the future. Keep up the great work!
Absolutely.
Can we also include changing the number of consensus witnesses to something larger, like say 100 for added security? That or change the number of votes from 30 to say 5, or even better would be 1 vote but with a vote slider to be able to vote for more than one witness with our stake? There was much talk of these things at the time of the hardfork but now they seem to have been forgotten about, at least publicly.
The problem with only 1 witness vote is it will be easier to cause a stalemate. One would only need 20% of HP instead of >50% of hp to do this attack.
How do you figure? 1 vote with a sliding voting scale so you can use all your voting power on 1 witness or however many you choose by adjusting the voting weight down.
I don't think you have put enough thought into this.
Currently, there is 140,623,980 HP, ~70 million HP is required to do a Sybil attack or 51% attack on the Hive network and elect the 17 witnesses necessary.
If your 1:1 proposal is enacted, ~7 million HP would make it certain 1 specific witness is in the top 20. Now (30 votes each) >50% is needed to get 1 or them all.
At a 1:1 voting (sliding scale doesn't matter and is probably a disadvantage if it is a coordinated attack), if everyone is voting ideally (impractical) ~200 million HP would be required to definitely have a 17 witness consensus making it much more difficult to attack this way.
However, ~ 28 million HP would be enough to get 4 witnesses in the top 20 (much easier to coordinate only requiring a few of the top whale accounts). If there are 4 witnesses not agreeing to a consensus, there is no consensus and hard forks are not possible. They could make whatever demands they want to change their vote. Until it is changed no hard fork is possible without creating another chain like Hive 2.
If you are thinking Bah this would never happen! Please check out the most recent history on Hive/Steem where it happened when >50% (the current amount) is required to mess things up.
I have thought about this plenty and worked out the napkin math as well and it all comes down to one easy trade-off. Someone preventing something from happening is infinitely better than them being able to impose their will and change the entire network.
Right now we need > %50 to attack the network and impose will or make Hive a dead project.
If > %50 feels something is good, that is actually a majority. Even if they are blocked, > %50 wanting something bad enough to do this spells bad news moving forward. I know calling it a consensus is stupid, but technically >80% isn't a consensus either.
If your changes are done an attacker will need %20 > to make Hive a dead project. Attackers will get what they want because they won't move their votes until it happens. Imagine if it was done immediately after a hard fork with a bug that could be exploited?
The proxy.token did this when Steemit, Poloniex, Binance and Huobi were attacking the Steem network. For weeks proxy.token ensured no one would get a consensus and started asking for stupid things like banning certain witnesses, removing of downvotes, quicker power downtimes (so exploiting the network would be even easier), and a bunch of other crazy changes the majority of people disagreed with. It was so screwed up Hive was forced to be created. This permanently damaged the reputation of DPOS and subsequently both networks.
Lowering the number of witnesses one can vote for is not making the network safer. A lot more thought and complicating factors go into this. For now, allowing people to vote for anything less than 17 witnesses is dangerous because it will make a coordinated attack easier rather than more difficult. The majority will lose their power to prevent attacks.
If it ain't broke don't fix it. Please think of a solution that doesn't make attacking Hive easier.
This doesn't make attacking HIVE easier, it makes controlling it significantly harder. Right now it takes significantly less HP to control the consensus witness spots than 5 votes per account (or 1 vote with a slider) would require. That isn't really debatable, it's a fact. Had either of those measures been in place when Justin Sun bought the Steemit.Inc stake he never could have controlled the top 20 witness spots and none of this would have happened.
Which means it clearly is/was broke and needs to be fixed.
i agree with the idea of increasing consensus witnesses to at the very least 100.
If not, surely another takeover, (like the 1 that occured with with steem) could happen in the future.
Can I please use this in posts or tweets?
Sure :)
Nice.
🐝 🐝
We should look to go beyond "blockchain competition" and look to compete with giants like facebook , medium and the twitters. Currently the entire Hive blockchain is a function of posts that are no older than 7 days. No one cares about anything older than that since the payout is already done. Its just human psychology.
Most of the content that the world consumes like food, travel, music, humor and art etc have an indefinite shelf life. They generate revenue for the content maker for years. If Hive is to become a hub for content makers so that a billion people from around the world log on to hive to have "a good time" the platform needs to be something that a professional content maker can use to monitize their content beyond the current seven days.
The biggest competition to Hive is not another blockchain called steem. But technologies like Brave browser and BAT token. Which is rapidly growing and ensuring that content makers can get paid directly by users on the current platforms they exist on. If BAT becomes the mainstream crypto protocol to support good content, it will significantly reduce the incentive for newer and younger content makers to seek fresh platforms.
That will not be good for a platform that in terms of its size with respect to the larger digital world is still in its infancy. Hive will need to grow to a certain size and stature so that it can survive the changes that happen in the the larger eco-system. If one were to look at a bench mark. I would say we should look to become atleast a size that compares to medium.(com)
I agree entirely, I think it is antithetical not to have a very long reward period. Hive is fundamentally intended to reward content contributions, but think of somebody who made a post years ago about something that is just now exploding onto the scene -- the farther ahead of the times they were the more impressive their contribution, yet hive cannot reward them.
Long-term payouts are also essential to attract creators that have always been making a living through content. In the US Copyright was originally 14 years with the option to double for an additional 14 (since expanded by corporate interests to insane lengths). The digital world moves a lot faster, but long-term payouts could still really pull the quality up. I bet a promise of potential support for 4,096 days (about 11 years) with plan to extend that to 8,192 days would be supported by creators.
Technical limitations are involved -- the overhead of an extended general vote and payout period is huge. Instead of tracking votes in the same way as the first 7 days, only top content from a period of time would be 'monetized' and a separate chain could track what is and isn't viable from each time period. Determining top content might be done through a few systems, perhaps some of the top posts by their original 7 day totals mixed with some trending content from the period and any content the creators pays/burns to activate (they could have just paid to fake it into the top anyway, but this way the payment could go to the community instead of an attacker of the community).
Idk. thoughts?
We already fixed this with d.tube, the Avalon Blockchain is launching on July 1st, has Limitless monetisation, it also has Voting Power system that goes up forever + 100% curation system. + No abusers as top Whales as it is in Hive
Have invested in some of those dtube tokens. Hope it rocks ! :)
I started writing a response but then it became so big i though i will do a post on it :P . I have tagged you on it. Would love to hear your thoughts on them.
Here is the Post
We already fixed this with d.tube, the Avalon Blockchain is launching on July 1st, has Limitless monetisation, it also has Voting Power system that goes up forever + 100% curation system. + No abusers as top Whales as it is in Hive
This.
good move, finally.
One question. does that include rewards?
no, if you power up HP, it will do everything else in the ecosystem that it normally would. It just starts on a countdown timer for governance issues specifically :)
No, my question were about HP earned through rewards.
like, if i get 10 HP today from rewards, will it work on my witness vote?
OH! Sorry, I totally misunderstood you~ I get what you're saying now. Astute question! Liquid funds powered up via a command are subject to the cooldown time. Rewards claimed as staked will count towards your governance vote immediately. There's no way you can claim enough staked rewards to overthrow the totality of the rest of consensus, so this should be an unimpeded way to increase your voice that comes with using and contributing to the network over time!
Yes i agree with that, and that is why i asked.
Thanks crim. Helpful and charming as always.
This HF is setting the groundwork for future expansion and success. Nothing flashy for now, get over it.
BTW, I bet my ass that the centralised spreadsheet run by Jsun will just copy this code... Because that's all they can do.
I'm still getting triggered every time I see "Custom Json" because it is tooo damn close to "Jsun". Can we please rename that shit in HF 25...
No lol, json is a widely used format.
this is actually a really great point. One of the big things that has been done was combing through all of the code and changing much of the naming conventions/schema to be different enough that a quick copy paste wouldn't really be possible. Yes, it's open source and could be engineered, but just plopping parts of the Hive codebase into something else wouldn't be "plug and play", as it were.
That's great. The level of technical competence of JSun's team is pretty limited if past experience is anything to go by.
Hive has a huge advantage of having a large, commited and very skilled group of blockchain devs.
We might even be able to change more quickly than JSun can copy. Get inside their decision loop.
That's a smart move. Even though this is open source we should not make it "easy" to copy pasta.
This would be a continuation of hive's progression, do far I'm satisfied with what the fork hopes to fix really. Let's get it done
without the ability to translate - everything that you do does not make sense to most people
It's great to see things coming along and it's also good that all users have the ability to help and be a part of the changes.
Looking forward to Monday, and I will certainly try to help test from an end user point of view.
Cool. Great things coming.😎
Awesome work guys....
On a scale of 10, how ''easier is it run a Hive node as described above"?
Great regards
Same level of technical acumen required, but fewer resources required such as high amounts of RAM.
Where is the current HF24 development code? How much RAM would be needed? I've been trying to run a full node for ages without any success. And MIRA is insanely slow!
UPDATE: Found it.
This is a great security improvement to the chain!
Im excited for this upcoming Monday I cannot wait, I am digging all the changes listed and they are necessary to better our Hive. Keep it up coders! I hope to move from community building to coding soon 😀.
These sound like good changes and updates.
Thanks for the information!
Great looking development signals.
Get your forks ready! Looking forward to testing some code 👊
Thank for the update, I should be around to help test.
Great. I'm willing to help test.
I sure hope this has been setup better than the shitty steem hardforks and its easier because honestly that crap was annoying AF
Great work guys, and I love this coming change
Nossa meu Deus
Great efforts and hard work by #Hive devs... Awesome..!! 👍
What and how are the current infrastructure costs handled by the community?
Are we also working on #HiveMediaTokens ?
Thank You all so much for your endless work on Hive!!
If I know more about being an IT, I will help to develop more the HIVE.
Hey ... Nice work!
Can we change the semi superlinear reward curve to pure linear ... now that we have 50/50 ....
Can we give this hard fork a better name ?? Cuz 24 in Cantonese = easy to die 😂😂. Just saying... 😉
Does it really? Lol...
what will be the chainID? i guess we need to specify it when creating a steem instance in our beem python code...
Good to see you're still at it! thanks for the info.
Just an idea:
For a next HF I suggest automatically disable witnesses after reaching 3 thresholds:
In order for a witness to be automatically disabled, it would have to meet all 3 criteria. This would automatically remove old witnesses who simply gave up the job without disabling first for some reason. I consider it a good alternative idea to use just the
price feedcriteria alone, but for 7 days.But I still defend my other 2 proposals: Vote Dilution and Vote Expiration, specially the vote expiration part as I believe witnesses have to keep earning our votes by their continuous work. Some PeakD developers agree with me on that.
@hiveio Hm. Thanks for sharing! Honestly I think that it would be good if we get that type via emails. :)
Congratulations @hiveio! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :
You can view your badges on your board And compare to others on the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPDo not miss the last post from @hivebuzz:
Support the HiveBuzz project. Vote for our proposal!
I am looking forward to see the improvements.
can i know who there is behind hiveio account?
Look forward to it. I have a problem with updating my profile. When I click on settings, nothing happens. I have to refresh the page for the url to work. When I get to the page I'm unable to update anything in my settings. When I put something in the about field or website field & hit update, nothing happens.
I especially appreciate this part:
"It's meant that helping further decentralize Hive with more seed nodes, witnesses, and RPC nodes has been a lot harder to do than it should be. [...] Making Hive easier, faster, and more affordable to run allows for better decentralization, from blockchain level to the diversity of projects and users in the ecosystem."
I would now know the details but even if current tutorials certainly work for some installations, when something does not work it is currently a tough road, so having it better is an absolute great thing!
The rewards earned on this comment will go directly to the person sharing the post on Twitter as long as they are registered with @poshtoken. Sign up at https://hiveposh.com.