Steem Velocity Hardfork - Hardfork 20

in #steem6 years ago

HF20 thumb.jpg

In today’s post, we will provide you with a summary of the changes in the Velocity Hardfork (i.e. Hardfork 20). The goal of this post is to be the definitive guide for all of the changes included in the Hardfork which is scheduled to take place on Tuesday, September 25, at 11:00am EST. The changes in the Velocity Hardfork are dependent on the approval of a super-majority (17/21) of the witnesses voting in favor of the Hardfork.

Resource Credits

One of the major changes in the Velocity Hardfork is a change from our existing Bandwidth system to a new-and-improved system based on Resource Credits (RCs).

Steem is one of the only freemium blockchains in the world. The new RC system will make it the most advanced freemium blockchain in the world without compromising the existing features and functionality that make Steem such a powerful platform for building DApps.

The details of how this new RC system will work are described in our recent post Blockchain Update 4: Resource Credit Implementation Details.

GitHub Issue 2457, GitHub Issue 2511, GitHub Issue 2512, GitHub Issue 2521, GitHub Issue 2549, GitHub Issue 2563, GitHub Issue 2600, GitHub Issue 2621, GitHub Issue 2624, GitHub Issue 2625, GitHub Issue 2626, GitHub Issue 2627, GitHub Issue 2631, GitHub Issue 2546, GitHub Issue 2547, GitHub Issue 2648, GitHub Issue 2649, GitHub Issue 2650, GitHub Issue 2679, GitHub Issue 2685, GitHub Issue 2694, and GitHub Issue 2703

Updates to Account Creation

The primary goal of the Velocity Hardfork is to change the account creation system in order to lower costs and improve the new user onboarding process.

Discounted Account Creation

The Velocity Hardfork will give users the ability to create new accounts at a discounted rate, potentially without having to pay any STEEM or delegate any Steem Power in order to create the account. When creating a new account, users will be able to use RCs instead of a portion (or all) of the STEEM account creation fee.

The RCs that get spent when creating discounted accounts are the same RCs that get consumed when users interact with the blockchain. This limits users’ abilities to interact with the blockchain when they run low on RCs. Users (especially ones with a moderate-to-low amount of Steem Power) should be careful not to spend too many of their RCs on creating discounted accounts, otherwise they won’t be able to interact with the blockchain until their RC mana recharges.

GitHub Issue 1771, GitHub Issue 1772, GitHub Issue 2651, GitHub Issue 2700, and GitHub Issue 2710

Discount Account Creation Tokens

The blockchain will have a global pool of Discount Account Creation tokens that will represent the amount of discounted accounts that can be created. Every time a user creates a new account by paying a portion (or all) of the fee with RCs instead of STEEM, one of the tokens will be consumed. If there are no tokens left in the pool, then no additional discounted account creations will be allowed.

The number of new Discount Account Creation tokens created each day will be controlled by the witnesses. The reason that the supply of account creation tokens is entrusted to the witnesses is because they are incentivized to ensure that the rate at which new accounts are created does not place an undue burden on the blockchain.

The total number of tokens allowed at any one time will also be controlled by the witnesses. This is to prevent an excessive amount of tokens from accumulating if there is insufficient demand to use them up.

GitHub Issue 1770, GitHub Issue 2628, and GitHub Issue 2688

Stake-Based Discount Account Creation Market

In keeping with our preference to leverage markets to manage the complexities of resource allocation, the cost of creating discounted accounts (using RCs) will vary based on an internal market.

When the available supply of discounted accounts is low and/or the demand for them is high, then the amount of RCs that will need to be used in place of the STEEM account creation fee will be high. When the available supply of discounted accounts is high and/or the demand for them is low, fewer RCs will be needed to replace the STEEM account creation fee.

It should be noted that based on the supply and demand of available discounted accounts, it may only be possible for Power Users (those who hold a lot of SP) to be able to afford to create a discounted account.

GitHub Issue 1767 and GitHub Issue 1769

Burn Account Creation Fee

Instead of powering up the account creation fee to new accounts, it will be "burned" by transferring it to the null account.

GitHub Issue 1762

Deprecate Account Creation with Delegation Operation

After the Velocity Hardfork, it will no longer be possible to create accounts using a delegation of Steem Power, since the account creation fee will be burned. Therefore, the account_create_with_delegation operation will be deprecated.

Users will still be able to delegate SP to other users via the standard delegation procedures.

GitHub Issue 1760

Revert Modified Account Creation Fee

When we originally added support for creating accounts with delegated SP, we changed the way that the witness account_creation_fee was used to allow for a portion of the fee to be paid with a 5x delegation of Steem Power. With this change, the price of creating an account without delegated SP became 30x the account creation fee. For example, currently the account creation fee is 0.1 STEEM, and it costs 3.0 STEEM to create a new account.

Since creating accounts with delegation will no longer be supported, there is no longer a need for the additional complexity of multiplying account creation fees. We will be rolling back the change to multiply the fee by 30x. For example, if the witnesses set the account creation fee to be 3.0 STEEM, it will cost 3.0 STEEM to create an account.

At the time of the Hardfork, there will be a one-time, 30x change made to each of the witness’s account fees, so that the price of creating an account will not drop by 30x when the Hardfork occurs. For example: if all of the witnesses have their account creation fee set to 0.1 STEEM at the time of the Hardfork, they will all be changed to 3.0 STEEM when the Hardfork takes place, so that it will still cost 3.0 STEEM to create an account. After the one-time 30x update occurs, the witnesses will be able to update their account creation fees normally from then on.

GitHub Issue 1761

Dust Vote Threshold Changes

