(sorry to keep going off-topic on I0coin)

But, my theory is this:

Someone is doing testing or has deployed, or is in the process of deploying, a large amount of ASIC using covert asic BOOST. Reasons being:

1.  Sudden large increase of hash power and diff on Bitcoin and Merged-mined BTC coins

2. Empty/small size blocks

- Empty blocks being added to BTC's chain
- Small block sizes
 
Mining empty blocks and small blocks are clues that covert asic boost is in use. Covert asic boost

"Miners must look for one collision of 4 bytes, which is 32 bits — so this collision is one of 232 hashing attempts. We take the square root this due to the birthday paradox to arrive at a  n approximate expected total of 65,536 attempts.

Each attempt may require changing the extra nonce to generate a new Merkle root hash.  However, due to the structure of the Merkle tree, this would require even more additional hashing. If we change the extra nonce, a new is hash is required for each row of the Merkle tree. For a large Bitcoin block with perhaps 10 or more rows, this is a lot of extra work and  is an inefficient process.

The following methodologies may make this process more efficient:

Option 1 is to produce empty or smaller blocks. This simply reduces the size of the Merkle tree and therefore requires fewer hashing operations to generate a different Merkle root hash. The extra nonce can therefore vary in the normal way to produce more Merkle root hashes."

- A few other options to make the process more efficient.

Each option, however, can have an undesirable effect on your operations if not done correctly, which brings me to:

3. Skewed transaction time stamps.

- We are seeing a large # of blocks containing (received) time stamps that are way out out whack. I can think of many reasons this would happen:

   - Huge hash increase on local network overloading systems (self inflicted DDoS). Think of a computer processor and system like a highway. Sudden increase of massive amounts of data clogs
     things up. Quite simply, if there are any constraints placed upon the call to/from the clock register, there will be time corruption.  
   - Buggy or flawed/low quality chip design
   - Sudden temperature changes
   - Environmental issues causing frequency changes
   - Power supplies that are not clean/stable
   - Packet storms and overloaded network resulting in timing update issues
If current UNIX time is 1530041671 (06/26/2018 @ 7:34pm utc), and system issues result in time being updated or read as say, 1030041671 (one bit off), we see transaction received time set to 12/04/2002 @ 10:41pm UTC

China is supposed putting an end to crypto miners in China. Complete BS obviously.. Seems like they are ramping things up instead.