Pre-release
Pre-release

@mvandeberg mvandeberg released this Oct 15, 2018 · 37 commits to master since this release

Assets 2

Steem Velocity 0.20.6 Release Notes

This is a bug fix release primarily targeting the RC Plugin.

Note: witness_api plugin no longer exists, and should be removed from config.ini if present.

Reindexing

  • Nodes running the RC plugin need to manually force a reindex with --replay.

  • Nodes that do not run the RC plugin do not need to upgrade or replay.

  • At this time we recommend witnesses and API nodes upgrade.

  • This is an optional release for exchanges. While the RC values will be different on 0.20.5 and 0.20.6, we have determined through our testing the difference will not be significant and should not cause problems for exchanges. If an exchange wants to update we recommend reindexing 0.20.6 up on a separate machine and switching only once the 0.20.6 node is functional.

Fixes

  • RCs are no longer calculated prior to HF20 (#3007)

  • Removed the old bandwidth system. This includes the removal of several API fields that were specific to bandwidth and the removal of the witness_api, which was used exclusively for returning information related to bandwidth. (#3029)

  • Changes were made to the RC parameters to conserve current pricing while more aggressively protecting blockchain resources at high usage levels. (#3061)

  • The state byte cost for votes has been reduced as votes are only required in consensus before a comment has been paid. (#3064)

  • Negative RCs are limited to 2 hours worth of regeneration. (#3050)

  • The execution time cost of custom json operations has been reduced by 20 times for all custom json operations except those used by the follow plugin. (#3027)

  • RC Execution Time was not be charged against ops. This has been fixed and execution time is properly being checked. (#2972)

  • Fixed command line interface compatibility issues with boolean flags. Flags work as intended on the command line but are settable to boolean values in the config file. For example, on the command line you can set --enable-stale-production or set it as enable-stale-production=true in the config. (#3025)

  • The account creation fee in the command line wallet uses the correct HF 20 value. (#3019)

@theoreticalbts theoreticalbts released this Sep 29, 2018 · 121 commits to master since this release

Assets 2

Release notes for 0.20.5

Steem Velocity 0.20.5 Release Notes

Reindexing

  • Nodes that do not run the RC plugin do not need to upgrade or replay.
  • Non-witness nodes that run the RC plugin should generally replay the blockchain.
  • Exchanges and private full nodes used exclusively by accounts with large Steem Power balances do not urgently need to upgrade or replay [1] [2].

[1] If you choose not to upgrade, you should re-consider if you notice that transactions submitted to your node seem to frequently get "lost," i.e. not included in blocks. Upgrading to 0.20.5 should fix this issue.

[2] If you choose not to upgrade, you should re-consider if the accounts broadcasting transactions on your node have low Steem Power or RC. Upgrading to 0.20.5 should fix issues experienced by such accounts.

Witnesses

  • To fix these known issues for most accounts, witnesses should upgrade immediately without replaying.
  • Witnesses should replay the blockchain to retroactively fix RC of all affected accounts.

Fixes

  • Fix a timing logic issue introduced when removing RC manabar regeneration cap. #2994
  • Fix an issue which prevents newly created accounts from immediately receiving RC due to the account creation fee. #2997

@mvandeberg mvandeberg released this Sep 28, 2018 · 128 commits to master since this release

Assets 2

Steem Velocity 0.20.4 Release Notes

This is a bug fix release regarding the rc plugin. All nodes running the rc plugin should to upgrade to 0.20.4.

Reindexing

Steem 0.20.4 requires reindexing from previous version if running the rc plugin. Please note: The witness plugin and network broadcast API specify the rc plugin as dependencies. All of the provided Docker configs run the rc plugin.

Fixes

  • Virtual ops now properly appearing in get_ops_in_block api call. (#2936)
  • Return the correct value for max_rcs via API calls. (#2944)
  • Fixed condenser_api.get_accounts returning invalid values for voting power. (#2947) (#2962)
  • Fixed new witness_properties not being reported correctly in condenser_api. (#2942)
  • Properly credit burned account fees to account max RCs. (#2958)
  • RC plugin enforcement now required for witnesses and broadcast nodes (#2965)
  • Accounts with -100% of max RC can now regenerate RCs. (#2968)
  • Increased RC parameters to better allow accounts with lower SP to transact at higher rates. (#2974)
  • RCs are credited to the account on power up and incoming delegations. (#2961)

@mvandeberg mvandeberg released this Sep 21, 2018 · 160 commits to master since this release

Assets 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.

@mvandeberg mvandeberg released this Sep 19, 2018 · 166 commits to master since this release

Assets 2

Steem 0.20.2 contains an update to the RC code to support a better user experience at the time of HF 20. We recommend all nodes run 0.20.2. If you are not running the rc plugin or the witness plugin, you may continue running 0.20.1.

@mvandeberg mvandeberg released this Sep 11, 2018 · 188 commits to master since this release

Assets 2

Steem 0.20.0 contains a few bugs that have been fixed in 0.20.1. We recommend all nodes run 0.20.1 and will not support 0.20.0.

Aug 24, 2018
Merge pull request #2843 from steemit/merge-develop
Merge develop

@mvandeberg mvandeberg released this Aug 16, 2018 · 506 commits to master since this release

Assets 2

Steem Equality 0.19.12 Release Notes

Witness nodes are strongly encouraged to upgrade to 0.19.12 if running 0.19.11.

Reindexing

0.19.12 should not need reindexing when upgrading from 0.19.11.

Overview

This is a soft fork bug fix release.

Bug Fixes

The previous authority membership soft fork was too restrictive, inadvertently limiting use of some accounts. The limits have been adjusted accordingly.

@mvandeberg mvandeberg released this Aug 7, 2018 · 511 commits to master since this release

Assets 2

Steem Equality 0.19.11 Release Notes

Witness nodes are strongly encouraged to upgrade to 0.19.11 if running 0.19.10.

Reindexing

0.19.11 may need reindexing when upgrading from 0.19.10 due to how a bug fix in 0.19.10 was implemented.

Overview

This is a soft fork bug fix release.

Bug Fixes

There was a bug in how witness nodes were heuristically calculating the block size when generating a block that could lead a node to produce a block that was too large. (#2632)

Authority membership size was not being enforced and is now checked.

Fixed a bug in the logging config that could inadvertently lead to the data dir being wiped. Also added a more generic log-appender option that can specify a either a file or a stream in the same option (#2614)

The write processing thread was started to early in the steemd startup process which lead to nodes being pegged at 200% CPU during reindex. Reindex was not parallelized and one core was busy waiting. This thread will now start at the correct time and reindex will only consume the needed 100% CPU. (#2613)

@mvandeberg mvandeberg released this Aug 7, 2018

Assets 2

Steem Equality 0.19.6 Release Notes

Witness nodes are strongly encouraged to upgrade to 0.19.6 if running 0.19.5.

Reindexing

0.19.6 may need reindexing when upgrading from 0.19.5 due to how a bug fix in 0.19.5 was implemented.

Overview

This is a soft fork bug fix release.

Bug Fixes

There was a bug in how witness nodes were heuristically calculating the block size when generating a block that could lead a node to produce a block that was too large. (#2632)

Authority membership size was not being enforced and is now checked.