The Dust Vote Threshold is a rule that prevents the occurrence of extremely weak votes and was implemented to combat blockchain bloat. Currently, accounts must possess about 1 SP for a 100% Voting Power vote to successfully post to the blockchain. If a vote below the required threshold is placed, it is rejected by the blockchain. This can create a bad user experience for new users, as their votes can fail for seemingly no reason.

The Velocity Hardfork will change how the Dust Vote Threshold works by allowing users with any amount of SP to cast votes as long as they have sufficient RCs. Votes that are below the threshold will be posted to the blockchain but they will have no impact on rewards. This will allow users to have a better user experience on all Steem-based applications by enabling them to vote any time they choose (regardless of the size of their vote), provided that they have enough RCs.

This change will make very weak votes become worth nothing. In order to treat all votes (big and small) equally, all votes above the threshold will have the equivalent amount of rewards removed from their vote. This effectively establishes a baseline voting strength that applies to everyone. In addition to making it more fair, there is also the benefit of introducing a slight non-linear rewards curve at the lower end of the spectrum (to discourage spam), while still maintaining a linear rewards curve for votes above the baseline.

GitHub Issue 1764 and GitHub Issue 2515

Removal of the Minimum SP Power Down Restriction

Currently, accounts with less than 10x the current account creation fee (in SP) are prevented from powering down by the blockchain. This was designed to prevent people from creating new accounts only to immediately power them down.

After the Velocity Hardfork, the account creation fee will be burned instead of powered up to the new account. Because the new account will not be receiving any SP, there will be nothing to power down other than any SP the account creator purchases. For this reason, the 10x requirement will be removed.

GitHub Issue 1860

Curation Updates

30-minute Curation Window

Steem account holders (including bot accounts) are currently disincentivized by the Steem blockchain from voting on a post within the first 30 minutes. The earlier a vote is made within the initial 30-minute window, the less curation rewards the voting account receives. This was originally introduced to even the playing field between human curators and bots during a time when the majority of the content on Steem was long-form written content.

While successful, much has changed on Steem since that time. Steem now hosts all kinds of content, and powers hundreds of decentralized applications which dramatically expand the types of content that can be consumed on Steem. Because of this, the community and the witnesses have come to a consensus that the 30-minute rule is taking curation rewards away from human voters who are actively consuming content and voting on material they like. For this reason, the Velocity Hardfork will reduce the curation window from 30 minutes to 15 minutes.

GitHub Issue 1878

Self-Voting Rewards

According to the current blockchain rules, if authors vote for themselves immediately, they get their author rewards, 100% of the curation rewards from their vote, and a portion of the curation rewards coming from everyone who votes for the post after them. Any other curator voting at the same time as the author would get 0% of the curation rewards. This gives the author an unfair advantage over other curators, because the author can earn additional curation rewards through self-voting.

In order to eliminate this advantage, the portion of curation rewards that is not given to the curators due to the early voting penalty will be returned to the rewards pool instead of being awarded to the author, thereby increasing the overall percentage of rewards paid to curators. This will better serve the original mission of the curation rewards budget: to ensure that the Steem blockchain distributes rewards to the most valuable content.

GitHub Issue 1877

Expiration of Internal Market Orders

The current implementation of the internal market dictates that limit orders are never forced to expire. This allows users to submit orders to the internal market which require long-lived consensus bandwidth, degrading the overall performance of the blockchain. After Velocity, the blockchain will require that all internal market orders expire after 28 days. This is consistent with the implementation of order books on many of the major exchanges. Existing limit orders will have their expiration capped to 28 days after the Hardfork.

GitHub Issue 1449

Changes for Witnesses

These changes apply primarily to the witnesses.

Update to Witness Price Feed Format

The Velocity Hardfork will make an update to the requirements for witness price feeds. Price feeds will now require the base to be SBD and the quote to be STEEM. Price feeds that report the base as STEEM and the quote as SBD will be rejected.

GitHub Issue 409

Flexible Witness Parameters

A new witness_set_properties operation will be added. It will allow witnesses to update individual parameters instead of needing to do an update_witness call with everything all at once. The operation will support: account creation fee, max block size, sbd interest, signing key, and witness URL. Witnesses will also be able to submit price feeds using the new method.

This new operation will authenticate against the witness’s signing key instead of their active key. This means witnesses who submit their price feeds using the new operation will now be able to to submit them using their signing key. This provides a security benefit to the witnesses, since they will no longer need to store their active key on any of their servers.

The current witness update operation will remain functional, but new witness parameters will not be added to it. It is important for this operation to remain functional as it provides a method to update the witness signing key with the account's active authority.

GitHub Issue 352 and GitHub Issue 1620

Limit on Maximum Block Size

Witnesses will be able to set the maximum block size for blocks accepted by the Steem blockchain. The Peer to Peer (p2p) protocol, however, will have a 2MiB limit on the size of a block that the p2p network can process. Witnesses should not be able to set the value higher than what is allowed by the p2p network.

In order to prevent witnesses from allowing blocks above this 2MiB limit, we are adding a maximum 2MiB limit on the maximum block size parameter submitted by the witnesses.

GitHub Issue 1655 and GitHub Issue 2642

New Witness Parameters

Witnesses will have two new witness parameters to submit. The account_subsidy_daily_rate will control the amount of discounted account creation tokens that are added to the global pool daily. The account_subsidy_pool_cap will control the maximum number of discounted account creation tokens allowed in the pool. These values will be submitted via the new witness_set_properties operation discussed above.

GitHub Issue 1765 and GitHub Issue 2688

20 Second Comment Limit

