Edit: Some people pointed out that it is indeed possible to lower the maximum block generated by Core, but not through the CLI. It would not need a downgrade, but at least a restart.
First of all, this block was invalid for all Bitcoin Unlimited clients with EB set to 1Mb. Currently, all mining pools running Bitcoin Unlimited have configured their excessive block size to be 1Mb. The block was actually rejected by the same node that mined the block.
Code: Select all
2017-01-29 06:58:48.499177 Processing new block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 from peer myself (0). 2017-01-29 06:58:48.508666 Excessive block: ver:20000000 time:1485673118 size: 1000023 Tx:2290 Sig:4140 :too many bytes
There has been a lot of misinformation out there, especially from Core developers and Core supporters. Greg Maxwell was claiming that it was a hard fork attempt, and there has been a lot of gloating in general by people trying to leverage the situation for their own gains.
Another problematic lie from the Core camp is the claim that there was a risk of a chain fork due to miners engaging in spy or SPV mining. This false claim is being spread by Blockstream CEO Adam Back, among with other ridiculous claims such as pools not actually running Bitcoin Unlimited.
The truth is that most pools either spy mine (listen directly on the other pools using Stratum), or do headers only mining (some people call this by the incorrect term "spv mining") that only validates headers before starting mining. Even Core/Segwit supporting pools like BTCC (Samson Mow) and Bitclub Network (run by Core supporter James Hilliard) engage in this practice, simply because the reward is greater than the risk.
When Bitcoin.com's excessive block was broadcasted, most of the other pools started mining on top of it for a little while. Here is our log:
- 06:58:48 Bitcoin.com mines an excessive block at height 450529
06:58:49 ViaBTC starts mining a block at height 450530
06:58:49 BTC.TOP starts mining a block at height 450530
06:58:49 BTC.com starts mining a block at height 450530
06:58:49 HaoBTC starts mining a block at height 450530
06:58:49 BTCC starts mining a block at height 450530
06:58:49 F2pool starts mining a block at height 450530
06:58:50 BTCC starts mining a block at height 450529
06:59:03 ViaBTC starts mining a block at height 450529
06:59:20 BTC.TOP starts mining a block at height 450529
06:59:30 F2pool starts mining a block at height 450529
06:59:50 HaoBTC starts mining a block at height 450529
07:20:19 Bitclub Network finds a 998.2kb block at height 450529
Imagine that all mining pools are doing spy mining and waits 30 seconds for a timeout. With an average block time of 10 minutes, it's a 5% chance of finding an empty block that would get orphaned, but the risk of this happening twice in a row is 0.25%, and three times 0.0125% and so on. The conclusion is that Adam Back's claim is not only wrong, it's fear mongering and a part of the Core camp's ongoing crusade against mining pools in general, and anything SPV related in particular. In this case, there were no risk of causing a BIP66-like fork.
The best way to mitigate the risks for spy / headers only mining is to operate a good block relay network. Bitcoin.com is going to allow anyone to use their network as soon as it's available for public peering. Our network will carry all blocks in and out of China, and carry it to North America and Europe. We are currently working on a new compression technology called uthin blocks, allowing 99% compression and using UDP for maximum transfer speed. Another great way to mitigate the risks is to run Bitcoin Unlimited's xthin blocks with expedited forwarding. Xthin is very fast and will decrease the time your pool is mining without validating transactions.
This was a good learning experience for Bitcoin Unlimited, for Bitcoin.com and for the bitcoin community. It proves that the system worked, that invalid blocks can be mined and relayed without causing much trouble. It also proves that pools are taking responsibility and balancing the risks and rewards properly.
The Bitcoin.com Mining Pool Team