Steem 0.20.2
Steem Velocity 0.20.2 Release Notes
The hardfork is scheduled for Tue, 25 September 2018 15:00:00 UTC (11:00:00 EDT)
All nodes should to upgrade to 0.20.2.
Reindexing
Steem 0.20.2 does not require reindexing from 0.20.1. If upgrading from 0.20.0 or older, reindexing is required.
Overview
This is a hard fork release. The primary changes in this release are to the account creation and voting power systems and the addition of the resource credit system.
Steem 0.20.2 is built on top of the Appbase architectural changes released in Steem 0.19.10. If you are not familiar with the changes introduced in that release, we strongly recommend you read those release notes as well.
Steem 0.20.2 usurps 0.20.1 as the official release for Steem Velocity and contains some changes to how the RC system will behave at the time of the hardfork to create a better user experience.
Resource Credits
Steem Velocity moves beyond the bandwidth system to a an improved system based on Resource Credits (RCs). The RC Plugin defines blockchain resources and limits medium and long term use through stake based Resource Credits. Based on the usage of a particular resource, there will be a market price in RCs. When a transaction is included, the issuing account will be charged a number of RCs according to the resources consumed by the transaction. In this release those resources are history bytes, market bytes (these are analogous to the bandwidth plugin), state size, execution time, and subsidized accounts. The RC Plugin is designed to be extensible and more resources may be added if the need arises. This is the most comprehensive update to the resource management of the Steem Blockchain since the initial release in March of 2016.
There is also a new rc_api that will allow querying of various RC metrics. Those calls are get_resource_params, get_resource_pool, and find_rc_accounts.
The RC Plugin is listed as a dependency of the Witness Plugin. When HF 20 goes into effect, the Witness Plugin will automatically begin listening to the RC Plugin for bandwidth feedback instead of the existing bandwidth algorithm. For the time being, both algorithms will continue to operate but only one will be listened to for the purposes of rejecting transactions.
If, after HF 20 goes into effect, there is a problem with the RC Plugin, witnesses can go back to listening to the bandwidth algorithm by setting the following command line arguments. --witness-skip-enforce-bandwidth=false --rc-skip-reject-not-enough-rc=true. These arguments are exclusive and a steemd node will not start if they are both set to true or both set to false when running the Witness Plugin. In such an event, Steemit and the witnesses will coordinate to make the switchover.
Account Creation Changes
Account Claiming/Creating
There are a new pair of operations, claim_account_operation and create_claimed_account_operation that upgrade the account creation process. When combined, these operations work identically to the current account_create_operation. When used separately, this allows an account to pool claimed accounts and create them at will later on. When combined with subsidized account creation, this will lead to the smoothest user experience by allowing faucets to buffer subsidized accounts at a steady rate and consume them sporadically to meet user demand.
It is recommended that all faucets upgrade to use this creation flow as any possible future updates to account creation are more likely than not to be implemented using these operations.
struct claim_account_operation
{
account_name_type creator;
asset fee;
extensions_type extensions;
};
struct create_claimed_account_operation
{
account_name_type creator;
account_name_type new_account_name;
authority owner;
authority active;
authority posting;
public_key_type memo_key;
string json_metadata;
extensions_type extensions;
};Subsidized Account Creation
After HF 20 goes into effect, the blockchain will begin limited subsidization of account creations. A subsidized account can be created by paying a fee of 0 STEEM with the claim_account_operation. There are consensus and non-consensus limits on subsidized account creation. There are two primary consensus mechanisms. The first is a global pool of subsidized accounts that is enforced in consensus. This prevents unlimited creation when to pool is empty. The dynamics of the pool are controlled by the witnesses and discussed later. The second is a per witness consumption that prevents a compromised witness from draining the subsidized account pool. The non-consensus limit exists in the RC Plugin and charges account creators RCs to create subsidized accounts. The consensus supply is used as input to determine the cost in RCs of creating a subsidized account.
Account Creation with Delegation
The account_create_with_delegation_operation is deprecated and as of HF 20 will stop working. This was an initial attempt at cheaper account creation and is eclipsed by subsidized account creation.
Burned Account Creation Fee
The account creation fee is now burned upon account creation instead of being powered up to the new account. To compensate for the reduction in available RCs, each new account is granted a bump to their RCs proportional to the burned fee. This is retroactively applied to all accounts created prior to HF 20.
Minimum Power Down Restriction
We are removing the minimum power down restriction that prevents users from powering down their Steem Power until they have earned a certain amount. This was created to prevent new accounts from instantly powering down the STEEM used to fund the account. Because STEEM is now burned when an account is created, this restriction is not needed.
Witness Changes
Set Properties Operation
There are a number of new properties added in Steem 0.20.2 and the existing witness_update_operation does not support extension. witness_set_properties_operation is an extensible replacement that supports new properties added in 0.20.2 and can support properties that may be added in later releases.
Documentation on witness properties can be found here.
struct witness_set_properties_operation : public base_operation
{
account_name_type owner;
flat_map< string, vector< char > > props;
extensions_type extensions;Account Creation Fee Change
When account_create_with_delegation_operation was introduced, we changed the semantics of the account creation fee. In Steem 0.20.2 we are reverting the semantics back to the original. After HF 20, the account creation fee is simply the required STEEM to create an account and the complications that were added will be removed. To ease this transition, at the time of the hardfork, all elected witnesses will have their account creation fees increased by 30x. The amount of STEEM required to make an account before and after the hardfork will not actually change. Witnesses are required to update their infrastructure to account for the change after the hardfork, but the blockchain will ease the transition.
Price Feed Format
It has already become customary to report price feeds as an SBD:STEEM pair. HF 20 will require the price feed to be reported this way for consistency and optimization.
Upper Limit on Votable Max Block Size
As a restriction of the p2p code, the highest votable max block size will be limited to 2MiB.
Voting Power Changes
Manabar
The way voting power is now tracked is via a "manabar". Rather than tracking percentage voting power remaining, it is now tracked as unspent rshares, also called mana. Your max mana is a function of your SP, delegations, and active power down. Mana regenerates proportional to your max mana and is updated whenever there is a change to your max mana or a vote takes place. This lazy updating is important for API consumers to be aware of. However, it is easy to extrapolate current mana. Mana is regenerated from 0 to 100% of max linearly over 5 days. The manabar records when it was last updated. The current mana is last_mana + (now - last_update) * max_mana / 5 days. This is, of course, capped by max mana.
Per Satoshi Steem Power
This change is largely motivated by a refinement of how we think about Steem Power in terms of voting power. Some voting exploits relied on this lack of a foundation to vote with more stake than an account should have. While it would be easy to assume that any maximally acting actor should use the exploit, we don't want users of Steemit.com, DTube, Busy, and other Steem DAPPS to be at a disadvantage because they don't use these exploits. What we came up with, or rather clarified internally, is a set of base rules defining how we treat Steem Power in this regard. Each satoshi of Steem has power associated with it regardless of whether it is powered up or not. That power is used for all stake based actions such as voting and RCs. The power regenerates linearly from 0 to 100% over five days. All liquid STEEM is treated as having 100% power even though it is not used for stake based calculations. The result of this decision is that when you power up STEEM, you instantly have access to it at 100% power, but the STEEM must be powered back up to 100% before it becomes liquid. To do this, the week before STEEM is powered down from Steem Power to liquid STEEM, it is not used for voting. This gives the STEEM seven days to regenerate its power.
This distinction is important and is a departure from the current rules. Currently, new Steem Power inherits the voting power of the account. 100 STEEM powered up into an account with 0% voting power would effectively have 0% power and the same STEEM powered up into an account with 100% voting power would effectively have 100% power. This discrepancy is fixed and was the crux of several delegation/voting exploits. Now, when the 100 STEEM is powered up, 100 mana is added to each account, regardless of how much mana the accounts had previously.
Return Delegation Return Time
When Steem Power delegations are returned, the delegated STEEM needs to power up as well. Even though the return time was 7 days, because we had not defined these interactions well, exploitation was possible. Now, with well defined interactions, we have actually reduced the return time to 5 days and fixed exploits.
Vote Dust Threshold
There is currently a small threshold that must be met in order to vote. This was to prevent "dust" votes that don't impact rewards. However, this leads to a bad user experience for new users that tend to have low value accounts. Instead, the threshold is subtracted from all votes and votes are allowed no matter how few rshares the vote allocates.
Limit Order Expiration
Limit orders must expire within 30 days of creation. Existing limit orders with long or non-existent expirations are having their expiration set to 30-31 days (deterministically pseudorandom) after HF 20.
Reward Changes
Curation "Reverse Auction" Window
The curation "reverse auction" window has been reduced from 30 to 15 minutes.
Curation "Reverse Auction" Destination
Currently, the curation rewards lost in the reverse auction are sent to the author. This gave the author an unfair advantage when self-voting because they would not pay the price of the reverse auction and would be able to guarantee themselves as the first curator and get a larger portion of the curation rewards. Now the curation rewards lost in the reverse auction are sent back to reward pool instead to put the author on an even playing field with other curators.
Symmetric Vote Lockout
For the last 12 hours before content is rewarded both positive and negative changes to reward payouts will decline linearly. Previously only upvotes were allowed which lead to some users waiting until their content was about to pay out and then upvoting it considerably without fear of moderation. The symmetric approach to positive and negative feedback prevents excessive trolling and rewards exploitation equally.
Comment Limit
The comment cooldown of 20 seconds is being reduced to 3 seconds (one comment per block).
SBD Changes
The Steem Blockchain has some rules in place to encourage healthy market dynamics for SBD. Those are being tweaked to attempt to keep SBD on the peg more often. SBD will slow printing linearly starting at 9% of the market cap (instead of 2%) and stop entirely at 10% (Instead of 5%).
BIP-0062 Signatures
The definition of canonical Steem signatures now follows the BIP-0062 specification to prevent transaction malleability. The previous implementation was not quite right and while it did not allow transaction malleability, it did reduce the entropy of canonical Steem signatures.