The 20-second limit on comments will be removed as part of the Velocity Hardfork. The blockchain will now allow a new comment every block (once every three seconds), which is the same restriction placed on voting. Special thanks to community developer @mejustandrew for submitting the pull request for this change!

GitHub Issue 2019

Fix for Double Voting Exploits

Two users reported exploits where an account could gain extra voting power by using all of their voting power, and then delegating their SP to another account, or powering down and powering up again into another account. We will be including fixes for these exploits as part of Velocity. More technical details on the fixes can be found here.

GitHub Issue 2428 and GitHub Issue 2539

Decrease Delegation Cooldown Period

As part of the changes we will be making for the double voting exploits, we will be able to decrease the cooldown period for SP delegations from seven days to five days. This means that after a user undelegates SP from another user, it will only take five days for the SP to return to their account and become available for use again.

Increase Account Voting Power Precision

As part of the fixes we are making for the double voting exploits, we will also be increasing the precision of voting power (now voting mana). This will increase the number of votes that an account can make with less than 2% voting power, since the blockchain will now be allowing more granular votes.

GitHub Issue 1808

Minimum Account Usability

Even though the account creation fee is burned, accounts created after the Velocity Hardfork will still be able to transact with the blockchain with zero SP, because the burned SP will still be counted towards their RC balance calculations.

GitHub Issue 2488 and GitHub Issue 2595

Upvote Lockout Period

In Hardfork 17, a change was implemented to prevent upvote abuse by creating a twelve-hour lock-out period at the end of a post’s payout period. During this time, users are no longer allowed to upvote the post. This prevents users from hiding a self-vote at the end of the payout period and exploiting the rewards pool. However, users retained the ability to downvote as a safeguard against the scenario where a user self-votes immediately before the beginning of the 12-hour lockout period. Though uncommon, this created an opening for malicious users to wait until the lockout period to issue punitive downvotes so that they couldn’t be countered with upvotes.

Velocity will address this potential scenario by modifying the lock-out to a cool-down. After Velocity, upvotes and downvotes will both be allowed during the last 12 hours of the payout period, but their strength (for the same amount of voting power) will decrease linearly from 100% to 0% over that 12-hour period. In other words, it will take twice as much voting power to have the same impact on a post’s payout if the vote is done with only six hours left on the payout window instead of twelve. An upvote or downvote cast during the last minute would have virtually no impact on a post’s rewards.

This change will help ensure that no matter when a post receives an upvote or downvote, users will be able to counter-vote. This will also help to stabilize the potential payout of posts during the last 12 hours by decreasing the strength of votes as it gets closer to the payout time.

GitHub Issue 1267

Steem Blockchain Dollar (SBD) Changes

Community developer @timcliff submitted two changes to update the logic for Steem Blockchain Dollars (SBDs).

Update SBD Print Rate

In Hardfork 14, rules were added to reduce the SBD print rate when the “debt ratio” (amount of SBD tokens in existence / the STEEM market cap) was above a certain percent.

Under the new rules, SBD tokens will continue to be printed unless/until the debt ratio reaches 9% of the STEEM market cap. Between 9% and 10%, liquid payouts will shift linearly from paying 100% SBD and 0% STEEM at 9%, to paying 0% SBD and 100% STEEM at 10%. This works the same as the shift that occurs today between 2% and 5%.

GitHub Issue 2140

Reward Beneficiaries Paid Based on Author Setting

When an author chooses the “50/50 payout” on their post, they will receive 50% of their rewards as SP, and the other 50% as “liquid payout”. The liquid payout is typically in the form of SBD, but it will sometimes pay a portion (or all) in liquid STEEM if the debt ratio is sufficiently high. The author also has the option to select being paid 100% in Steem Power.

Currently, if an author adds beneficiaries to their post, the beneficiaries will be paid in 100% Steem Power, regardless of which selection the author made for their rewards. After Velocity, beneficiaries will be paid using the same payout setting as the author.

GitHub Issue 2022

Miscellaneous Changes

Support of BIP-0062 Canonical Signatures

To solve transaction malleability, Steem enforces “canonical” ECDSA signatures. The canonical ECDSA signatures that Steem uses are a subset of a more widely used BIP-0062 canonical signature system.

We will update our canonical signatures to use the BIP-0062 method, so that our signatures can be more easily understood by outsiders, and to make integration with the Steem blockchain easier for third-party developers who may be reusing code from other blockchains that use the BIP-0062 method. This also opens up the rest of canonical search space, which increases the entropy, and therefore security, of our signatures.

GitHub Issue 1944

Mined Accounts

Velocity will not support the creation of accounts via mining. Instead, Velocity will include the changes necessary to enable account mining on Steem via softfork at a future date. The reason for this is that the many attempts at “ASIC resistant” algorithms have failed to curb ASIC implementations. Until we can come up with a reasonable PoW scheme that is accessible by end users without being easily exploitable, we felt it would not be a good idea to include PoW for account creation. We decided it was much more important to get the Velocity Hardfork completed and add support for discounted accounts ASAP. Since the feature can be added at any time in the future without a hardfork, we have the flexibility to add it once we find an acceptable algorithm.

One of the main things that will be changed in Velocity so that mined accounts can function properly once implemented, is preventing mined accounts from having a default account recovery partner. Because a second-party is not involved in the account creation process, there is nobody to designate the account recovery to if the account is stolen. If a user with a mined account wants to take advantage of the account recovery process, they can designate a willing party as their recovery partner after the account is created.

GitHub Issue 1782

Modernize Schema

These are highly technical changes to improve the maintainability of the Steem code base. Those interested can read the details in the corresponding GitHub links.

GitHub PR 2692, GitHub PR 2693, and GitHub Issue 683

