Release Notes for BU versions 1.0.0 &


Staff member
Aug 22, 2015
Bitcoin Unlimited 1.0.0 & Release Notes

The third official BU client release reflects our opinion that Bitcoin full-node software has reached a milestone of functionality, stability and scalability. Hence, completion of the alpha/beta phase throughout 2009-16 can be marked in our release version 1.0.0.

The most important feature of BU's first general release is functionality to restore market dynamics at the discretion of the full-node network. Activation will result in eliminating the full-blocks handicap, restoring a healthy fee-market, allow reliable confirmation times, fair user fees, and re-igniting stalled network effect growth, based on Bitcoin Unlimited’s Emergent Consensus model to let the ecosystem decide the best values of parameters like the maximum block size.

Bitcoin Unlimited open-source version 1.0.0 contains a large number of changes, updates and improvements. Some optimize the Emergent Consensus logic (EC), others improve the system in a more general way, and a number of updates are imported from the open source work of the Bitcoin Core developers who deserve full credit for their continued progress.

Changes are as follows:

Emergent Consensus (EC)

✦ Set Accepted Depth (AD) to 12 as default.

BU has a “sticky gate” (SG) mechanism which supports the functioning of EC.
SG means that if blocks are propagated which are bigger than a specific node's “Excessive Block Size” (EB) and subsequent blocks reach the node's "Acceptance Depth" (AD), then the node accepts, for 144 blocks, every block up to the size of its EB * 16. This mechanism is needed to ensure that nodes maintain consensus during an uptick in the network's record block size seen and written to the blockchain.

In co-operation with Bitcoin XT a potential attack on SG has been identified.
A minority hash-power attacker is probabilistically able to produce AD+1 blocks before the majority produces AD blocks, so it is possible that a sequence of very large blocks can be permanently included in the blockchain.
To make this attack much less likely and more expensive, the standard setting for Acceptance Depth is increased to 12. This value is the result of analysis and simulation. Note that due to variation in node settings only a subset of nodes will be in an SG situation at any one time.

Bitcoin Unlimited recommends miners and commercial node users set their Accepted Depth parameter to the value of 12.

Further information:
Discussion of Sticky Gate / the attack
Table with result of simulation

✦ Flexible Signature Operations (sigops) Limit and an Excessive Transaction Size

When a Bitcoin node validates transactions, it verifies signatures. These operations – Signature Operation, short SigOps – have CPU overhead. This makes it possible to build complex transactions which require significant time to be validated. This has long been a major concern against bigger blocks that tie up node processing and affect the synchronicity of the network, however, a "gossip network" is inherently more robust than other types.

BUIP040 introduces several changes to mitigate these attacks while adhering to the BU philosophy. The pre-existing limit of 20,000 per MB block size is enough to enable a wide scope of transactions, but mitigates against attacks. A block size of 1 MB permits 20,000 SigOps, a max block size of 2 MB permits 40,000 SigOps and so on.

Attention: As this fix is consensus critical, other implementation which allow blocks larger than 1MB should be aware of it. Please refer to BUIP040 for the exact details.

Additionally BU has a configurable "excessive transaction size" parameter. The default maximum size is limited to 1MB. Blocks with a transaction exceeding this size will be simply rejected.

It is possible to configure this value, in case the network has the capacity and business use-cases for allowing transactions >1MB. The command for the bitcoin.conf is net.excessiveTx=1000000. But it is not expected that a change in this setting will be network-wide for many years, if ever.
Attention: It is recommended to use the defaults.

Further information:
Github Repository PR#164
Discussion and Vote on BUIP40

✦ Removal of the 32 MB message limit

Satoshi Nakamoto implemented a 32MB message limit in Bitcoin. To prevent any future controversy about a hard fork to increase this limit, BU has removed it in advance with the expectation that, when it will be reached years ahead, everybody will have already upgraded their software. The maximum message limit varies from node to node as it equals excessive block size * 16.

P2P Network

✦ Wide-spectrum Anti-DoS improvements

Network traffic represents a grey-scale of useful activity. Some helps the network to synchronize, while some is for surveillance and deliberate wastage. Bitcoin Unlimited differentiates useful and less useful data between nodes.

Useful data is primarily valid transactions and blocks, invitations for required data, and handshake messages. Not useful data is typically seen with spam or spy nodes. From version 1.0.0 Bitcoin Unlimited nodes track the quality of data from peers.

1) All traffic is tracked by byte count, per connection, so the "usefulness" of data can be measured for what each node is sending or requesting to/from a BU node. On inbound messages, useful bytes are anything that is NOT: PING, PONG, VERACK, VERSION or ADDR messages. Outbound are the same but include transaction INVs. Furthermore the useful bytes are decayed over time, usually a day.

2) if a peer node does nothing useful within two minutes then the BU node chokes their INV traffic. A lot of spam nodes normally listen to INV traffic, and this is first of all a security concern as it is undesirable to allow anyone to just try and collate INV traffic, but also it's a large waste of bandwidth. So, quickly they are choked off but are still sent block INV's in case they are blocks-only nodes.

3) If rogue nodes try to reacquire a connection aggressively a BU node gives them a 4 hour ban.

There are other types of spam nodes that will do this, so using these three approaches keeps BU connection slots available for useful nodes and also for the bit-nodes crawlers that are determining the node counts.

✦ Request Manager extensions

Bitcoin Unlimited uses a Request Manager that tracks source nodes for blocks and transactions. If a request is filled slowly, it reissues the same request to a different source instead of just waiting and eventually timing out. The Request Manager was introduced to stabilize Xthin block propagation, but is generally helpful to improve the synchronization of the mempool and to manage resources efficiently.

