You are viewing a single comment's thread from:
RE: HF 20 - lessons finally learned?
The system is expected to reach its equilibrium in the next 5 days. Rolling back is not an option on a blockchain, we need to look forward.
The system is expected to reach its equilibrium in the next 5 days. Rolling back is not an option on a blockchain, we need to look forward.
Which you believe because Steemit Inc. told you so? Wasn't not doing that the point of your post?
We're not approaching a point where users will have minimum basic functionality, we're diverging from it. This is disguised by the fact that nobody's voting, but if they were you'd find hordes of small accounts running out of RCs without being able to use all of their VP, because the number of SP needed to do that keeps rising.
As far as I can tell most of the resource pool balances are increasing not decreasing which means the cost of most transactions in terms of RC is decreasing. The exception being those that allocate state (mostly comments and posts). Those seem to be increasing in cost.
Overall we won't know how the balance works out for several more days.
Finally, it isn't ever guaranteed that small accounts get to use all of their VP, or do much of anything else. By design, small accounts have very limited usage and increasing usage quota comes with increased SP. Indeed, under the bandwidth system, heavy usage meant that many small accounts were locked out entirely from using the blockchain for hours at a time.
Right but what we are seeing now is small accounts locked out from using the blockchain under very light network usage. That is not equivalent at all to small users locked out under heavy usage under old bandwidth system IMO :)
Yes, it is absolutely not the same, it is different. Better? Worse? Those are less clear for sure. It is often a first impression that any change is bad. But is it really?
I'd add that some of these issues are temporary and due to a combination of bugs (being worked on) and transition effects from the switch (will evolve/resolve over time). Some are by design, though.
All this means is that traffic is very low. Which, duh?
So basically your position is it's fine that someone needs to put hundreds of dollars in to have basic functionality? If that's intended behavior I'll be leaving as soon as the exchanges are open.
That is not what increasing pool balances mean. Increasing balances mean that RC prices are decreasing (i.e. each user's ability to interact with the blockchain is increasing, across all SP levels). This can happen at any absolute usage level.
I don't have a position either way in the abstract. It depends on the actual costs of some particular level of usage relative to price being charged for it. This can be attacked in different ways, such as making the blockchain implementation more efficient so it can support higher usage. Just cutting prices and inviting unconstrained usage (for example low-SP comment bots making hundreds or thousands of comments per day as was the case before) with no way to pay for it doesn't sound like a viable approach to me.
Surely you would agree that there must be some SP level where the account can't use all if its vote power, and generally speaking that "low SP" accounts must have limited usage, right? Maybe that is <5 SP, maybe it is <1 SP, or even <0.1 SP, or maybe it is <30 SP or higher. We can't just pull this number out of the air, real resources must exist to support it (including with a much larger user base with many more such accounts).
AFAIK, the RC system was designed on the basis of physical resource budgets (for example, that it is sustainable for the blockchain to grow at ____ MB per day, that ___ msec of CPU is allowable per block, etc.) and then allocating these resources between users such that they can't be exceeded in the aggregate. These are real resource limits upon which the survival of the system rests. Now it is possible there are bugs or miscalculations in the early estimates, and that is certainly being looked at. So we will see what adjustments make sense to make.
The very nature of a freemium system is that basic functionality must be free. Maybe that's "sponsored by @steemit" in the sense of resource usage, but it's not optional unless we're going to a pure pay-for-play model, which is not what anyone said they want, and is not something I believe will be practical in the long-term.
As I pointed out to @andrarchy before the fork, there's a real risk that what we discover under this system is that Steem never really worked in the first place. That seems to be where we're heading right now.
Yes I think we all agree on that. Where we may disagree is on the how to define "basic functionality".
Certainly true to some extent, though the magnitude is less clear. IMO it is better to discover and work on improving any mismatch between expectations or desires on the one hand and reality on the other than to continue to play make believe.
BTW, you may find this interesting on cost trends:
https://steemit.com/steem/@holger80/how-strong-are-the-rc-costs-changing
Doesn't change that we have to work from where we are now
We need to get to a state where this cannot be said again with any seriousness.
" Rolling back is not an option on a blockchain". Uh... yeah it is... and if the resource credits stabilize at an equilibrium that freezes 90%+ of the actual human owned and operated accounts on the blockchain from normal interaction levels, then it absolutely should be rolled back. Flagged for massive disagreement with the statement and the philosophy behind it.
You can further patch to get back to old behavior, but you can not simply roll back to a prior version without invalidating all transactions since the fork.
thanks for clarifying, had just done some digging myself and realized this. my apologies, flag removed. I thought you were saying this as more of a philosophical statement. sorry. So related question though - if a HF21 was released that had same code as the last stable HF19 release that wouldn't work?
No because the new transactions that exist on the blockchain over the past 2 days, and probably some of the resulting state, would be considered invalid by HF19 code. There would need to be a new hybrid created, and that's a very significant effort.
I guess with the RC system in particular you don't even have to patch or roll back, Stinc built into HF20 the ability to roll back the RC system and go back to prior bandwidth system. From steemitblog post: ""Due to this uncertainty, we added a 'fail safe' to the code that will enable witnesses to revert from the RC system back to the old bandwidth system if absolutely necessary."
In practice that is easier said than done. It requires not only witnesses but (nearly) all nodes in the whole ecosystem to make this change.
Ah... thanks for that clarification. So even if a supermajority of top witnesses made this change, if Stinc isn't on board and doesn't update api.steemit.com for instance it wouldn't work?
Correct. Transactions go through the front end nodes first. For steemit.com users (and indeed many other app users) that means nodes run by steemit.com. If those nodes don't pass through the transactions, witnesses never receive them and they don't go the blockchain.