Tue Jan 31, 2017 6:14 am

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

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

As you all know, a bug in Bitcoin Unlimited caused Bitcoin.com to mine a block that was 23 bytes larger than allowed. We discovered this right after the block was mined, and took precautions immediately. The immediate action was very simple, set the max generated block size to 0.999Mb via the cli. This is a feature that does not exist in Core, so if this bug arose in Core, a restart of the client would be necessary.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.The reason the block was broadcasted was because we have our own network for hi-speed relay of blocks. This network is hosted on several dedicated servers across the world and have two routes from Europe to China, and several routes from California over the pacific that lands in Hong Kong and Beijing. The block was broadcasted internally and some of these nodes have the default setting of 16Mb blocks, so they were broadcasted to the rest of the network. We have now updated these settings to only allow 1Mb blocks.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:This proves that since the validationless mining debacle a few years ago, the pools have checks and balances in place to make sure they don't build a block on top of an invalid one. The reward of 12.5 BTC clearly outweighs the risk of mining an invalid block for 30-40 seconds. Since it's very uncommon that invalid blocks like these are mined and broadcasted, it's a risk worth taking for the pools. It also means the contingency plan works. The slowest pool in this example, were mining on the invalid block for 61 seconds.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.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.RegardsThe Bitcoin.com Mining Pool Team