BUIR-2017-01-29: Statement regarding the excessive block produced by Bitcoin Unlimited software on 29 January 2017

On 29 January 2017, a block with a size greater than 1 MB was unintentionally produced by the Bitcoin.com mining pool as a result of a bug in the Bitcoin Unlimited 1.0.0 software. The Bitcoin Unlimited project takes this incident seriously and is taking steps to resolve this problem and to avoid similar incidents in the future.

What Happened

On 22 December 2016, code was merged into the Bitcoin Unlimited repository that changed how much space was reserved for the coinbase transaction during the creation of blocks. This change was included in commit 1e085736 as part of pull request 164 [1]. This pull request implemented BUIP040 and included additional features and memory optimizations needed to support very large blocks [2]. These changes were included as part of Bitcoin Unlimited 1.0.0 released 27 January 2017.

The change introduced a bug that made it possible for the generated block to exceed the node’s specified Maximum Generate size when a miner adds a custom coinbase transaction.

On 29 January 2017, while mining with Bitcoin Unlimited 1.0.0, the Bitcoin.com mining pool produced block with hash 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 [3]. Because the software did not properly account for the size of the coinbase transaction added by Bitcoin.com, the block had a size of 1,000,023 bytes.

Due to the size of this block, it was rejected as invalid by all Bitcoin Core nodes and marked as an Excessive Block by Bitcoin Unlimited nodes with an Excessive Block setting of 1MB. All miners, including the Bitcoin.com pool, did not mine on this excessive block, but instead continued to extend the chain on top of the previous block.

The block was accepted, at height 450529, by Bitcoin Unlimited nodes with larger Excessive Block settings. Some of these nodes were issued 24-hour bans by Bitcoin Core nodes, although it appears all nodes remained well-connected with the network.

[​IMG]

Response

Immediately after the excessive block was generated, the Bitcoin.com mining pool operator contacted a Bitcoin Unlimited developer to help diagnose the problem. As an immediate workaround, they decided to incrementally reduce the size of generated blocks (bitcoin-cli setminingmaxblock 999000). Other pools mining on Bitcoin Unlimited were made aware of the situation as soon as possible.

The correct diagnosis of the bug was made with help from ViaBTC pool. A fix to the bug has been committed from pull request 259 [4].

Why did testing miss this issue?

Networks of nodes only running Bitcoin Unlimited accept blocks greater than 1MB in their default configuration. As a result, excessive blocks created by the bug in question did not trigger any errors in unit or QA tests. Testing on BU’s dedicated testnet (“nolnet” or “no-limit network”) has to date focused on the transition to blocks greater than 1MB, and so the generation of blocks in excess of 1 MB did not raise any flags.

Next Steps

The Bitcoin Unlimited project intends to learn from this experience. The following steps are being taken to address the issue and improve our processes:

Unit tests have been added to test that block generation produces properly-sized blocks.

In the last step of block generation (CreateNewBlock), a check for excessive blocks before they are propagated is being extended to blocks smaller than 1MB. This check already existed for > 1MB blocks but the test was not being run for <=1MB blocks. This will assist miners in detecting problems more quickly in the future, before excessive blocks are mined or broadcast to the network.

We are adopting longer term steps to solidify our code review and development processes.

We are reviewing our communication policies to ensure that our user base is quickly and clearly informed when problems arise on the network in the future.

In the coming weeks, we will be conducting an incident review. This will include investigation into ways this bug could have been caught earlier on in its lifecycle. Following the incident review, we will publish additional details about changes to our development and testing processes to avoid similar mistakes in the future.

Conclusion

The Bitcoin Unlimited project takes the interests of its users very seriously and strives to provide reliable software. We are working to provide the stable software that empowers all participants in the Bitcoin network, and we intend to continuously improve towards this goal.

Bitcoin Unlimited seeks to remove existing practical barriers to on-chain scaling by providing software for miners and all node operators to safely upgrade to larger blocks. We would also like to help move the Bitcoin community to a multiple-client future where the overall health of the network is resilient and not affected by a bug in the code base of any one project.

Thank you to all our users and supporters. We value your support and strive to live up to your hopes for a brighter future of on-chain scaling for Bitcoin.

[1] https://github.com/BitcoinUnlimited...mits/1e085736d59c6f72955ee4a1c21f887c5caa7f89

[2] https://bitco.in/forum/threads/buip...eters-and-defaults-for-large-1mb-blocks.1643/

[3] https://www.google.com/url?q=https:...563000&usg=AFQjCNGXxF7z6uB5-5c-OqyN3ok-bxcnnQ