Spam attack scenario of Steem

Premise
I would like to have discussion to think about attack case in the open network to improve the protocol.

1. Spamming atack

Bandwidth per share rely on adjusting the reserve ratio to the current network usage.

Currently the reserve ratio is 20,000.

As my previous post https://steemit.com/steem/@tomoaki/steem-current-status-total-steem-supply-total-sbd-steem-dollar-supply-total-vesting-shares-steem-power-reserve-ratio-etc 

You can also check from another API providers like this https://api.steemjs.com/getDynamicGlobalProperties
from this post https://steemit.com/steemjs/@joomla-tips/steemit-rest-api-documentation-part-1

So...1 /20,000 * 100 = 0.005 % token holder(s) !  

0.005 % token holders = $150M (current STEEM market cap) * 0.005 % = $75k ! token holders can fill a full block with spam transactions without paying any fees. (because bandwidth-per-share)

Now we can think who can flood the network in the condition ? 

Information from the Steemwhales shows more than 150 people  http://steemwhales.com/?p=8&s=total can flood the network only by himself !

Is this low reserve ratio is dangerous, don't you think so ?
Or I would like to know how quickly the dynamic adjust will work.(if one hour we will be lagged in a hour for any actions)

```

 from whitepaper 

Adjusting the Reserve Ratio

Rate limiting requires that the network adjust the reserve ratio quickly enough to mitigate the impact of an attacker attempting to flood the network. Let’s assume the attacker has a large balance, say 1% of the available tokens. If we also assume that the network targets 50% utilization, then a sustained attack should find this user throttled to 25% of network capacity assuming everyone else is also using 25% of the capacity. Stated another way, the largest single user should never be able to consume more than 50% of the target capacity unless they own more than 50% of the SP.

Let’s use an initial reserve ratio of 200x. Due to fractional reserves, this means someone holding 1% of the tokens has the right to demand transactions totalling 2x the maximum block size. In order to bring the network usage of the attacker down to 25% the reserve ratio would have to fall to 25x. This would cause the minimum balance required to transact once per week to grow by 8x.

The blockchain can establish a response rate that says any sustained increase in usage should be brought down to the target capacity in within a short period of time (say 30seconds). An attacker attempting to spam the network shouldn’t be able to disrupt service for normal users for more than a minute.

While reductions in the reserve ratio must be quick and non-linear to counter abuse, increases in the reserve ratio should be slow and linear. If the network adjusted in both directions in just 30 seconds then an attacker could pulse the network. A flood of transactions should be corrected in 30 seconds and then take a hour to return to their pre-attack levels. Under this model the attacker could flood the network for 30 seconds per hour or less than 1% of the time.

There must be a slow constant upward pressure on the reserve ratio any time network usage is below 50% until the network hits the maximum reserve ratio. The maximum reserve ratio determines the minimum required stake to flood the network in short bursts.

Any user with fewer than TOTAL_TOKENS / (2*RESERVE_RATIO) will be unable to produce enough transactions to fill even a single block. With a reserve ratio of 200, this means any user with less than 0.25% of the currency cannot create enough transactions to delay anyone’s service.

```