Fix Error Message Typo

Community developer @arcange submitted a change to fix a typo in the error messages that are returned when certain API calls are made without a proper number of accounts. The error message now correctly reads at least one account must be specified.

GitHub PR 2673

Remove Challenging Authorities

Challenging Authorities was a system devised in the summer of 2016 that was never fully released. The proposal would enable a user to pay a small fee to challenge the authority of another user— forcing them to sign a transaction with a higher level authority to prove they continued to have control of a key. Were this feature implemented, it could have led to a scenario where an innocent account holder was forced to remove their keys from cold storage by a malicious actor. For this reason, Velocity will remove the extraneous code related to this feature.

GitHub Issue 1848

Testnet

We will be launching a Velocity Hardfork testnet prior to the mainnet Hardfork date, which will give developers the opportunity to test the upcoming changes in a non-production environment prior to launch. We will provide the details on this testnet once it is ready for public use.

Schedule

A majority of the development for the Velocity Hardfork has been completed and can be reviewed under the project/hf20 tag in the Steem GitHub repository. The issues are also being tracked via our project board here.

The Hardfork is scheduled to take place on Tuesday, September 25, at 11:00am EST. The changes in the Velocity Hardfork are dependent on the approval of a super-majority (17/21) of the witnesses voting in favor of the Hardfork.

We will be tagging the Hardfork release on or prior to August 25, which will give witnesses and node operators at least 30 days to review and test the changes, and apply them to their nodes prior to September 25.

We are confident that these changes will be major improvements to the Steem blockchain, making Steem even better than before.

Steem on,

The Steemit Blockchain Team

Sort:  

Hey, @steemitblog, et al.

So, first of all, like many of the commenters have and will continue to do, thanks for the heads up on the Hard Fork update. This is a worldwide system, so I'm guessing that the 11 AM EST time on a Tuesday is the optimum time to do this?

One other thing. Why the change to 9% rather than the 2-5% for SBD printing. I understand we're at or near the 5% now. This feels a lot like the upping of the debt ceiling the US does constantly to allow more spending on borrowed money. I'm just wondering what the reason is, what's the rationale, and whether or not it's an appropriate thing to do given the safeguards that were originally in place. In other words, what has changed (other than the debt ratio reaching 5%) that will make this change better?

Thank you for the ongoing updates this year, and for informing us of these upcoming changes. I hope all goes well with the implementation of the HF, and that all functions as intended.

The purpose of the change was to allow for the creation of more SBD to hinder "pump" attempts that raise SBD beyond it's intended peg value of $1 USD. But it's important to note that the increase in potential SBD doesn't risk the sovereign debt problem that the US has: the STEEM blockchain is designed to linearly stop honoring the ability to convert the SBD to Steem at the rate of $1 worth of Steem when the debt ratio goes above 10%. Think of it like a built-in promise of the Steem blockchain to hyper-inflate SBD's value vs Steem during the period that "too much" SBD is in circulation.

Hey, @blocktrades. I appreciate the response here.

I was aware of the failsafe for SBDs, so that's good to know that this isn't something that would somehow override it.

Okay, so allowing a higher percentage of debt essentially hinders pumps on SBD because the price drops with more SBD in circulation, so to speak? Or is it the opposite. This is where it gets a little murky for me. The whole idea of having a stable token that is still publicly traded and thus open to speculation.

The intent of SBD is not that it be 'open to speculation' other than speculation within a narrow range and relatively short time period due to liquidity considerations (with enough volume, a speculator can make a large amount of money betting that SBD at $0.99 will rise to $1.01 or vice versa). Instead of a speculatively determined price, increased demand for SBD should result in more SBD being circulated and decreased demand for SBD should result in less SBD being circulated, in both cases pushing the price back toward $1.

The current mechanism doesn't fully implement this but that is the intent, and the proposed change gets a bit closer while removing an odd quirk how the thresholds are currently set: between 5% and 10% there is literally nothing being done by the system to control or even influence either the supply or value of SBD (none of it being created nor destroyed, backing ratio not affected, etc.). No one really intended to create a market cap ratio 'window' for fully-free-floating SBD with no controls at all; it seems to have been an accident.

EDIT: @timcliff in his reply also noted some other perverse effects of the mechanism of shifting payouts from SBD to STEEM, which are good points too. By reducing size of the range where this occurs those effects are reduced, which is good. (I, and numerous other stakeholders and witnesses, would like to see more done, but this is a great start and kudos to @timcliff for getting it implemented and scheduled for the hard fork.)

Hey, @smooth. Thanks for this. I'm learning a lot from you all today. :)

Okay. So, a void or limbo area was created unintentionally between 5-10% so that whatever is suppose to happen (create or destroy SBD) happens. Sounds like a great idea to me. So, basically this was unknown until the current situation revealed it, then, if I'm understanding correctly.

Yes, that is one of the reasons I have supported this change. In his reply @timcliff noted some others. Generally speaking we want SBD to work better and add value ('value' here referring both to utility for users and capital attracted to the ecosystem i.e. higher STEEM price), and we believe this change helps do that.

This looks dangerous to me and I think the comparison to raising the US debt ceiling by @glenalbrethsen is a valid one. It was certainly the first thing to come to my mind when I saw it.

To me this is a bandaid solution and all we're doing here is kicking the can down the road. We are going to have an illusion of normalcy up until 9% and then at 10% we are suddenly not just getting a printing halt, but also a haircut on SBD conversions that I think could be potentially disastrous for confidence in SBD value being held at $1. What is being put in place here is a virtual cliff for the lemmings to throw themselves off.

