Proposing Hardfork 0.20.0 “Velocity”
HF19 Success!
In Monday’s @steemitblog post we announced the impending adoption of Hardfork 0.19.0 by the Witnesses. We are happy to announce that this transition occurred successfully and all Steem users are now posting to the new-and-improved Steem Blockchain! All Steem rewards are now being distributed to content creators based directly on how much Steem Power they have (i.e. a linear relationship). It is no longer the case that a user’s influence is exponentially related to the amount of Steem Power they hold, making the Steemiverse a more fair and equal place.
Another Successful Hardfork
HF19 marks our 18th successful hardfork. While we have a deep respect for all the great projects in the blockchain sector, we are proud of the unique attributes of the Steem Blockchain which enable us to upgrade its features, and make it more valuable, so rapidly and safely. As far as we know, we are the only project to intentionally and successfully navigate a hardfork without creating an additional blockchain, let alone 18 hardforks! Thanks again to all the Witnesses who helped make that happen. Now that we’ve successfully implemented HF19, it’s time to propose the next Hardfork, codenamed “VELOCITY.”
Proposing Steem Velocity 0.20.0 as the Next Fork
In our 2017 Growth Plan posted 2 months ago we listed our 3 priorities: Communities, Effortless Onboarding, and a Mobile Application. We are extremely happy with our progress on all fronts. Our team of world-class developers have been working around the clock on all of these features and so we are excited to begin revealing the fruits of their labor with 0.20.0. The focus of this hardfork is on improving the process of account creation and reducing the friction involved in onboarding millions of new users.
This proposal addresses some on-chain issues to support signup improvements on Steemit.com and other sites to bring more users into the Steem ecosystem. As with the proposal for Steem Equality, these changes go together. Please view the proposal as a whole rather than individual parts. This is a complete rework of how account creation currently works on Steem, designed to help streamline the onboarding process for all Steem developers and improve the scalability of the Steem Ecosystem.
Burning STEEM for Account Creation to Prevent Abuse
A significant practical problem we have experienced with account creation is automated abuse of the signup process to yield free STEEM to attackers. This increases the average cost of legitimate account creation, making the Steem Protocol more expensive and less attractive to developers and potential partners. Presently, each new account is required to be funded by the account creator with initial Steem Power. The original reason for this was to give each account the requisite minimum Steem Power needed to transact on the blockchain. However, a side effect is that when a user fully powers down, they are temporarily locked out of their account. People need to be able to cash out without being at risk of losing access to their account.
The current system also incentivizes attackers creating multiple accounts in order to acquire free STEEM, which again increases the overall cost of maintaining the protocol. To solve this problem, we propose a new method of burning STEEM (i.e. destroying the tokens and removing them from the token supply) on each account creation and crediting the account with permanent minimum bandwidth instead of providing Steem Power to the new account. This will reduce incentives to abuse the steemit.com signup system and will prevent users from temporarily preventing themselves from transacting after powering down in full.
Discounted Account Creation
One of the key areas limiting growth of Steem is the cost of creating accounts. We want to grow Steem to at least to size of Reddit, hopefully larger. Reddit currently has 234 million unique users a month. Let's assume that if they have a 50% retention rate (quite generous), then they would have signed up 468 million accounts. If we wanted to do the same then it would cost 93.6 million STEEM ($187.2 million at the current price) and 13.5 billion Steem Power in delegations. The current STEEM supply is only 250 million STEEM. With the stake that Steemit has, it would take nearly 12 years for us to create those accounts and undelegate Steem Power continuously to reach those numbers. Simply put, it does not scale and if we want to grow to become the disruptive technology that we all know Steem is, we need to remove this barrier.
We want to add a daily quota of discounted accounts. These accounts can be paid for with a combination of STEEM, bandwidth, and mining. Yes, mining. We believe that the ability to mine an account into creation was a fantastic feature of our hybrid proof of work system that was lost when we removed proof of work. Mining will use Litecoin's scrypt algorithm as it is battle tested. This will only be used for creating accounts through the discount system and not for block production.
The level of discount will be dynamic based on current demand to prevent all of the accounts from being created instantly. Witnesses will vote on the daily quota so that we can scale this system alongside our growth. This system will run in parallel to existing account creation.
Remove Account Creation with Delegated Steem Power
The original intent of this feature was to allow bulk account creation without account creators spending a lot of STEEM. Discounted account creation solves this in other ways and does it better, it makes sense to remove this feature. Accounts will still be able to delegate Steem Power to others, just not as an integrated part of account creation.
Remove Vote Dust Threshold
The vote dust threshold was added last summer as a countermeasure to automated spam of extremely small votes. While it served an important purpose at the time, the feature interferes with the ability for new Steem users to participate in the community and build a following. The dust votes did not impact rewards significantly, but were taking up valuable space in the blockchain. The true issue was in the bandwidth algorithm, which has been updated to prevent this attack. Because accounts will now be created with 0 SP, their initial votes will not be worth anything. Removing this threshold will allow those accounts to interact with others on the blockchain while they establish themselves in our community.
End User Impact
We understand that this change is nuanced and has many moving parts, but we believe the end implementation will be simple to use. As mentioned previously, end users will not need to fully understand this system to use Steem and only those interested in creating accounts will be affected. Below is an example of what creating an account would look like under this system.
We expect the majority of accounts to be created by Steemit and our partners cheaply using stake. The account creation process will appear similar to what it is today with a fee and proof of work field. To create an account via stake, all the creator needs to do is not include a fee or a proof of work. If the creating account does not have enough stake they will need to include an adequate proof of work or STEEM fee to cover the difference. We will provide APIs and tools to calculate how much of a fee is necessary. To create an account without a creator, no creator will be specified in the operation and will include a proof of work adequate to cover the entire fee. If the dynamic cost is too high, regular account creation will be an option. To end users, this will appear identical to what it is today and only affects developers wishing to sign up new users.
Conclusion
Steem Velocity is going to be key to bringing millions of users to the Steem ecosystem. Communities and our mobile application are on their way. Development is proceeding well and 0.20.0 will be paramount to getting us prepared for those launches and opening the floodgates for the millions of new users that will get to experience Steem in the next year. We are as devoted as ever to the vision of Steem and are excited that we can continue to partner with you, the community, to make Steem as great as it can be.
Thank you for reading and Steem On!
- Team Steemit
Technical Notes
Out of all the feedback from the Steem Equality proposal, technical details was one of the most common themes. Below are some technical details for the features proposed above for those that are interested.
Dynamic Fee Algorithm
The fee algorithm is just a supply curve. It simulates an active market by setting a price depending on the supply of an asset. In this case, those assets are account creation tokens and resource credits. Account creation tokens will be a consensus construct to track the supply of accounts that can be created at a discount. Resource credits will represent stake days that can be spent on account creation and are non-transferrable. Resource credits accrue for everybody at a stake-weighted rate and are non-consensus. Account creation tokens are tracked as consensus state and are printed at a rate specified by the witnesses. They are only bought when an account is created and are destroyed on use. They can pool up to two days worth of the quota to allow for burst account creation.
The supply curve we will use for the fee algorithm is a rational function in the form . defines a known point on the curve.
We define the account creation credit supply curve using the following curve:
- is the current supply of account creation tokens.
- is the daily rate that account creation tokens are created. This will be witness votable.
- is the maximum number of resource credits allocatable due to stake.
- is a resource credit overprovision ratio. is 10% overprovisioned. This defines what the maximum size of the burst supply can be. We propose a value of 0.1.
Using these values the price of an account creation credit when there are one day's worth of credits available () will be of the burst resource credit pool. We will cap the supply of to which will create a lower bound of the price at .
The supply curve for the burst resource credits is defined using the following curve:
- is the current supply of burst resource credits. will be capped at .
- is the base fee to create one account with pure STEEM. This is defined by the witnesses using the existing account creation fee.
As a sanity check we can calculate the price of one account when and .
And because we know the minimum price of an account in resource credits we know that the minimum price in STEEM will be .
For the proof of work dynamic fee we will define the price in hashes. The value of each work is the expected number of hashes to achieve a work with specific difficulty. The equation becomes the same as the resource credits for STEEM except that becomes the base number of hashes for an account, which will be defined by a witness vote.
Per Satoshi Pricing
Having an instantaneous price for a specific supply is good, but we actually have a continuous supply as tokens are bought. Each satoshi is listed in the market at a different price as defined by the supply curve and needs to be bought at the respective price. We can calculate this using a definite integral, however the solution to our supply curves contains a natural logarithm, which is difficult to compute using integer math. Instead, we will use the following approximation.
This is a trapezoidal approximation of the integral. Because our supply curve is concave up this approximation always overestimates, which reduces risk of exploitation. The change in supply should be small enough per transaction that the error is minimal.
Fee As Softfork
We want to keep all of the dynamic fees and resource credits as non-consensus logic in the witness plugin. This necessitates that the meeting of a fee is non-consensus. Having the funds in an account must continue to be consensus. As a countermeasure, the account creation token supply will be consensus. This way, in the worst case scenario, if a witness is compromised, the number of accounts that can be created will be limited to the supply of account creation credits.
Non-production Soft Fork
Currently in Steem, soft forks can only occur when a block is being produced. Once a transaction has been included in a block, it is in. Unless others disagree with the block on a consensus level, it cannot be revoked. Usually, this only deals with soft rejecting of transactions and it cannot be known which transactions were rejected for this reason. We have an algorithm to extend this premise and secure the blockchain further. Normally, blocks are a binary accept or reject. We want to introduce the concept of subjective reject. This is a block that a node wants to reject, but would not be rejected based on consensus. When given an opportunity to produce, the witness will produce on the last accepted block, but it willing to switch to fork containing a subjectively rejected block. So long as all witnesses are using the same soft fork rules, these forks will never occur. They exist to protect the blockchain against a misbehaving witness, as misbehaving will cause your block to be dropped and the block reward to be forfeited. There is nothing preventing witnesses from doing this today. This will simply formalize this logic in our release that will help protect the blockchain from misbehaving witnesses. This change is the most intrusive to the core blockchain logic as it changes the fork resolution rules. Due to this fact, we will not ship this change in 0.20.0, but in a later release.
Sounds good. I'll have to go through the math more carefully later. But all those details are "soft-fork" parameters and formulas (other than the account creation tokens state which by itself doesn't mean much) and thus can be easily changed later by witness consensus without a hardfork.
And while on that topic...
While that subjective reject solution is likely the best one and the most general one (not just for abuse of account creation by bad witnesses but for general abuse over things that have soft-fork protections), it may be useful to have further restrictions for this specific new account creation feature, especially since it won't be ready by HF20. One mechanism, for example, that may be useful in further limiting the damage of abuse is to only allow at most some fixed fraction of the daily account creation token rate to be consumed per block; so even if there was demand to create the entire daily limit of accounts instantaneously, the blockchain would still force it to be spread out over let's say a round, thus delaying the account creation by at most 1 minute but also ensuring that a single bad scheduled backup witness could only create accounts equal in number to 1/21th of the daily account creation rate (other trade-offs in time delays and limits to damage by single bad witnesses may make more sense). This consensus rule is easy enough to implement and provides useful protection against abuse with very minimal drawbacks during the time after HF20 is activated but the code for the "subjective reject" solution is not yet ready (and it still remains a useful additional protection against account creation abuse even after "subjective reject" is deployed).
Additional thoughts:
Would the system log the VESTS amount corresponding to the burned STEEM (or equivalent STEEM value of the PoW or stake used) at the time of account creation and continue using that for the rest of the account's existence to determine its share of this permanent minimum bandwidth? Or would each account always maintain the exact same share of permanent minimum bandwidth regardless of what was the STEEM amount they had to burn (or its USD value) at the time of account creation? Or something else entirely?
Perhaps this should be the time to separate out reactions from upvotes/downvotes in the UI. At a blockchain level, truly dust level upvotes (not the threshold that exists today but a much lower threshold determined by computed curation weights being so small that they might as well round down to 0) would
add to the(nevermind, it has to track it at least minimally as part of consensus ifnet_rshares
of the post but would not create a consensus-level vote objectnet_rshares
is to be modified, otherwise it can be abused; insertions in this paragraph are italicized) be rejected. Nevertheless,the upvote would still be captured at the middleware level along with any additionalthe UI could submit to the blockchain the reaction information provided withcustom_json
operations to reflect the user's opinion of the post, so that it could be properly reflected in the UI.By the way, while we are at it could this hardfork also get rid of the annoying time limitations on creating posts/comments. First of all, the consensus memory usage argument does not justify a longer time limit on top-level posts (currently 5 minutes, which is ridiculously long especially for use cases like Zappl) than comments (currently 20 seconds, which is still too much for active post authors responding to comments much less for useful bots). At the very least both time limits should be the same and should be lowered to a more sensible time limit like 3 seconds. But I am not convinced that any time limit is necessary. Perhaps the bandwidth rate-limiting on new
comment_operation
s should be adjusted to have a sufficient fixed amount (to justify the fixed cost of creating a newcomment_object
in low memory nodes) plus the variable amount that scales with the size of the transaction (to pay for the bandwidth utilization).Also, on a more technical level, if this account creation redesign requires creating a new operation for account creation to replace the existing
account_create_operation
, please do not forget to addextensions_type extensions;
. This was (correctly) done foraccount_create_with_delegation_operation
but apparently that operation is going to be retired with HF20. Theextensions
field is useful so that later hardforks can more easily add optional parameters with account creation. My favorite example of such an optional parameter that could be implemented in the future is one that overrides the initial recovery account to be something other than the creator of the account, so that the newly created account can have their intended recovery partner from the very beginning (even when a registrar different than their recovery partner is paying to create their account, or with HF20 if they are mining a discounted account) rather than needing to wait 30 days before the change can be activated.What would happen if you upvoted my post arhag?
With a 100% upvote? Right now, it would probably reward you with over $500 worth of value.
But I am guessing that was a rhetorical question.
That was still worth the price of admission!
Wow!
5 SMAKERS!!!!!
That can pay for a monthly car lease...
Unless you had a more reasonable mode of transportation, then it would be one car payment and 250 worth of steem!
:)
ROLF just have to...
hahahahaha I love this, ba.hahahahah.
I am also in the same state, in which the lady is.
These equations described above is moving around my mind, without any clue what they all about.
Lol !!!!!
I like the part about separating out the reactions from votes. There are no down votes but I like the idea because I want to encourage without using all my voting power.
I think the way how Steemit accounts are created, managed and used is probably one of the biggest obstacle of expanding of Steem world!
Wow... You could have just written your own Post with all that information...
@pocketechange
Hi arhag,
A little off topic. Last month I powered up thinking steem was still decreasing 100% reading revent posts from people explaining steem and steem power. Then I found out today that a fork in 2016 already changed all of that to 9.5%.
The whitepaper I heard has not been updated only the FAQ.
You seem to know a lot about the intricacies of Steemit.
If someone asks you why should I power up versus just investing in steem what would your answer be.
Or could you point me to the right directions so I can figure out exactly how steem works now after all the forks after the whitepaper?
This is big one. Not just a parameters change, but a lot of development was done. Is is remarkable that active development still happening after @dan left. This means that platform is matured and could be trusted. STEEM is trully decentralized.
To be fair, Dan wasn't actively coding for months before he left. It was clear that Steem was in good hands. Indeed, we have star developers on Steem beyond the Steemit Inc team.
Yea. Dan himself acknowlage this. He sad that success of STEEM is more dependent on quality of frontend than blockchain part.
Naaaaaaah I dont think its decentralized. It think it just improved its representation, maybe just in time. I am impressed with this latest fork in the road. This may calm the dead fish and minnow ranks somewhat. Yea popularism!
Here is my alternative proposal: https://steemit.com/hf20/@samupaha/thoughts-and-alternative-proposal-on-hf20
TLDR: Let's replace SBD with SAT (Steem Account Token) which is backed by steem that will be used to give SP for a new user when a new account is created. SAT gives a right to create one account, and it can be earned as a reward insted of SBD.
OPOW-mining is environmentally destructive and it will cause the value to flow outside of Steem ecosystem, so it shouldn't be used.
I read through your proposal. I appreciate the thought that you and community put into responses and the creativity that we have at our disposal. A couple of quick notes.
The spam was problem earlier because of some bugs in the bandwidth calculations that have since been fixed. Users acting in this manner will be rate limited whereas they were not before. It was a problem because of another bug that we did not know about at the time. Rather than keep an archaic rule in place that is causing users today headache, we want to get rid of it.
Your idea regarding tradable account creation tokens is actually one that we were entertaining. But it does not solve an important problem that was outlined in the proposal. Cost over time. There is simply not enough STEEM to sign up the users we need to at current prices. And we don't want an expensive price. Scarcity is good. It creates competition. But in the case of Steem, we want the competition to be for the rewards and not for the ability to get an account. Most of us here understand the value of Steem and would gladly pay for accounts, but that isn't going to work for mass adoption. People would not have started using Facebook in the beginning if they had to pay $5. Maybe they would now because of market share. But we don't have that level of influence yet.
We don't expect mining to be used often for account creation, but there are still many individuals in the crypto space that are not using Steemit who place a high value on their privacy. Verifying a phone number or email address is a non-starter for them.
As for some of your other concerns. Just because they are not mentioned in a proposal does not mean we are ignoring them. We are trying to make these releases as targeted and small as possible. There are many things we want to get around to and will in time.
What if we used BOINC instead of existing proof of work mining algorithms? Would that be possible? (I left a more detailed comment below.)
I like this idea, Ripple did something similar when they first started giving out tokens. Unless they are just converting scrypt coins to cover the account creation fee. It would be nice to have mining support science
I guess @samupaha raises a very valid point in this post against the above proposal.
If I am allowed to use my Steem Power to direct part of the reward pool to this very comment (which I just did), then why on earth am I not allowed to direct the same reward pool to fund a new account for my friend?
Surely, a new user (in most cases) is worth much more to the ecosystem than my stupid comment. Yet I can waste our common funds on rewarding myself but not for bringing a new user.
Something seems to be very wrong in the incentive scheme.
You are very correct. One of the most significant problems with the current vote weighting scheme on Steemit is that it is so prone to financial manipulation, rather than simply being useful to promote valuable content.
The white paper makes this very clear "...algorithms must be designed in such a manner
that they are resistant to intentional manipulation for profit."
HF19 reduced the incentive to manipulate curation for financial purposes by making VP weighting by SP linear, rather than exponential, but this isn't a fix, merely mitigation. HF19 also increased the rate at which VP decays by 400%, and this has resulted in an explosion of self voting - almost solely due to financial manipulation.
I acknowledge that devs are human with limitations on their time and ability to build Steemit, so hope my comment doesn't imply I think they need to fix everything I think is wrong right now. I do want, as you have, to keep these issues in the conversation, so that while the devs are furthering Steemit's journey down their roadmap, these problems that need fixing can be addressed soon.
So still a few days delay to register?
Been trying to reach you but can't find your chat. I have same username in chats
I only have one question. How many kitchenware we have to go through before getting a U.I from this century? :)
All kitchenware :)
There will be better frontends off steemit.com in no time, I am (not) afraid. ChainBB, Zappl, Busy, ... More will certainly be coming along.
good job by HF19, and I think you need to update the white paper, huge changes since the beginning
That's in progress too!
glad to hear that :)
This ^
The reason why steemit experiences exponential growth in it's userbase.
HF 0.20 already in the cards, that's fast!
We are planning them in a pipelined fashion, so development of the next proposal is happening simultaneously with the previous fork. Steem on!
Great job, i'm a new user and like Steem(it) very much!
I also just read the 2017 growth plan, which I totaly support!
Kudos, this is how it should be done!
This process is showing some serious maturation as the hardforks go by.
While this will reduce the incentive for people to create extra accounts at Steemit Inc's expense, attacks will still happen just to burn down your stake. You will still need to rely on a costly verification process to avoid that, and you can't onboard millions of people with a time consuming process.
Are there any plans to incentivize other participants in the network to carry the cost burden of creating new accounts?
We can detect abuse just fine—that isn't our issue. (That is why we have the signup approval process in place at the moment. Very few fraudulent accounts are getting through, but the UX is suboptimal.)
I have an email list of over 20K people, and was planning to bring them over to Steemit, but the approval time takes way to long, and I am affraid they will get discouraged. @sneak @steemitblog