The blockchain for Smart Media Tokens (SMTs) and decentralized applications.
All nodes should upgrade to 0.23.0.
Steem 0.23.0 does not require reindexing from 0.22.1.
At the demand of the community, the PR #3649 has been merged with the following functions:
Power-down period will be reduced to 4 weeks, instead of the current 13 weeks. This change is to promote more users to stake STEEM without fearing their assets locked up for a long period and to participate in Steem activities. By creating a more friendly environment for investors, we expect this change to positively enhance STEEM stakeholders' experience.
All nodes should upgrade to 0.22.1.
Steem 0.22.1 does require reindexing from 0.22.0. If you have not upgraded to MIRA, please read the MIRA release notes on that process if you wish to run your Steem node backed by MIRA. Otherwise, a non-mira 0.22.1 is available under the tag v0.22.1-no-mira.
This is a bug fix for 0.22.1. There is a subtle behavior in the new curation rewards curve that lead to votes being able to have a curation reward weight of -1, which when stored in an unsigned field resulted in a computed value of 2^64 - 1. When paid out, these votes were attempting to receive trillions in STEEM, which was caught by other assertions. There is not a problem with mathematics backing the curation reward curve, but subtleties in the integer based approximation of a square root. The release floors the curation reward weight in such cases to 0. This can only happen when votes are allocating very few rshares and would not receive a reward, so forcing the value to 0 will not impact how rewards are allocated.
All nodes should upgrade to 0.22.0.
Steem 0.22.0 does not require reindexing from 0.21.1. If you have not upgraded to MIRA, please read the MIRA release notes on that process if you wish to run your Steem node backed by MIRA. Otherwise, a non-mira 0.22.0 is available under the tag v0.22.0-no-mira.
This is a bug fix for 0.21.1. There was an issue while calculating downvote mana during delegations. This release fixes the calculation.
All nodes should upgrade to 0.21.1.
Steem 0.21.1 does not require reindexing from 0.21.0. If you have not upgraded to MIRA, please read the MIRA release notes on that process if you wish to run your Steem node backed by MIRA. Otherwise, a non-mira 0.21.1 is available under the tag v0.21.1-no-mira.
This is a bug fix for 0.21.1. There was an overflow in a calculation that caused a chain halt. This release fixes the calculation and allows the chain to continue block production safely.
All nodes should upgrade to 0.21.0.
Steem 0.21.0 does require reindexing from all previous versions. If you have not upgraded to MIRA, please read the MIRA release notes on that process if you wish to run your Steem node backed by MIRA. Otherwise, a non-mira 0.21.0 is available under tag v0.21.0-no-mira.
This is a hard fork release. The primary changes in this release are the introduction of the Steem Proposal System (SPS) and the Steem Economic Improvement Proposal (EIP).
The Steem Proposal System (SPS) is an on chain decentralized autonomous organization (DAO) that allows users to submit proposals for funding and vote on which proposals should be funded. The SPS is funded by means of inflation and donations. SBD (and only SBD) can be sent to the account steem.dao. Additionally anyone can make donations by setting the account as a comment reward beneficiary. Warning: There is no mechanism for refund from the steem.dao. Non SBD transfers will be rejected, but any SBD donated cannot be refunded.
The inflation budget has been changed to fund the SPS. The content rewards are being reduced from 75% of the budget to 65% to give 10% of the inflation budget to the SPS. The actual inflation schedule has not changed at all. The inflation schedule continues as planned. As of block 34 million, inflation was at 8.42% and will continue to narrow 0.01% every 250k blocks until it reaches a rate of 0.95%
One one-hundredth of the balance of the steem.dao account will be paid out every day in one hour intervals in order of approval. It is strongly recommended that the community creates and maintains refund proposal(s) to prevent proposals with little to no approval from receiving funding.
There are three new operations for interacting with the SPS.
struct create_proposal_operation : public base_operation
{
account_name_type creator;
account_name_type receiver;
time_point_sec start_date;
time_point_sec end_date;
asset daily_pay;
string subject;
string permlink;
};
struct update_proposal_votes_operation : public base_operation
{
account_name_type voter;
flat_set_ex< int64_t > proposal_ids;
bool approve = false;
};
struct remove_proposal_operation : public base_operation
{
account_name_type proposal_owner;
flat_set_ex< int64_t > proposal_ids;
};
When a proposal is created, a post must be specified that is linked to the proposal. It will be @creator/permlink. All proposal creators should use that post to keep their proposal up to date so that stake-holders can easily review and approve the proposal. There is a 10 SBD fee that must be paid in order to create a proposal. The fee is paid in to the SPS. A proposal can, at most, receive daily_pay per day, but if the proposal is not paid for a round either from losing approval votes or the budget not being able to cover the proposals costs, the lost pay will not be made up. Proposals are not owed anything by the blockchain until they are actually paid.
Proposal IDs are generated by the blockchain and are a global unique identifier of the proposal. The ID is returned with the proposal on all SPS API calls. Because the proposal ID is generated by the blockchain, it is strongly encouraged to use the transaction status API to wait for the transaction creating the proposal to become irreversible before approving it or else the proposal ID may change and the approval will be for the wrong proposal.
The following API calls have been added to support accessing proposal information. database_api.list_proposals, database_api.find_proposals, database_api.list_proposal_votes.
We are changing the rewards curve to a convergent linear rewards curve. The new curve is of the form n^2/(n+1). It will start out super linear and then become linear as stake is concentrated on content. It will incentivize concentration of stake the same way the quadratic rewards did, but unlike quadratic rewards, this curve will not run away with the incentivization. As more stake is concentrated on content the incentivization to concentrate more stake will actually decrease to zero at infinity.
The curation reward curve has been updated alongside the content reward curve change. Steem has always derived the curation reward curve from the content reward curve to preserve certain properties. While the curve has changed, the expected behavior has not changed at all.
To encourage more thoughtful curation and user engagement, curation rewards will receive 50% of the rewards budget (up from 25%).
Each user now has a mana pool specifically for down votes. This pool is 25% of the upvote mana pool. Downvotes will consume this mana first before consuming regular mana. When voting, 1/50th of the remaining mana is used for a 100% vote. The same math is used for downvote mana but multiplied by 4 because the downvote mana pool is 25% the size of the normal mana pool. The maximum of these values is used. When both mana pools are at 100%, the values are the same. When downvote mana runs out normal mana is used in the same manner as the current behavior.
In Hardfork 20 we reduced the curation reverse auction window from 30 minutes to 15 minutes. The change was received positively and the benefits of the system today are nebulous. We are reducing it further to 5 minutes.
We are adding a new account update operation:
struct account_update2_operation : public base_operation
{
account_name_type account;
optional< authority > owner;
optional< authority > active;
optional< authority > posting;
optional< public_key_type > memo_key;
string json_metadata;
string posting_json_metadata;
extensions_type extensions;
};
This operation adds a new field, posting_json_metadata that can be updated using the posting key. json_metadata added to an account prior to the hardfork is copied to posting_json_metadata. posting_json_metadata is returned on the account_object in any API calls that return accounts. Apps that want to update metadata with the posting key can migrate to doing so. Apps that don't update will continue to work as they currently do.
Users that have 0 mana can still vote, but those votes will not receive curation rewards nor will they impact rewards.
There was a rounding error when enforcing the SBD "Haircut" rule that would allow SBD to continue to be printed at a slow rate despite the supply. This has been fixed and SBD printing can properly stop when the supply is too high. Note: SBD printing for the SPS does not follow this rule and will continue to print SBD regardless of the supply.
Comments can only be created once per block but edits are just as impactful from a performance perspective and have no such lockout. We are adding a one comment edit per block lockout to accounts.
When calculating Steem Power power down rates, the rate was rounded down such that up to 0.000012 VESTS would withdraw on a 14th week. Those VESTS have been redistributed across the 13 week power down to eliminate the 14th week of a dust power down.
There was a bug in the p2p code that would not always disconnect from peers that the node wanted to disconnect from.
All nodes should upgrade to 0.21.0.
Steem 0.21.0 does require reindexing from all previous versions.
This version of 0.21.0 does not build MIRA by default in our pre-built docker image.
Steem 0.20.12 does require reindexing from all previous versions.
Steem 0.20.12 is an identical release to 0.21.0, containing the latest security and stability fixes for Steem, but will not vote for 0.21.0 if ran by a witness.
This version does build MIRA by default in our pre-built docker image.