I don't think the current 'void' between 5% and 10% serves any useful purpose and it is clearly destabilizing to remove all supply or price influences on SBD within some fairly arbitrary range.

Apart from that we could quibble about exactly how things should work, like maybe the ramp should start a bit lower than 9%. But overall I agree with @blocktrades that the real debt control and safely value comes from the 10% limit, not this one, and I also agree with @timcliff that printing STEEM instead of SBD* is not useful because it just serves (all else being equal) to drive the STEEM price down, when the STEEM price being weak is the main reason the limit has ever been hit (multiple times now).

After all, even with the current 2-5% there is nothing to prevent STEEM from dropping another 50% in value after the 5% is hit and then we are right at the 10% anyway. 50% is hardly even a big move in crypto terms (we've already seen STEEM lose 90%+ of its value two or three times). Hitting 10% and risking the haircut is always in the equation, regardless of the printing rules. SBD holders should be aware of it and consider it rather than assume it won't happen.

One last point. The haircut doesn't kick in instantly it gradually phases in. So at 10% there is no haircut. At 11% there is roughly a 10% haircut, etc. There will be plenty of opportunity to see this play out and I'm sure even before 10% is reached, as it is approached there I'm sure there will be posts warning about SBD potentially becoming less-than-fully backed, and people who don't want that will have the opportunity to sell or convert their SBD (which may itself help resolve the situation). There's nothing sudden about the transition.

* An alternate rule we might consider (but I'm sure very few people are interested because everyone wants their 'free money') would be to stop printing rewards altogether when the debt ratio gets too high (rather than switching from printing SBD to printing STEEM), as this could be taken as a sign that the market is not valuing STEEM enough for it to be a good idea to continue diluting it.

If PoW is implemented in the future like the article suggests then all of these issues will be solved...in my belief

Oh that's an awesome upgrade :D

Hi @glenalbrethsen. Just to clarify, in terms of the "debt ceiling," the closest thing to that with SBD is the "10% limit" on the debt ratio. Basically what that does is that no matter how much SBD is printed, it will never be allowed to exceed a debt limit of 10% of the STEEM marketcap. SBD will just become redeemable for less than $1 USD worth of STEEM, instead of taking on additioanl debt. Based on that, the safety of how much debt the Steem blockchain takes on (in the form of SBD) is not changing.

What we have seen under current market conditions is that there is still a high demand for SBD (the price is consistently above $1 USD) even though the debt ratio is above 2%. What is happening under the current rules is we are printing less SBD, even though there is still excess demand. This change addresses that by allowing more SBD to be printed.

Another negative impact under the current rules is that it is printing more STEEM (instead of SBD). This means we are seeing additional (unnecessary) downward pressure on the STEEM price, when we could just be printing more SBD instead of STEEM.

The last thing to point out is that the current system is missing out on the best opportunity to use SBD to it's full advantage. When the STEEM price is at it's lowest is really the best time to print more SBD, because if you assume the price will go back up - then the blockchain ends up getting a 'discount' on how much STEEM needs to be created. For example, if $100,000 USD worth of SBD printed today when the STEEM price is around $1.00, it would only need 1/5 the amount of STEEM if the SBD was not redeemed for STEEM until the price of STEEM goes up to $5.00.

Technically the same mechanism works in reverse. If we print a bunch of SBD when the price of STEEM is at $5, and then the price drops down to $1, we have to print 5x as much STEEM. If we allow the debt ratio to get much closer to 10% though (by allowing printing all the way up to 9%), then it reduces this effect. A significant price drop in STEEM will not result in as much STEEM being printed if the debt ratio was already close to 10%, because it would be capped once it reached the 10% limit described above.

Hey, @timcliff. Thank you for answering my question on this. It's been extremely helpful.

Now, what I'm wondering is, are we in some kind of market period where STEEM hasn't been before? I guess I'm wondering if it's known that 9% is the better debt ratio than 5%, why wasn't it lifted before this? And what happens if 9% doesn't prove to be enough for whatever reason?

My guess is, either this kind of market conditions have been here before, but it didn't last long enough to get a change made but it's been sitting on the back burner, or it is new, and based on whatever criteria, it was determined the raise should take place just in case the current situation was prolonged, or came back again at a later date.

You are correct. The situation of SBD being overvalued while the printing limits are being hit has not really happened before. It did happen very briefly in 2017 but quickly went away on its own.

However, the overall goal is not so much to react to one particular market situation as to structurally improve SBD so that it works better and adds value to the Steem platform. The changes were actually implemented and merged into the code before the current market situation occurred (though it had been recognized and anticipated).

These are improvements which have been considered and discussed for a long time and are only now getting rolled out because: a) this is the first hard fork update since early 2017, and b) it took a while to both reach consensus among witnesses, stakeholders, and developers about what to implement and then get them implemented.

Okay. Very good. I'm not sure how anyone else feels about consensus making, but I'm alright with it taking a while. If the required majority gets there through taking the time to deliberate and observe, better decisions get made.

It's interesting to note that this will be the first Hard Fork I'm a part of, along with everyone that has come in since the last fork, which is the vast majority of the accounts, and probably most of the daily user base still here. After 19 happening in less than a year if my math is sound, that seems to make this one that much much anticipated, especially when you add on what is expected to arrive later with Hivemind/Communities and SMTs.

Thanks for all this. I feel like I understand why this is going to happen and the reasoning behind it. I hope it, and the rest of HF 20 goes as intended, or at the very least (since there always seems to be something), keeps pushing us in the right direction. :)

Well the main risk is that we see the opposite of what has been happening with SBD, and there is insufficient demand for it. We have seen that before in the earlier days of Steem. Under that scenario, then market conditions would push for SBD to be converted into STEEM, which would reduce the SBD supply.

