Let's all be real, hard fork 20 did not go as well as we all would have liked. And witnesses have their share of the responsibility for this. As I already said on the utopian radio show I think all us witnesses should publicly state our expectations, requirements, and obligations for future hard forks.
This way the community can vote on what they want to see, Steemit inc. can prepare and ensure new forks are meeting these requirements, and the community developers can actually themselves develop forks that can be adopted. We all need to actually use the decentralized decision features that this wondrous blockchain has, and have discourse over it. I think this will be a great step to improving Steem as an ecosystem.
So without further ado I would like to state the first draft of my public witness statement:
My Hard Fork Adoption Requirements
- A code freeze with a tagged release
- meaning once testing started no new code changes.
- If a new change happens, testing may have to be restarted completely to account for it
- A testnet that mirrors the main net
- where all consensus witnesses run a server on the old version and migrate to the new version to properly simulate a fork
- where users interact and try to break things
- where enough tools work so that everyone can connect just like they would to the main net
- where DApps can be used on in a beta stage
- that has all the blocks from mainnet from at least the last 7 days applied in normal time and then undergoes a fork (so the process will take 7 days per fork)
- where we simulate the hard fork at least three times after the code freeze and before the real hard fork date
- Documentation on the changes and what code parts to look at
- with developer discussions on the changes that explain magic numbers and thought processes that went into the code
- for example how the RC parameters came to be
- with developer discussions on the changes that explain magic numbers and thought processes that went into the code
- If possible only one major change per fork and rather more forks.
- Give witnesses the possibility to do a full code audit of the changes. This means it has to be a manageable amount of changes.
- If something changes the way the Steem blockchain works in fundamental ways, it should be it's own fork.
- For example instead of the current HF 20:
- Fork 20: SBD print rate changes
- Fork 21: Voting Mana introduction
- Fork 22: Resource Credit system
- Fork 23: Discounted accounts
- For example instead of the current HF 20:
- This will motivate everyone to ensure the existence of better tools and systems supporting frequent hard forks and change the whole process into a routine.
- Even though exchanges will also have to participate in more forks, having a routine could also benefit them feeling save while upgrading.
As a witness I pledge to do these things for each new fork:
- Evaluate the fork to my requirements and do a public statement at the start of the code freeze, if I accept it to go into testing.
- Test the fork and at the earliest possible moment publicly state, if I will adopt it and why.
- Document my process of testing to keep everyone informed.
- Do a code audit of all changes to the best of my abilities.
- Run a testnet node, backup, and seed and contribute to testing.
- Develop my own publicly stated testing protocol that I will follow, and document all results.
- Always have one node on the old version, should problems arise, and be prepared to roll back changes.
- Always be available for any questions users may have about the network.
If I become a top 20 consensus witness, I additionally pledge to:
- Follow with the changes on github as they evolve and review/participate in the process.
- Implement community requested changes into patches/forks.
- Always do a full code audit with public results of new changes.
- Run a staging version of all my apps on the testnet.
So far I am witness rank #34 which is quite high but still no place to have my opinion heard. So I hope that this post can spark a discussion, and other witnesses do similar statements. We should not forget that the top 20 consensus witnesses are the ones making most of the decision, and they are under the most amount of pressure. But they also earn the most amount of rewards, so I would welcome them having public statements on what their stance is.
Update to @therealwolf: I will pitch to all the witnesses, so that they make their own list of requirements and pledges. My list is just a suggestion, please don't take it as the only way to do it. And I think in the near future I will try to have my witness votes reflect if someone has a pledge or not.
As always, feedback is highly appreciated and I will post updates to this as discussion evolves.
I will follow closely what the other witnesses will share in terms of self reflection, learnings and what they pledge to implement and/or request. I will then adapt my votes accordingly.
Thanks for initiating this!
(I will vote your post when my
VPmana has recovered from the HF20 wipe-out)This is where we should add a decent bounty and anyone discovering a bug should be rewarded. Then you will see lot of people jumping in and trying to break things.
I also would add a topic:
The super-secret-witness-channel is a closed black-box that should be at least read-only for other witnesses.
Wouldn't we need to implement some kind of Worker Proposals to be able to offer a Bug Bounty from the Reward Pool? Or are you saying Steemit and the Witnesses should fork out for it?
Yes for the bug bounty...its the only way to align interests...
Sounds like some common sense to me. A lot of this is just best practise for software development.
I'd personally like to see an agile development methodology adopted where we have a formal product backlog that people can vote on and actually have some relatively transparent and perpetual development going on via fixed sprints (ala scrum).
There has been far too long between updates for STEEM and the development processes that are being used are incredibly immature. For an ecosystem this large (and valuable!) it really is inexcusable.
Which is why I think establishing such standards in a decentralized manner is important. If all witnesses state how they want development to happen then voters can make an informed decision about it in their witness votes.
I already had plans to make a post similar to this and have been calling for many of the very things you’ve mentioned here. This would be a great start for all witnesses, but especially for those who have been raking in vast amounts of witness rewards for a very long time.
I’ll have my own post on this matter soon. Thanks for bringing this to my attention. It’s a solid plan for any witness to adopt.
Looking forward to your post then! I would enjoy if you would tag me in it so I get a notification :)
I knew poking you to come onto the show was a good idea. Just didn't know how good. <3
Great to hear your thoughts on the radio show last night, even better to see this statement as a follow up.
I hope to see similar statements from the other witnesses. Solid list of ideas to create a robust testing environment. Thanks.
This sounds very good to me. We can all agree that HF20 didn't go as well as it could have, so I'm all for any measure that might prevent this problem from happening during the next hardfork.
One thing I was thinking about though, that I haven't seen anyone talk about, is the potential for witnesses to add bounties to people who can break the testnet. From what I understood, the testnet didn't really have a lot of data, but a bounty might attract a lot more people to test it. I'm sure the top 30 witnesses would not have too much trouble pooling in for a bounty. This last part is obviously directed towards all witnesses on the blockchain, not only @reggaemuffin, but it was something that popped into my mind when I read the post and comments here.
On the radio show @jedigeiss and @techslut suggested that Utopian could post a bounty for users to break things. Which is a great idea so my witness pledge factors it in and asks for an environment where such a bounty can actually have an effect.
Ah, it's great to hear that other people also had this idea. Let's hope something like that could happen then. I can definitely see some people trying their best to break the testnet if they could get a few hundred STEEM or so for doing it.
I also agree with everything.
I would be happy to mirror a real blockchain testnet on my machines and run tests on it, provided there are clear instructions on how to do it. Will obviously modify steem.supply to work on both networks, the way ETH uses mainnet, Rinkeby, etc.
Probably the only way I would differ is about the incremental hardforks, like one feature per hardfork. There are many factors to be considered, and one big upgrade every few months is easier to be adjusted to than just smaller things. I think mostly in terms of user's expectations here, and not in technical or coding terms, because in those terms it obviously makes sense to go baby steps. But as a regular Joe I want to have less of a cognitive pressure on the actual usage (oh, shit they changed this thing again, when did it happen, etc..)
All in all, I agree HF 20 was actually a failure and should be recognized by everybody involved as such.
As an entrepreneur, I know oh very well that the most important and long lasting lessons (which served me so well along the path) were learned from failures recognized as failures and not disguised in "successes".
You got my attention @reggaemuffin. My personal take is to reset my witness votes. I have 28 witness votes awaiting for people with competence in the software industry. So far we have no competent witness sitting on the top 20, because all they accepted to release HF20! We need the right witnesses making the right decisions!
So... just following you for now but I hope to see your promises becoming reality!
Great ideas @reggaemuffin which is why I know that @ned and Steemit Inc will completely ignore everything you have said in this post because they have made it clear they like their rogue fluid approach to development and releases.
The problems we are seeing are sadly not problems witnesses alone can fix, they are fundamental issues inside Steemit Inc itself. The problem is the code that makes its way to the witnesses is broken and Steemit Inc provides very little guidance or support for a testing and release phase.
The blog post they put out where they kept saying they didn't know how things were going to go and they would "wait and see" was really concerning to read and knowing the issues we saw at launch were not easily addressable, HF20 should have been wound back.
A company like STINC which has the funds to hire developers and proper resources seems to be happy hiring friends and people they know instead of the best candidates possible. From what I can see, there are two main developers at Steemit Inc doing all of the work.
The real fixes are:
https://api.staging.steemit.com/as well as a staging environment for Steemit itself:https://staging.steemit.com/From what I know Steemit Inc. would really appreciate the witnesses to give such a pledge. But that is for them to state. If all witnesses are saying that they will not adopt a fork with X then Steemit Inc. knows what is up and won't do X, as we saw with HF17.
From the things you mention. Many of these are already there or not possible in the way you said them. Depending on Steemit Inc. to cure us all is in my opinion not the way to go. And yes, we need to hold witnesses responsible. And to be honest that is the task of all witness voters. Like in politics, if you dislike something, talk about it.
But I digress, this post was about the witnesses owning up to their part of the responsibility and publicly stating their stance on how development goes. If a witness will take your list as requirements, then definitely vote for it :)
I have to admit I agree more with @beggars than with you when it comes to the responsibilities of the witnesses. AFAIK few of them are experienced developers or sysadmins while many Steemit users have such a background. Requiring witnesses to run a test node seems absolutely reasonable to me but it's a major change in how witnesses are chosen and that's why I'm afraid it ain't gonna happen. Because for 35 years we all expect computers to work, not to be maintained heavily.
What should not be forgotten is that all of this could be a blue-print for other blockchain-based projects but I suppose you're already aware of that ...
Thank you for bringing up what I have seen many miss...
A solution or at least a reasonable suggestions to be debated.
I hope that many witnesses regard such a public statement as something important to have. So far responses are very good to it.
i like that this post has a lot of people, especially witnessess, adding input.
for us regular joes, its almost like a study session XD
ty for the post, and education i am recieving from said post
Pony Out
I agree!
"A testnet that mirrors the main net"
I think this should be done now.
Maybe have the top 20 witnesses to run the testnet since they are the ones making the money?
There is a testnet but it was not yet close enough to the main net to spot the problems we had. So my suggestions are tailored around closing these gaps for the next time.
Seems like they should be able to run a copy or mirror of the main net with just limited accounts. Like maybe have 100 test users.
New rule, to have a T20 spot you must have another node in testnet
Haha. Don't know if you could make it a rule, but the presence of a testnet node could be a deciding factor in a lot of peoples votes if it was more commonplace and communicated....
seems legit XD
I've never quite understood why 21 machines, 4 or 5 nodes and mixing versions and then feeding a mirror of reality into it from a purpose built block passing node can't be done. All I hear is "test net has to run a while and be reset" and " it only had one version at a time on it" um, not a valid staging platform?
Saw a lot of finger pointing at "witnesses should read the code" from folks who don't document the code, make the changes completely understandable or obvious and cannot even articulate or predict the effects of the very code they wrote (badly and undocumented along the way)
It sounds good to the uninformed to "blame the witnesses" for "not being diligent" but that excuse only seems to come from those with reasons to deflect fault off themselves.
You mean, like this guy, who was the STINC employee claiming to be in charge of the testnet?
https://steemit.com/steem/@inertia/re-ats-david-re-steemitblog-hardfork-20-what-to-expect-tomorrow-20180925t032945094z
Thanks! I agree with most of this too.
I would add that any test nets created and any test data should be made available publicly too - or at least for the access of all other witnesses - so that all can test and review. I think a website hub for this purpose is needed. The funds paid out to top 20 witnesses alone can easily cover the development of this - but steemit inc. should also have the funds to cover the cost without issue.
One thing that became obvious to me after completing my degree in system engineering/architecture a long time ago is that only the most 'serious' software companies actually use the formal design and testing structures that I learned at university. The banking sector tends to do this and I think that given that cryptocurrency aims in some ways to be a challenge to mainstream banking - despite the anarcho tendencies involved - people need to learn to use and value formal documentation and development/testing protocols. There really isn't a practical way to get good results without them. The downside is that this slows everything down considerably - but the upside is that things actually work as intended. In my opinion, we need more qualified people involved, including technical writers and, in fact, entire layers of support that appear to be missing from this complex distributed network of people. I don't think this kind of awkward, non communicative approach to this development can last much longer - if only because of loss of confidence and increasing capability in the competition.
Agree! Steem is two and a half years old now, it shouldn't be this way.
These are some awesome thoughts Reggae! You've had my vote for a long time, but I appreciate the update on how you would approach quality assurance with the hard forks. It all makes sense the way you wrote it, even for a code illiterate like me.
Keep on fighting the good fight! Hopefully these ideas will be heard and adhered to in the future!
Thank you for your trust in me @mikepm74! I believe that we witnesses can do more and I hope that my suggestions will be adopted by other witnesses.
This sounds really good and I hope other witness will follow.
seems like i regenerate the RC amount for 1 comment within 15 minutes o: - getting cheaper to comment
The RC credit system is going to destroy the platform. Someone needs to do something about it. It looks like a massive power grab by the whales. No small fry will be able to succeed.
The RC system is definitely a step forward but it will take some tweaking to get it right. Give it a few days :)
This is why it is so important to tweak the system inside a testing environment already and I think my proposed testing requirements would have helped lessen the first blow of RC.
ah come on... you're not going to ask for sensible software development processes, are you?!
270+ million USD market cap, I'm sure it'll do just fine with some hasty patches... it's just magic internet money, chill out...
/s
sorry, I'm still a bit salty after watching this magnificent train-wreck :P
I'm not even going to try to imagine what kind of surprises the holy grail of SMTs might have in store
Well yes I do! That is what we all should do ;)
I think the best move forward is to not blame but rather improve the process. Recognize that Steemit Inc. and the witnesses and the stakeholders who are voting were all kinda cowboying it and that we need better and clearly defined processes.
Maybe voters could have their own requirements for witnesses. That they publicly state. ANd then other can proxy on that if they agree with it.
And agreed, for SMTs we need this better process!
Yeah, and I really appreciate you stepping up with proposing some better best practices. We don't have to go full ITIL here and some things are often tough to realize in a real world environment... but we should at least try.
I'm a huge proponent of agile iterative approaches and I think you "guidelines" would make for a decent basis to create an executive framework here...
most importantly though I fully support your implicit demand for more technical involvement of the big 20 and other large project owners, but from what I can judge this would have to start with a more transparent top-down communication of developments towards the community.
It'll be interesting to see how the situation gets digested and if we'll just go back to stake obedient circle-jerking or if we make improvements from here...
Yes we need improvements, but there's also room for complaints... the negative RC and VP-drain coming "as a surprise" is simply not excusable!
I recognize I still sound salty... ah well... Thanks for making this post and keeping the needed discussion going!
Nah, SMTs are going to be developed, rolled out and then Medium and the Guardian will automagically come. Because this platform is so
unicornamazing!Hopefully they come after the clusterfuck though because lack of accountability may actually already undermine the future of the SMT platform.
If SMTs are going to be pushed, and I believe they can be a great platform for change and have a potentially disruptive future even, then we need more credibility on this platform. Which comes with accountability first, flearns next.
Great post, great follow-ons in the comments. Postmortems like these are what we need, and it is the task of everyone to add sufficient pressure on those who need to adopt the flearns.
I knew it was correct to never remove my witness vote from you.
Remove you t20 witness votes and spread them elswhere.
holger80 and emrebeyler!
and spread the word!
;)
I'm sure going to keep an eye on how the big 20 react to the aftermath, there's only a few up there that have my support to begin with...
We got "hardfork" on this one, it was a disaster, I think there was to much moving parts in this one but the ambition should be applauded...
Lets see where this leads us, for now, this Resource Credits could potentially kill off whatever activity is left on the platform
Wow like seriously? You mean the witnesses wernt involved in the HF20 decision making? Then who was solely behind the whole hardwork? This is a decentralised platform and I expect stuffs like this to be handled in a decentralised manner. I buy into what you suggest @reggaemuffin.
I think you misunderstood what I was saying. The top 20 witnesses are the main decision makers on new hard forks. So you have 20 people decide this in a decentralized manner and voters can vote in other witnesses into the top 20 if they like what said witness does. I am trying to get all these witnesses to state a public stance on what they plan to do and request. So that voters and developers can make informed decisions.
I would add the need for a documented plan for how to deal with unexpected behavior. What constitutes cause for a rollback? What level of "just wait and hope it fixes itself" is appropriate? We should hash that out before the fork so that we aren't stuck with it afterward.
I think such a plan is something the witnesses should come up with. In my pledge I do just that:
So I will have a plan to roll back changes and will communicate that with other witnesses. Best case we never need to roll back ;)
I think those are two different things. You have a plan for how to roll back, which is great and necessary. But we need an explicit plan for making the decision to roll back as well.
If 99% of users can't interact and 80% of the voting power disappeared, should we roll back? I think if we asked that question last week, virtually everyone would have said yes. Instead it was only asked after it happened, so we didn't get a rollback.
I think such a decision would happen organically if all witnesses have a plan. Just as any other hard fork decision happens.
The Resource Credit system is still unknown.... how many small accounts are being negatively affected??? I’m trying to find all this out. I like your suggestions for sure
Posted using Partiko iOS
The RC system will take a few days to reach a point where we can say something about it. But some of the more expensive operations are now taxed more, which includes comments. A test net that users would try to break would have given us some metrics about how good the RC system really is and so for now we will have to wait and see and then tweak things in a few days. In the meantime, if you have any questions regarding the RC system I am happy to answer them :)
I have a small account (700SP or so), and a tiny account (53SP). I have the second account as my just-in-case account and vote ten times a day and post once or twice a week.
Tiny account:
40.42% Vote Power available
33.13 % | 35,834,743,132 RC
(from https://steemworld.org/@shadowmask)
My account:
37.92% VP
33.06 %|418,249,130,388 RC
(https://steemworld.org/@bashadow)
at this point in time both accounts 1 post.
Primary account 7 comments 6 votes and a lot of rewards that built up.
Secondary Account - 1 vote and 1 rewards claim. (I would like to get my other votes out like normal to continue building it, but I am going to wait on it to recover a little bit.)
My main account I am trying, (not to successfully yet), at running it like nothing happened. (I have backed way off on comments and votes, about 1/3 speed on them at a guess).
If that helps any for you.
Thank you for your findings! Getting data on how users experience the new system is important. Writing a post about it can be beneficial to everyone :)
I am with you!
What you mention here is best practice in most production areas.
Testnet should be called "Integration" and mirror 1:1 the mainnet with top20 witnesses on it.
Here prioir a Hard Fork, changes will be implemented and tested.
My words for months now, but no one is listening to me.
What do I know, I have just decades of experience in those things.
We have to be fair, a live blockchain is really hard to test. But that is what we are striving for, a blockchain that moves fast with frequent hard forks that do not cripple everything. I hope that this helps in changing something.
I never said it would be easy:)
Maybe as a T20 witness you have to have node running in testnet, too.
Otherwise you can make it maximum to spot 21.
Or something like that.
There are so many good ideas how to improve the current system. You and some other below 20 witness should get together on it, build an alliance :)
Sad thing is, nothing will change.
I don't see it.
I have not seen any T20 post yet, that improves or criticises the past hf20..
One of my requests is exactly that each top 20 runs a node on the test net. I will definitely run one the next time!
And give them time, I hope that posts will be written in the next days about what happened.
I am hoping it be ok soon, maybe 5 days ahead,
it seems the road is so bumpy
really cool to hear you on MSP today, first time i saw you and interested in talking more!
Thank you for tuning in! I am slowly working over my fear of public speaking so I hope you will hear me more often in voice!
you should join us on voice in my discord, small group but lots of witnesses and cool people...i will send you an invite, actually in a chat right now and recording with some msp friends :) great to hear you and would like to hear your point of view and add you to the list of witnesses we have here that you'll see when you get here :) looking forward to it.
Spoken like a developer who has been through a few releases...
But you know what? All of that sounds entirely reasonable! I don't see anything in there super outrageous or ridiculous.
Hopefully it actually happens...
Exactly! Which is why I hope that many witnesses will adopt this.
It makes sense. A proper post mortem is required now and witnesses need to collaborate to prepare the next update and prevent something like HF20 upgrade from happening again.
It did harm Steem reputation and upset many steem app developers...
I already did a review of HF20 https://steemit.com/witness-update/@reggaemuffin/hf20-the-afterglow
And this is the first post in implementing much needed change to prevent it from happening again. I hope that many of the big stakeholders agree with me here.
Seems like missing our a real test on a real testnet(which truely mirrors the main net) was what causing the disaster like this.
Which is why that is one of my requirements ;)
Think it is good to hold the top 20 accountable for their role in rolling out this HF as well. I think the HF should have been rolled back 6 to 8 hours in. We are still now at only about 15% of the normal transacting user count, so even now a roll back might be still worth considering. I personaly just removed my votes for top twenty witnesses @curie, @blocktrades and @utopian-io and voted for the whole 21-40 bunch. I think the top 20 should really step up their game and convince the comunity (with statements like yours) this HF has been a major learning experience for them that they dedicate themselves to should not get a repeat, or make room for the 21-40 witnesses and let them proof the next HF won't have to turn out as dramatic as this.
I am holding them accountable. Which is why I am saying that there needs to be public statements from all of them and they need to set their foot down if things don't work.
Rolling back a hard fork after some time would be a problem in itself. That would need a lot of preparation in advance, otherwise you have to delete all the blocks after the HF block and we come into muddy territory.
I hope that we can implement a process where a rollback is not needed but an option in case of problems.
I like the way you've written this and would be open to starting up similar feedback mechanisms and expectation lists. Great job here! Got me thinking for sure.
Thanks @klye, that means a lot! Looking forward to reading your take on this in it's own post ;)
I will cast my vote for you today! Let's hope that you can increase in the rankings!
Cheers,
Peter
I won't pretend I understand half of what I just read, but from all indications, it's for the good of the blockchain.
Anything for the good of the blockchain and to ensure safer, smoother forks in the future is fine and supported by me. Good job, Muffin.
To add to your points, a CI pipeline and codeclimate like static code analysis can be added too. This can help the process dramatically.
A CI pipeline already exists:
https://github.com/steemit/steem/tree/master/ciscripts
But no tests are triggered - its only doing the build ?
Ideally the tests based on Tinman and using common frame works like caliper should be run when code changes are made. Now its not possible to have CI - CD for every commit, but periodic invocation of the CI - CD - benchmark can be done. Unlike other blockchains I think the non-consensus layer of the STEEM code base has large number of operations and rc_plugin is just one of the many components. Honestly I don't see any reason for not capturing the bad user experience by minimal testing itself. Unlike in the past STEEM's own Tinman is again getting some maintenance. Perhaps the community can help with CD infrastructure which will ensure high degree of coverage.
In any case, the blockchain and the ecosystem is not stable enough to meet real world scenarios. Personally I feel relieved as at some point during August I considered and designed a means to store part of a disaster rescue operation to the STEEM blockchain. The requests looked something like below and if we had moved ahead, this could have been a catastrophic scenario as the PDNA (Post Disaster Needs Assessment) is now happening and the STEEM blockchain could have prevented its progress.
Original plan was to put the request_ids and the status updates for the above requests to the blockchain as comments. Further the volunteer assignment.
The document (in progress can be seen here : https://docs.google.com/document/d/1EyypzKjkaREOyZGqXMu542QasPoqg16-2iOS9ALAymM/edit?ts=5bab8943#heading=h.h8bplm64d1o8 )
So, for STEEM its important that usability and reliability is ensured and it stays up irrespective of the HF (hard freeze) or otherwise. There is tremendous potential for this chain to become a public general purpose chain for the storage of immutable data and I hope STEEM succeeds in ensuring reliability before SMT, communities and everything else.
Probably the most important thing: STEEM urgently needs a TESTNET like Bitcoin!
https://steemit.com/steemit/@vikisecrets/hardfork-20-steem-urgently-needs-a-testnet-like-bitcoin
Steem has a testnet, but lack of participation, tools and processes made it miss the bugs we experienced. So What I am requesting is to improve the testnet with changes that would have caught the bugs we experienced.
If there is a testnet, then it was not tested properly or the testnet is insufficient lacking real data and real activity.
Servus erstmal!
Technisch hab ich zwar nichts beizutragen, jedoch möchte ich sagen, dass ich es gut finde das sich jemand um die Aufarbeitung der Probleme kümmert!
Fehler macht man damit man daraus lernt!
Danke dafür und steem on!
Reinhard
I'm casting my vote for you today in the hopes your fire will keep burning so you can accomplish some of these goals :-) I'd happily be one of those 'try to break this!' testers on the testnet ;-) Good luck!
Thank you! I've been wanting to see something like this from all the witnesses for ages. How can we know what we're voting for if they don't tell us? It's the reason I have been slow using my witness votes.
Posted using Partiko Android
Thank you for making constructive comments and suggestions.
Congratulations @reggaemuffin!
Your post was mentioned in the Steemit Hit Parade in the following categories:
I was being naiive, but I fully expected that Steemit Inc developers, all contributors to GitHub, and at least a few top witness were running testnets with simulated transactions for every extreme edge case permutation. After the Hardfork 18 debacle, it was obvious that proper stress tests and simulations were necessary, but here we are - same old story. Looks like everyone has slacked off and forgotten how crucial QC is to any venture.
Even as a low ranked witness I (and everyone of us) have obviously failed. I need to contemplate whether this is a responsibility I want to continue with going forward, given I do not possess the skills audit code and run simulations. In the past, lower ranked, non-developer, community-oriented witnesses could leave the engineering stuff to Steemit Inc and top witnesses. But clearly, this is a failed assumption I cannot make again.
Anyway, thank you for pushing the discussion forward.
Thanks @reggaemuffin for your good recommendations you already got my support! Lets hope that things work out better next time!!!
Posted using Partiko Android
I appreciate this update and proposal and just voted you as a witness, keep up the great work :)
Yes, this is exactly the type of thing I am looking for. Definitely voting for witness, I hope this same thing does not happen for the SMT HF.
The testnet needs a public condenser and users should receive a notification as an invite to join the test condenser to help generating some test traffic.
Steemit Inc devs should always write unit tests for their code, I’m not sure why the negative RC or the fact that it was possible for https://steemd.com/@interfecto2 to claim so many free accounts while having 0 SP wasn’t caught by some unit test.
Maybe if backup witnesses were not paid peanuts then we could also participate and spin up some test nodes.
I fully support your suggestions.
At the very least we need a public testnet. This would allow users to test upcoming hard forks themselves. It would also allow application developers to test their applications without putting anything on the blockchain. It's kinda crazy that we don't have this TBH. What exactly are developers supposed to do to test their applications?
We need this, there has to be more confidence in witnesses for choosing the right patches and be able to test them. The situation right now, that Steem inc are only really the only ones who can make updates, and have the knowledge of coding the Steem blockchain defeats the goal of decentralization.