Bitcoin.com's excessive block - Pool analysis

[magma]

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.

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

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:

• 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

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


Regards

The Bitcoin.com Mining Pool Team

[OgNasty]

It could have led to an interesting situation had there not been safeguards in place to prevent forks like this.

[johnyj]

It could have led to an interesting situation had there not been safeguards in place to prevent forks like this.

Even if it extends, it will be no more interesting than the previous two forks caused by core

[Seccour]

It could have led to an interesting situation had there not been safeguards in place to prevent forks like this.

Even if it extends, it will be no more interesting than the previous two forks caused by core

Bitcoin Core didn't exist at that time.

[Steffenpp]

there has been a lot of gloating in general by people trying to leverage the situation for their own gains.

But this is what you do most of this post. You used it to attack Core. When in reality they have nothing to do with the situation. You fucked up.

[Fremont]

there has been a lot of gloating in general by people trying to leverage the situation for their own gains.

But this is what you do most of this post. You used it to attack Core. When in reality they have nothing to do with the situation. You fucked up.

I'm not sure how you came to that conclusion but magma was not attacking Core, he was simply presenting facts; I'm happy to explain this in a little more detail to help clear up any confusion. For instance:

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.

This is quite clearly a simple statement of fact that setting the max block size to 0.999Mb via the command line interface is possible in Bitcoin Unlimited without restarting, and not possible in Bitcoin Core. The statement was used to demonstrate one of the differences between Unlimited and Core - that if a similar bug were to arise in Core, a restart of the client would be necessary. A statement of fact =/= an attack.

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.

This is a simple statement of fact that misinformation has been put out, that some people are misusing the situation in order to try further their own agendas and acts as a preamble to the image containing a discussion which comes below it.

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.

This is a simple statement of fact that the claim put forth by Adam Back in the discussion mentioned above is wrong, amounts to fear mongering and is factually incorrect; it is also being used in furtherance of Core's (with Adam, naturally, by association) crusade against mining pools and anything SPV related. The most latter part of that sentence re: a 'crusade' may well be an opinion, but the former - i.e. the statement that Adam's claim is simply wrong, an assertion which is backed up by the information given throughout magma's post - is a statement of fact.

Fremont

[LiteCoinGuy]

well, i will stay with Core here - it is better to be safe when you must handle a 14 billion market cap.

[Rmcdermott927]

well, i will stay with Core here - it is better to be safe when you must handle a 14 billion market cap.

Agreed. I'm running 3 core nodes currently. Hopefully segwit will activate in my lifetime.

[Decoded]

well, i will stay with Core here - it is better to be safe when you must handle a 14 billion market cap.

But can Bitcoin handle a much higher market cap? Say maybe 30 billion? I doubt it. Small blocks will restrict the network and currently act as a bottleneck. We need a solution ASAP. I'm not saying to move to Unlimited, but we just need a change.