It sounds very drastic, but the absolute worst case scenario is that the SBD peg would break in the negative direction, and SBD would be worth less than $1. At that point, it would be up to the market to determine what SBD would be worth.

very good presentation, we hope that content creators related to the price at the crypto market, hopefully the price can go back to strength. this greatly influences our enthusiasm in creating valuable and worthy content

Okay. I think I'm getting this. This is basically a change to help ensure the SBD ratio is maintained within favorable parameters and that it continues to bolster the peg, as it is worse for SBD to break the peg in a negative direction than it is to do so in a positive.

Well, the peg is already 'broken' in the positive direction. There are not really sufficient mechanisms to push the price back down to the peg when it goes up. The changes being discussed here are all intended to help push the peg back down.

Okay. Very good. I feel better now. :) I appreciate the time taken by you and others to explain things. May it all go the direction we all hope it will go—for the betterment of the STEEM platform.

Apologies sir, i have wrong button press downvote 🙏🙏🤦🏿‍♂️

@glenalbrethsen so sbd won't be higher than 1$ or less than 1$. is this they trying to fix..

Hey, @lelong.

The short answer to that question is probably yes, in theory.

Longer answer is, it's not like they can fix it to any one price point, though. They're doing what they can, but the market is still going to decide what SBD does, even with this code change. Sounds like they're mostly concerned at this point with SBD dropping below a $1, too.

Excellent points I think I follow you here @timcliff. Right now there is an underflow of SBD within the economy and perhaps not coincidentally there is a very very low rate of interaction on here right now with the users across the board. Honestly there really is no way to deny that even with the intentional decrease in supply it has brought steem value's down significantly by price and additional quantities paid out in steem per post--which is the exact opposite intention it was created. Getting to the SBD payouts in posts, if I do not buy anything that really requires me to use SBD (for example bid bots which have basically become the engines that fuel SBD consumption in the economy really at all and are a virtual surefire losing bet right now) why would my post payout be tied and beholden to SBDs? I get the relief they bring in having to produce additional steem in the event of price crunches but isn't this one radical turn from one direction to offset the other? With the ability to overflow the system with up to 4.5 to 5 times more in supply as of say right now isn't that a concern? At $5 steem that isn't much of an issue but what if whales that are unloading truck loads of steem right now keep doing this at prices even below $1 when this fork comes out? SBDs will become an extinct medium of exchange very fast on here for sheer worthlessness.
A very overachieving, proactive approach at this fork would have been having smart tokens ready to launch and take our chances with them working out desired effects that we hope they do in helping reflect the many varied interests of our economy here on steemit. It would seem to solve a lot of this angst that is going on within the community, but it is not even mentioned on this announcement. I hope to avoid sounding like Captain Hindsight, but here we are and we have what we have moving forward. Are we supposed to believe that continuing to bail out the bid bots massive losses since sbds/steem has plummeted and votes are more and more worthless that continuing to fund this losing endeavor with more of the same is a legitimate response to curing these ills? If I were manipulating prices of steem/sbd I would be terrified of a smart token, because now I have to track 10,000 tokens day one when they are able to be implemented and find which are good and which are worthless. Also in the meantime finding out what they are being used for and whether it's worthwhile to follow or not. That is a lot and I would love to hear your response here, I certainly am not venting this all in your direction but to the debate at large and what can be done, and preferably not pushed down the road by a CEO that is currently unloading their stake in the company at two year lows in prices at best.

As far as the smart tokens you are referring to, they sound a lot like what they are planning for SMTs. What are your thoughts on those?

They are incredibly promising. Having the dynamic of getting payouts with them within communities/groups you choose to affiliate and have closer control on how the tokens are issued and how value is created is incredibly intriguing. Having them issued at a customized mode, whether it be in curation rewards or simply upvoting a vested member in a group could go a long way in maintaining and building membership here. It's all future projection of course, it really depends on how they are understood but it does really reward the people that do a lot individual community based activities.

What happens if we reach the 10% doubt ot ownership ratio and the STEEM price drops, let's say, a 50%? In this case the ratio will increase to 20%. Which are the mechanisms to regulate it again?

Interesting comparison Glen!

Hey, @ecoinstant.

I'm going to guess you're talking about the comparison between the lifting of the debt ceiling the U.S. Congress loves to do periodically and the lifting of the 5% SBD debt ratio to 9%?

If so, I thought it was too, but the major difference is, the ceiling is 10%, and will remain that way, according to everyone who answered the question. Which is good. We don't need to be jacking that up.

Well, they might have said that at 5% lol.

All they need to do, like congress, is vote again. I do think there are some technical differences, we don't need the debt to pay anything, all we are doing is balancing the markets between debt instrument and token. No body can foreclose on us if we don't pay our debts, for example.

But I still think the analogy is apt.


By the way, I noticed you changed your vote on my comment. Not a big deal, I mis-vote all the time with those goofy sliders, especially on mobile. But did you know that you don't get the voting power back? You actually spend vp for both votes, and just burn the first vote. Just something I learned, and I post it here with all these tech guys hoping that if I am wrong they will call me out!

Love and Light Glen, I always love seeing you around, I like that you try to get to the bottom of things, not a yes-man, but a ask another question man!

Yeah, I've been noticing that myself with the upvote. I should have just left it. I mostly have an issue when the system is glitching and it tells me I have to re-sign in to vote. Then it jacks the slider up to 100% and votes that way without allowing access to it until after the vote is made.

re: said that at 5%.