Because synchronized mempools are important for Xpedited (unsolicited Xthin) it is "bad" for them to be non-synchronized when a node loses track of a source. Also, if an Xpedited block comes in, some transactions may be missing so we can look up sources for them in the request manager! We don't want to request from the xpedited source if we can avoid it, because that may be across the GFC. It is always better to get the transactions from a local source.

With this release, the Request Manager’s functionality is extended to the Initial Blockchain Download (IBD). It eliminates slowdowns and hung connections which occasionally happen when the request for blocks receives a slow response.

Further information:
GitHub: PR79
GitHub: PR229

✦ Xthin block propagation optimizations

Based on many months of live traffic observation, Bitcoin Unlimited implemented several general optimizations of the block propagation with Xthin. As tests have shown, this enables some nodes to operate with zero missing transactions in a 24-hour period and thus achieves extremely efficient use of bandwidth resources and minimal latency in block propagation.

Last edited:


Staff member
Aug 22, 2015
Mempool Management

✦ Orphan Pool transaction management improvements

Not only blocks, but also transactions can be orphaned. A typical reason is when the transaction’s parent is missing in the mempool. In event of a growing backlog or of long transaction chains the number of orphaned transactions increases making management of the mempool resource intensive, further, it widens a vector for DoS attacks.

The orphan pool is an area that affects Xthin's performance, so managing the pool by evicting old orphans is important for bloom filter size management. The number of orphans should reduce once larger blocks occur and mempools are naturally of a smaller size. Occasionally they reach the current limit of 5000 and their source is not always clear: some might be intentionally created by some miners, or are an artefact of the trickle logic.

This release restricts the size of orphaned transactions and evicts orphans after 72 hours. This not only improves node operation, but the synchronization of mempool data improves Xthin efficiency.

Further information:
GitHub PR#42
GitHub PR#100


Command Tweaks

To allow a better organization of parameters in the command line or the bitcoin.conf, Bitcoin Unlimited introduces a new format using the dot notation. For example, to manage connections users can now specify "net.maxConnections" or "net.maxOutboundConnections".

Parameter access is unified -- the same name is used in bitcoin.conf, via command line arguments, or via bitcoin-cli (et al). Old parameters in the legacy format are still supported, while new parameters, like the excessive block size, are only implemented in the new format.
Try ./bitcoin-cli get help "*" to see the list of parameters.

Attention: Setting many of these parameters should be done by user with advanced knowledge.

✦ DNS-Seed

Whenever a new node starts, it needs to find its peers. Usually this is done by a DNS seed, which crawls the networks and builds a random list of other nodes to which the new node can connect to. Currently there are DNS seeds from bluematt, luke-jr, sipa, 21 and others. Bitcoin Unlimited aims to create its own DNS seed capable of special requirements such as supporting the service bit of XTHIN. By adopting and adjusting Sipa‘s code for a DNS seed Bitcoin Unlimited fixed a minor bug.

The DNS Seed of Bitcoin Unlimited is currently activated on the NOL (No Limit) Net, the testnet for Bitcoin Unlimited’s Emergent Consensus. It is expected to go live on the mainnet soon.

Further information
Github Sipa PR#42

Maintenance and Fixes

The release contains a variety of bug fixes, improvements for testing abilities and maintenance that have been implemented since v0.12.1. Major examples are:

Reorganisation of global variables to eliminate SegFault bugs

During tests it was discovered that the shutdown of bitcoind can cause problems. Sometimes the program wants to free memory which was used for global variables, while the memory is already free. This can result in the so called SegFault, a common bug of several C written programs. The cause for this bug is a mis-organisation of the destruction order used during the shutdown. By reorganizing global variables in a single file Bitcoin Unlimited fixed the destruction order and eliminates this bug. This is especially helpful for running bitcoind test suite.

Further information
GitHub PR#67

Lock order checking in debug mode

Bitcoin’s debug mode checks that locks are taken in a consistent order to eliminate the possibility of thread deadlocks. However, when locks were destructed, they were not removed from the lock order database. Subsequently, if another lock was allocated in the same memory position, the software would see it as the same lock. This causes a false positive deadlock detection, and the resulting exception limits the time that debug mode could be run to no more than a few days.

Further information
GitHub commit

ARM architecture

Version 1.0.0 has gitian support of deterministic builds for the ARM architecture. This supplements Windows, iOS and Linux x86, which were previously offered. This was backported from the Bitcoin Core project and adjusted for the Bitcoin Unlimited environment.

Imported Commits

✦ changes from the open source Bitcoin Core Project

Software development is a co-operative process, and especially when several teams work on open source projects, cooperation becomes a major source of success when all teams profit from the work of other teams. And while Unlimited and Core might disagree on some concepts and this disagreement sometimes dominates the public debates, both teams share the goal of an ongoing improvement of the codebase.

Bitcoin Unlimited has therefore cherry-picked a number of Bitcoin Core 0.13.x updates and upgrades which align with BU's onchain-scaling and wider goals to advance Bitcoin. We would like to thank developers Cory Fields, fanquake, Jonas Schnelli, MarcoFalke, Michael Ford, Patrick Strateman, Pieter Wuille, Russel Yanofsky and Wladimir J. van der Laan for their contributions.

commit list [to follow]

Previously disabled in BU version 0.12.0:

  • Replace-by-Fee [commented out]
  • Alert Key [commented out]

Special thanks to @Christoph Bergmann.

Last edited: