BUIR-2017-01-29: Statement regarding excessive block by Bitcoin Unlimited software 29 Jan 2017


Staff member
Aug 22, 2015

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.


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.


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/BitcoinUnlimited/pull/164/commits/1e085736d59c6f72955ee4a1c21f887c5caa7f89

[2] https://bitco.in/forum/threads/buip040-passed-emergent-consensus-parameters-and-defaults-for-large-1mb-blocks.1643/

[3] https://www.google.com/url?q=https://live.blockcypher.com/btc/block/000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5/&sa=D&ust=1485800794563000&usg=AFQjCNGXxF7z6uB5-5c-OqyN3ok-bxcnnQ

[4] https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/259

Edit: 8 Feb Review
Last edited:

Steffen Søborg

New Member
Dec 10, 2016
Why arent you creating an alt-coin? It makes no sense to me why you have created your own testnet and you have vastly different consensus rules. Yet you have to accomodate bitcoin consensus rules as well. There is going to be more disasters eventually. Why are you chosing this approach? Why not simply go the whole way and launch your alt-coin. It could use the same UTXO set as bitcoin even. Who cares.


Staff member
Dec 16, 2015
It makes no sense to me why you have created your own testnet and you have vastly different consensus rules.
The testnet is for > 1MB blocks.

Why does SegWit have it's own testnet. Does that make sense to you?

It should. When someone wants to test new consensus rules, it's difficult to do so on an existing test network without disturbing / interfering with it. There are good reasons to create a separate test network to test your changes in a more isolated way.

This has nothing to do with creating an alt-coin or not. You're going off-topic with that on this thread. If you want to discuss that, why not open a different thread in the Unlimited subforum.


Staff member
Aug 29, 2015
BUIR-2017-01-29:由Bitcoin Unlimited软件在2017年1月29日生产出大小超标的区块的声明

在2017年1月29日,因为Bitcoin Unlimited 1.0.0软件bug导致了Bitcoin.com矿池意外生产出一个大小超过1MB的区块。Bitcoin Unlimited项目积极认真和严肃地对这个问题做出对应解决措施,并且避免将来发生类似的事情。


在2016年12月22日,Bitcoin Unlimited代码仓合并了一个改变新区块的coinbase交易占空间大小的代码。这个改变是作为合并请求164[1](pull request 164)的一部分包含在1e085736更新确认(commit 1e085736)。为了支持非常大的区块,这个合并请求植入了BUIP040和增加了额外的特性,以及优化了内存管理[2]。这些变化都包含在了2017年1月27日发面布的Bitcoin Unlimited 1.0.0。

这些变化引入了一个bug,使得节点生成新区块时,如果矿工添加了一个自定义的coinbase交易信息,这个区块的尺寸就可以超过节点指定的最大可生产的区块尺寸大小( Maximum Generate size)。

在2017年1月29日,Bitcoin.com矿池使用Bitcoin Unlimited 1.0.0挖矿,挖到了一个区块,hash为000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5 [3]。由于Bitcoin.com添加了Coinbase交易信息,其软件并没有考虑这个信息导致的区块尺寸增加,导致了这个区块的大小为1,000,023字节。

这个区块因为尺寸太大,会被所有的Bitcoin Core节点和设置了EB参数为1MB的Bitcoin Unlimited节点全部拒绝。所有的矿工,包括Bitcoin.com矿池,都没有在这个超标的区块上进行挖矿,而是在这之前的区块链顶端挖矿。

因为部分Bitcoin Unlimited节点的EB参数设置为了大于1MB的值,这些节点在高度450529接受了这个区块。这些节点中的一部分被Bitcoin Core节点列为了24小时禁止连接,但是所有节点依然和全网保持了良好的连接。


这个超标区块产生后,Bitcoin.com矿池的运营立即联系了Bitcoin Unlimited开发者,请求做问题诊断。他们提供了一个立即解决问题的办法,降低可生产的最大区块大小值(bitcoin-cli setminingmaxblock 999000)。其他使用Bitcoin Unlimited挖矿的矿池也被尽可能快地通知到了这一个情况。

这个bug的正确诊断是在ViaBTC池的帮助下完成的。修复bug的的合并请求259[4](pull request)已经更新确认。


在网络中只有运行Bitcoin Unlimited节点在其默认设置情况下才会接受大于1MB的区块。因此在代码QA测试环节中,这个漏洞导致的超标区块没有触发任务错误。在BU的专用测试网络中("nolnet"或"no-limit network")都曾经有集中于测试生产大于1MB区块的环节,所有的大于1MB的区块均没有报警。


Bitcoin Unlimited项目将吸取这一次错误经验。我们正在采取以下步骤来解决这个问题和改进我们的流程:







Bitcoin Unlimited项目非常重要用户的利益,并努力提供可靠的软件。我们致力于给比特币全网用户提供稳定的软件,我们正在朝着这个目标不断前进。

Bitcoin Unlimited旨在消除链上扩容的障碍,我们通过向矿工和所有节点运营者提供软件来安全升级到更大区块。我们还希望努力为比特币社区未来的多客户端共存做贡献,以实现网络整体更健康和更有弹性,让网络不会因为一个项目的软件漏洞受到影响。


[1] https://github.com/BitcoinUnlimited...m ... 7c5caa7f89

[2] https://bitco.in/forum/threads/buip...e ... ocks.1643/

[3] https://www.google.com/url?q=https:...5 ... 3ok-bxcnnQ

[4] https://github.com/BitcoinUnlimited/Bit ... d/pull/259


原文作者:solex Moderator


Staff member
Aug 22, 2015
BUIR-2017-01-29 Review

On January 31, 2017 the BU team released the above report detailing our initial assessment of a bug in Bitcoin Unlimited v1.0.0 which caused a mining pool to produce and broadcast an excessive block. Following that event, key contributors to Bitcoin Unlimited conducted an incident review to discover the incident’s timeline and impact, and identify key changes to our processes to avoid similar incidents in the future.

We determined that our technical description of the problem in our initial report was accurate. In addition, we learned of practices used by the impacted mining pool that exacerbated the issue, which we can anticipate in the future through better software error checking and documentation.

We also determined that our initial report of the impact was accurate: The impacted pool lost one block worth of mining revenue.

To conclude the incident review, the BU team met to discuss root cause of the incident and identify key areas of process improvement needed to deliver higher quality software. We determined that the following areas contributed to the incident:
  • Coordination of the code review process
  • Documentation of suggested software configuration, and consequences for deviating from this configuration
  • Appropriate tagging of software versions to reflect production readiness
Some of key areas we identified and for which we are implementing changes include:
  • Adding additional requirements to merging code into releases
  • Increasing code review coverage and specificity
  • New guidelines for proposed changes to code to improve ease-of-review
We thank the community for their support following this incident and look forward to future software releases that will include improvements and much-needed, on-chain scaling enhancements to Bitcoin.

To learn more about Bitcoin Unlimited, please read our FAQ.

special thanks to
  • Like
Reactions: Bloomie