Quote from: CHIEF56 on June 25, 2018, 11:45:59 PM

Quote from: CHIEF56 on June 24, 2018, 03:56:48 PM

Quote from: realdantreccia on June 24, 2018, 03:37:35 PM

Quote from: CHIEF56 on June 24, 2018, 04:04:15 AM

Quote from: realdantreccia on June 23, 2018, 11:31:08 PM

Quote from: CHIEF56 on June 23, 2018, 11:26:56 PM

Quote from: CHIEF56 on June 23, 2018, 10:21:33 PM

Quote from: realdantreccia on June 23, 2018, 12:13:56 AM

Quote from: CHIEF56 on June 23, 2018, 12:13:20 AM

Quote from: realdantreccia on June 22, 2018, 11:52:50 PM

I knew something happened at the end of 2017 to make the Bitcoin we have seen in 2018 "different" ... Never seen an empty block like this...

https://blockchain.info/block/0000000000000000004b27f9ee7ba33d6f048f684aaeb0eea4befd80f1701126

Ahh, that's an odd one.

Transaction fee of -12.5 BTC

State reorganization underway for BTC. F2Pool is the mining pool submitting blocks from the early 2000's.

Pardon, but what is block version 0x3FFFE000

?

https://blockchain.info/block/0000000000000000001955aec280e6803720da428144b9bcd8adaea039a83f0b

https://blockchain.info/block/0000000000000000001955aec280e6803720da428144b9bcd8adaea039a83f0b?format=json

Ahh.. BIP-9 version bits set by F2 pool signaling set up of soft forks, I guess. So much reading to do and so far behind Embarrassed

https://bitcointicker.co/block/528898 - 0x3fffe000

https://bitcointicker.co/block/528908 - 0x2000e000

https://bitcointicker.co/block/528916 - 0x3fffffff

If only I knew coding. Haha.

Code:

https://bitcointicker.co/block/528898 - F2Pool - 0x3fffe000
https://bitcointicker.co/block/528908 - F2Pool - 0x2000e000 <~
https://bitcointicker.co/block/528916 - F2Pool - 0x3fffffff
https://bitcointicker.co/block/528932 - CKpool - 0x2000e000 <~

What's your take on the version?

Which part of it? What do the values translate into exactly, you mean? I'd have to research more into them.

What does it mean overall? The miners are signaling soft forks. I believe, once 97% ? of miners are in agreement, it happens. Correct me if I am wrong, but by F2Pool + and then CKpool setting the same bits, that equals more than 1% of the miners agree on 0x2000e000

I should have read more earlier, but:

Actually, the use and change we are seeing here is indicative of the fact that miners of those pools are solving blocks using version-rolling ASICBOOST . . . Either (1) overtly (2) covertly, or both.

BIP661 reserved a range of values in the Version field for this purpose, or other functions: https://github.com/bitcoin/bips/pull/661/files

And just recent: https://bitcointicker.co/block/529235 - BTC.top

Overt AsicBoost

Instead of changing the extra nonce, a miner using AsicBoost alters the 4-byte version field in the block header (top left of the image). This implies that chunk 2 remains unchanged for multiple hashing attempts and work is therefore saved. If this methodology is used, changes in the version bits are visible to everyone, which makes this AsicBoost methodology easily detectable.
(more: https://blog.bitmex.com/an-overview-of-the-covert-asicboost-allegation-2/)

Somewhere in the following links, explanations are found for the large number of empty blocks and skewed timestamps.. no more time for me to look at the moment:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/013996.html

https://blog.bitmex.com/graphical-illustration-of-a-bitcoin-block/

https://blog.bitmex.com/wp-content/uploads/2017/09/AsicBoostWhitepaperrev5.pdf

https://blog.bitmex.com/an-overview-of-the-covert-asicboost-allegation-2/

https://blog.bitmex.com/empty-block-data-by-mining-pool/

https://blog.bitmex.com/wp-content/uploads/2017/09/AsicBoostWhitepaperrev5.pdf

(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.