I'm happy that everything worked out and that nothing harmful took place to the blockchain or to the accounts. I'm also happy that things are up and running now.
Thank you for all the work troubleshooting and getting us back up and running.
What I'm not happy about is the lost of productivity for five hours, and potentially up to 12 for others depending on their time zones.
To know that one failed transaction could bring the entire blockchain to a halt, rather than it being isolated and dealt with individually does not make me happy. I know I'm not a large account, so what I potentially lost in rewards and productivity individually during those five hours is probably minimal. But what about the combination of everyone? I don't know what that amounts to, but I'm going to be conservative and say it's substantial.
I know this will be looked upon as a complaint, and it is, but I'm hoping that someone somewhere can see that it's constructive. It isn't optimum, or for that matter, an adequate solution for everything to stop anytime something untoward occurs on the blockchain. I've checked into nijeah's account, and he's currently delegating most of his SP to a deadfish account who hasn't done anything with it for at least two months.
I'm not trying to be disagreeable here. I'm trying to point out that one account doing something that occurs regularly (powering down) shouldn't stop the entire blockchain. If this one is fixed, are there other potential bugs like this one still lurking out there somewhere? Is having the entire blockchain stop the only way we have to troubleshoot it?
Look at it this way, would you rather have the blockchain stop for a few hours or have someone give himself 37,898,000 SP out of the blue? Which do you think would have a more negative impact on the network and ecosystem?
hear here
Hey @pfunk. Not at all ungrateful that the transaction didn't go through. If we're talking about what I would rather, though, I would rather neither happen. Someone shouldn't be able to give themselves nearly 38 million SP and the blockchain shouldn't shut down for all of us. The filter for such transactions shouldn't fail.
I think we can agree on that. I think we also agree that stopping the blockchain is better than the transaction going through. The questions remain, though. Is there potential for more of these 'unusual transactions' and if so, will anything be done about them before someone else accidentally or maliciously brings the blockchain to a halt again?
In software development it's impossibly optimistic to think a complex piece of software will be bug-free. Developers of course try to think of all of the ways something might be exploited but all the bases are rarely covered. There are numerous checks and transaction rejections in Steem, for some things less obvious than others. Often it's the exploitation of a bug that identifies it and drives it to be fixed.
Of course ideally the blockchain wouldn't stop and the transaction would have been rejected. But much like @timcliff said, considering the circumstances, the outcome wasn't too bad.
I have worked for a company where there was a formal requirements process with full traceability in place, we had solid DTAP environments, programming was done in Ada, code and module reviewing and testing was done in an almost religious way, and we had a very competent and creative dedicated FMECA team, and also aggressive alpha and beta testing, and guess what ...
Shit happens. Having shit happen less often is very expensive, and even then there are no guarantees. Still, my trust in the quality of the blockchain codebase did take a small hit, can't help it. Well caught and solved, though.
The transaction that caused it to stop was a very unusual one. At best, it was a mistake. There was a good chance it was actually malicious.
The majority of the time, individual bad transactions are filtered out before they enter blocks. This way, they do not impact all the good ones. In this case, it got past the initial filter. Once it was in a block, it is not possible to separate it out.
I know it is not ideal, and obviously the loss of t up-time was a really big deal, but given what happened, the temporary freeze was the best possible outcome.
I appreciate the answers. Does anyone know why this very unusual transaction got past the initial filter? And is there only one filter to go through?
Every type of transaction has filters coded up to prevent invalid transactions of that type. This person found a "creative" case that was not anticipated, and therefore didn't have coding in place to stop.
that it happpened ( the freeze) and was fixed within 3-4 hours speaks volumes. well, to me at least