Assuming the relevant section in the Steem White Paper is still valid, I have discovered something. I have been trying to ask around and even tried to find the relevant formulas in Github, but I prefer to deal in formulas than codes!

Anyway, in the White paper there is a section that states:

4.2.1 Example Implementation

Let B equal a user's average bandwidth at time T. Let W equal the number of seconds per week, and let N equal the size of the new transaction that occurred S seconds after T. Given this information the blockchain can calculate the new average bandwidth for a user as:

Bnew = MIN (0,B * (W-S) / W) + N * S / W

Tnew = T + S

Each user is entitled to an average weekly bandwidth of:

Let U = the user 's SP

Let S = the total number of SP

Let R = the current reserve ratio between 1 and Rmax

Let C = the maximum block size capacity set by witnesses

Let L = the total blocks per week

Let M = C * L * R

Allocation = M * U / S

A user would be entitled to an average bandwidth of M * U / S. Any time a transaction would cause the user's average to go above this threshold they would be unable to transact until enough time passes to lower the average.

The network can increase the reserve ratio, anytime blocks are less than half the target capacity and decrease it anytime they are more than half. The algorithm used to adjust R is designed to react quickly to decrease the reserve ratio when there is a surge in demand, while acting slowly to increase the reserve ratio in period of low demand.

The minimum reserve ratio is 1, and the maximum reserve ratio should be calculated to prevent small stakeholders from consuming all of the available bandwidth. If no one is using the available bandwidth then the reserve ratio can grow until a user with just 1 satoshi of the currency is able to transact every single block.

Let's look at this more closely:

Allocation = (C * L * R * U) / S

So if the total number of SP increases across the ecosystem, the allocation per user decreases. If the user's own SP is lower, then the allocation is lower. But look at this one: if the current reserve ratio is low, then the average allocation drops.

And each user's allocation is calculated as an average over a week. But we are seeing users with modestly large SPs bumping up against their bandwidth limits. I suspect the drop in the reserve ratio to be the main cause. In the 15 minutes taken to write this it has risen from a value of 229 to 243. I cannot see a place to fetch historical recent data, but I see from old articles that it was once 20,000! The White Paper mentions a value of 200, so these numbers are x100, meaning the current reserve ratio is really 2.43.

But this formula delivers a double blow because if the total SP is rising due to reinvestment at the same time as the reserve ratio is dropping, this can lead to a precipitous drop in our average allocated bandwidth. If the rise in recent claims (article care of @biophil) are mainly cashed out, then it is just the reserve that is having the major effect.

It's very recent rise in the last few minutes is no doubt due to so many people being locked out due to hitting their bandwidth limit. As this reserve ratio rises, more of your weekly allocation will rise above the bandwidth used and you can interact again.

The real question now is what is causing the drop in current reserve ratio?

I think we know.

What can you do at the moment if you are still getting a bandwidth limit message?

Your allocated bandwidth is calculated across 7 days, so look at all your current interactions - the simplest way is at steemd.com/@yourusername. Then, at least for now, adjust down your activity so as to lower your average use. Without any dramatic increases to the reserve ratio network traffic, this will take a few days to clear up.

(And, if I'm completely wrong about this, then I'm ready to eat humble pie... with extra cream!)

ADDENDUM (18 July 1 am local time)

The reason for the bandwidth limit errors is the current_reserve_ratio but it is not a financial parameter, it is purely a network traffic parameter. With the help of some witnesses we located the code that activates this parameter.

The reason that it has happened so suddenly rather than gradually is that the ratio only drops if the network traffic hits over 50% of capacity. The ratio drops so as to slow down the traffic, which has happened. It has also limited interactions and voting, but it does not target specific activities - it is purely about the number of actions logged to the blockchain.

The consensus has been to increase the block size - this should already be showing some improvements. In the medium term, witnesses will check their traffic stats to find out what has caused this steady increase in traffic.

Thanks to @personz (who found the crucial bit of code), @neoxian and @gmuxx for talking this through with me while many others were offline. Thanks to @ausbitbank for pointing out an error and to @aggroed for talking over some solutions.

Thanks for your patience.

Please resteem to the corners of SteemWorld - Thanks!

Update

Follow-up article: The Bandwidth Game - Join Now - Win 20,000 CRR!