This is definitely going to be an ultra-short post! You can read about the whole bandwidth error saga here, here and here!
The current thinking is that this sudden spike in bandwidth caused by an experiment triggered the algorithm for the current_reserve_ratio (CRR) that is designed to respond to a spam or DDoS attack. The consequences of this CRR algorithm are to immediately halve the network bandwidth.
But as users carried on doing their normal behaviour, completely oblivious that this was happening in the background, they triggered the CRR to continue to fall. Remember, the CRR is designed to protect the network from overloading. In this case, it was not a real overload but a temporary spike.
However, this experiment also triggered an error in the Steemit code. One of the parameters known as max_virtual_bandwidth was overflowing its 64-bit values. My understanding is that if such a calculation overflows its integer limit, then that parameter becomes disabled. I'm not sure of the exact cascade of events within the algorithms, but the upshot was that the system was unable to tell a temporary spike from a concerted spam attack. One of the things being fixed at the moment is to increase the max_virtual_bandwidth calculations to 128-bit.
All of this means that, if the final analysis is correct, the cause of all our bandwidth woes was not an increase in overall activity or the rise of the bots, but a simple bug exposed by a short experiment. The code for how CRR is triggered and how it increases back up to 100% still needs to be worked on; the increase of the above integer limit is in itself very quick to fix.
So, we await the eventual fix, but in the knowledge there is, for now, no attack on Steemit and no real issue about the bandwidth used by members - it's just a bug fix! Welcome to beta testing!
Thanks for reading.
PS This was as short as I could make it!