I was kind of feeling confused myself, about that, but apparently there's just things they find out about as things unfold. It seems a little disconcerting to me, but it's hard to tell sometimes what I should be worrying about and what I can just let ride.

re: vote again

I also thought of that. Is there a market where that might be favorable, or at least considered? I guess we'll find out down line. Whether it has any repercussions or not, why set any parameters at all if it's no big deal to just raise it?

re: not a yes man

Well, I appreciate that. I'm getting too old and grumpy to take things at face value, though I do prefer a civil conversation over a finger pointing contest. It just seems to get more accomplished, and when I have more questions later, they tend to get answered.

I get concerned that in our desire to be transparent and decentralized that we're needing to worry about a great many more things than what we really want to. On the other hand, if this is to be some form of governance for the blockchain, than we all need to be aware of what's happening, and at least attempt to understand it.

Hey that has happened to me! I know exactly what you mean. I have been switching to steemitstage.com when it gets really bad, two nights ago it was pretty terrible. I think this must be server load on the front-end.

I do think parameters are important, because most of what happens is automated. But, I think I read timcliff say that it is better to issue SBD type debt when steem is cheap, because we only need to pay back each one with a dollars worth of steem. So if it goes up we can pay it back with less.

I'm not really worried about it, I think 10 percent is still pretty low for such a useful token. But I really like that you are there poking them about it! Debt is a tool, if used right you can avoid hurting yourself.

I agree what you say, we have a much greater responsibility in a decentralized system!

Cheers Glen :)

we live - we learn
thanks

Oh the debt ceiling in the US, don't worry about that, it's just a number of absolutely zero consequence. LOL if only on steemit we could get away with what is gotten away with there...

Hey, @cryptkeeper17.

I'd like to be able to get away with it in my own pocket book.

No money? No problem. I vote to raise my own personal line of credit. Of course, I'm good for it. I'm me!

If only, but don't forget to also vote yourself a raise first.

Man. It's amazing the United States is still standing and at the very least, a facsimile of a sovereign nation. I guess the fact that the exact same thing could be said about virtually every other nation is what's saving our collective skins. We just keep passing the buck around like a hot potato.

There's so many things that Congress gets away with that we can't. Set your own raise. Blank checks. Insider trading. Unless you tell your family members, then it's a no go.

USA has less debt per % if gdp then China Europe or Japan so it’s not a USA problem but the whole globe

Those changes were submitted by @timcliff and approved by the witnesses. He will have to speak to the intent behind these changes. I can only speak for myself when I say that it's great to see a community-member PR acquiring consensus among the witnesses and being scheduled to be added to the protocol.

Cool, @andrarchy. Tim's been good at follow up so I'll see what he says. And I agree, it is good to get some consensus on any level, especially from the community and the witnesses. The more proactive we can be, the better.

11 AM EST time on a Tuesday is the optimum time to do this?

You can never satisfy everyone on a global system. One of the requirements of a witness or even developer role on such a system is the necessity for a certain amount of 24 hour availability. 11 am on Tuesday is okay for US and Europe but pretty bad (early to extreme early morning) for most of Asia. Making it later helps with Asia but hurts Europe. There is no perfect time.

Okay. Pretty much figured that to be the case. I was looking at it, of course, from the user standpoint, but that's obviously not the only consideration here. You've given us all a decent amount of heads up, though.

Since I've never been through one of these before, is there any expected amount of downtime at all? Or, if everything goes according to plan, do we just all keep working as it rolls out?

In a normal update there's usually the time it takes for that to happen. With a hard fork on a blockchain, though, it sounds like things keep rolling as you go?

If everything goes according to plan there should not be any downtime.

Looks like there are some good changes that will be implemented. I'm especially looking forward to having the curation window shortened as things move quickly. Honestly, with the amount of short-form content on Steemit, a 5-10 minute window would probably more appropriate, but maybe it will take more time to convince the powers that be. It's at least a step in the right direction to giving more curation rewards to the curators.

Agree with you on the time window. The original suggestion from @blocktrades was to reduce it to five minutes, which I personally would prefer (if not shorter). However, this is a step in the right direction which addresses some concerns about making too extreme of a change and causing new problems.

I also think the original goal of addressing bots and autovoting is less needed now because there is so much more content. Originally it was quite possible for bots to instantly vote for all of the (five?) very popular posters and grab all the rewards (with superlinear rewards concentrating things even further). Now that is no longer the case, rewards are much more spread out and with limited vote power, deciding what to vote for is relatively more important then getting in instant votes.

I hope once we evaluate the effects of changing it from 30 minutes to 15 minutes we can consider further reduction.

Thanks for the feedback.

I am happy to see the reduction in the time window, however I would hope we could move towards the removal of it eventually. It does seem like it is a solution to a problem we no longer have(too many curators/bots, not enough content) and probably just over complicates the user experience now. I think it is important to not underestimate the negative effects of a mechanism which complicates the user experience and potentially adds a barrier for profitable curation. Personally I wonder if we could return to the no reverse auction , 50/50 split for rewards. It is much easier to explain and comprehend and I think it would help to reincentivize good curation over for profit self voting.

I see some value in a very short window. With no window you can have a rush of bots all flooding to get in the very first block of certain known-to-be-popular content, which could be viewed as a sort of unintended denial of service attack. A ramp that forces bots to pick what each believes to be the optimal time over a short window rather than all trying to be first at the exact same moment may be better for purely practical reasons of spreading out blockchain load.

But IMO this should all happen over bot timescales (something like 15 to 60 seconds at most) rather than human timescales, and ideally can be ignored by human curators rather than introducing the whole 'optimal time to vote' complication as is the case now.

Removing it entirely as you suggest may also be okay though.

I was thinking about suggesting the removal of the voting time as well, but like you said, if you remove that, the bots will have a huge advantage over the human curators. I've had GINAbot tell me that someone voted on my new post before it even told me that I had created one. The goal should be to leave a small period of time to let the humans get some curation, then open it up for regular votes and whatever else.

Thanks for sharing your thoughts. You've been around for a while and seen a lot of the changes, so you have a unique perspective on how to make it work well.

I wasn't around for the superlinear rewards, but it sounds like it was a whole different ballgame.

with limited vote power deciding what to vote for is relatively more important then getting in instant votes.

Also there are a lot fewer votes that we get per day this is even more important than "back in the day."

There probably won't be a system that is entirely fair. And there probably won't be a way to keep those who want to abuse the system from doing so, but we can try to make it a good overall experience for most people and we'll be doing fine. We're still making more money posting here than they are over on facebook. :)

This news made my day! Thanks for all the hard work you guys are doing for us!

I like the new witness_set_properties operation where we can use the witness signing key. However, on a multi-server setup, each server has a different key pair, so it may not be practical. For example:

  • server 1 fails, use its signing key to enable server 2 to take over
  • after fixing server 1, will have to use server 2's signing key to re-enable server 1.

Annoying, but can be circumvented with a script that fetches the public key on the blockchain and use the corresponding private key.

It would be preferable to have a new key role dedicated for witness operations, this would solve all the problems.

I’ve read somewhere a while back that new key authorities are expensive (as far as development time and complexity) to implement. If it can be solved by witnesses spending a few hours coding their scripts to handle it, that is probably the most practical way to go.

Have to agree with @drakos.

If I understood correctly, the action has to be confirmed with the private active signing key, which varies depending on the active signing-key.

That would require an additional fetch of the active public signing-key. Maybe it would be better to add the signing key as optional or create a separate key for updating witness-data.

A separate key for updating witness-data would be nice. With this set up, we would need every server to have access to every signing key, which is not ideal. One of the points of separate signing keys is to ensure if one server ever got compromised, witnesses could quickly switch to a different signing key and never use the old one again.

Either way, getting access to a signing key and being able to tweak witness parameters is less dangerous to the individual witness than having access to their active key, so overall applaud the change.

Exactly @lukestokes. And actually, it would be quite useful to have different keys/authorities for different dApps. So instead of creating a special witness key, it would be the smarter way to create a general way of adding 3rd party authorities.

Looks at the summary
Looks at the current cryptomarket
Brb buying the dip.

I guess you could say BTFD

P.S @coinbros are on steemit !!

That's more news of nothing to really change that matters to the value of STEEM.

Posted using Partiko Android

If you think that these changes don't matter to STEEM, I would suggest that you don't know all that much about STEEM.

Yea...I don't.

Posted using Partiko Android

Yea...this is definitely gibberish to me.

Posted using Partiko Android

Well, easier and faster to make new accounts. That is a huge complaint and bottle neck right now. This is the most important and massive change that will affect all of us inviting our friends. The RC changes change a lot actually, but onboarding new users is huge.

Lowering the time between comments.

Tinkering with curation rewards, SBD limits, delegation cooldowns, okay I get that maybe none of the rest is life changing for your account.

But its big news, let me tell you ;-p

I don't understand the need to make multiple accounts. I've been squirming around here for a year.
Don't see the purpose of making multiple accounts.
I see where you're coming from.

Posted using Partiko Android

Maybe your friend or brother or lover or uncle or neighbor want an account too? A new account has to be created for them unless you are going to let them use yours. In the current system, someone has to pay! This takes time, people complain.

Now, its faster, less costly, and more people can make accounts! This drives up the demand for steem, causing even more people to want to make accounts!

I am also not up on this and don't really understand this post. When I came here in June 2017, I did not pay for my account. Nor did anyone else I invited in the last year. Has something changed now that makes people pay to get in? All of the content creators I invited have left and I have stopped trying to get people here now, but you never know.

How much more gibberish will the creators of this concoction create to make it more useful to the everyday person?

Posted using Partiko Android

Hey Tony! Feel free to come back when you find it useful! I already find the free hosting, built in monetization and uncensorable permanancy of the blockchain with 3 second transactions and zero fees to be very useful!

Dip below $.90 before HF 20 and it's going to be a great 4th quarter.

Posted using Partiko Android

15-minute Curation Window is really good. A person can read the article in 5 minutes and he/she can upvote it in 15 minutes.

Not to get ahead of ourselves... but any hints on if changes to Condenser (Steemit.com) may be in line to follow the hardfork fairly quickly? In particular, I just think a visualization of the RC system and usage will be critical to limiting user confusion and making the change a very positive one. Most new users will be largely unaware of any outside reporting tools that may develop and could grow frustrated as their actions slow or cease altogether.

Good point. Many other Steem related sites show bandwidth indicators today. Maybe showing various "mana" indicators for these new limitations would be helpful on Steemit.com as well.

This looks like a pissed off, grumbling face above the Hardfork logo...

pissed.JPG

Please don't do negative foreshadowing. Or is this some kind of a joke of your graphic designer?

Huge changes here, and big kudos to how clearly and methodically this post is laid out~ for those wondering what the hell a Velocity is, this is the perfect comprehensive guide. The extra security and nit-picky control over witness parameters and smaller vote accuracy are both things that I personally really hoped would be addressed.

Onwards!

Owuya! Ozo abiakwa la. Ngwa Daaalu nu o! From nwa afo Igbo ogoowinner.

Hahahahahaha!

ana me kele o....! :-)

Lol, igbo representing...ya gazie

haha i love this.

Nne ima ife anaru!