Build on Bitcoin: Critical Merged-Mining Bugs We Uncovered

This article explains merged-mining mechanics, security benefits, and critical vulnerabilities uncovered by Coinspect in real-world mining and block validation implementations. We provide practical insights and a conclusion for blockchain designers, developers, and researchers focused on building secure, interconnected networks. A future post will include technical details and source code for the examples discussed.

What is Merged-Mining?

Merged-mining, first proposed by Satoshi Nakamoto in a 2010 Bitcoin forum thread, offers a win-win solution for established and emerging blockchain networks. Despite its long-standing presence, the Build on Bitcoin movement brings merged-mining into the spotlight.

Merged-mining enables multiple blockchains to share mining infrastructure, allowing smaller chains to leverage the hashing power of more established networks. This approach increases the cumulative Proof of Work (PoW) across all the merged-mined chains, making it more difficult for attackers to compromise new blockchain networks.

How merged-mining Works

Let’s outline a simple merged-mining scheme. Due to its relative simplicity and widespread familiarity, we’ll use Bitcoin as an example.

Recap of Bitcoin’s Block Header

The Bitcoin block header consists of the following structure: Important concepts to remember:

1. When interpreted as an integer, the hash of the block header data must be lower than a target difficulty value (i.e., it starts with a minimum number of zeros for that block).
2. The Merkle Root is a cryptographically secure hash that enables the construction of Inclusion Proofs explained below.

Understanding the Merkle Tree

The Merkle Root Hash in the Bitcoin block header is the hash of the root node of a Merkle Tree. This tree structure is fundamental to merged-mining:

• Leaf nodes contain values (transactions in this case)

• Intermediate nodes are formed by hashing the values of their child nodes

This way, the root hash represents the entire content of the Merkle tree. Any bit change along the path will generate a completely different Merkle Root Hash, ensuring the integrity of the data.

Inclusion Proofs

The Merkle tree has an essential property that allows for the verification of data inclusion using a minimal set of information.

Given the Merkle Root Hash and a specific transaction, you can prove the transaction’s inclusion in the block by providing a series of intermediary hashes. This sequence of hashes, known as the inclusion path or simply the path, allows verification by reconstructing the path to the root, thereby confirming the transaction’s presence in the tree.

Example: Proving L2’s Inclusion

Let’s consider the Merkle tree in the image above and prove that L2 belongs to it: providing Hash 0-Left, Hash 1, and the position is enough to prove it.

Steps:

• Using L2 as input we calculate Hash 0-Right.
• Using Hash 0-Right and Hash 0-Left we calculate Hash 0.
• Using Hash 0 and Hash 1 we calculate the final hash, the Merkle Tree root.

If the final hash matches the known root, then we know that L2 is inside the tree. In our case L2 is a transaction and the known root will be taken from a bitcoin block header.

Block Generation

Now, let’s consider New Chain (NC), which aims to adopt a similar block structure while accepting merged-mining as its Proof of Work (PoW).

The new chain will use a header similar to the original, but with additional merged-mining PoW data. In this new context, the nonce in the original header is no longer necessary, so the updated header structure will be as follows: The hash of this block header will be included in a Bitcoin transaction, typically the coinbase, and then the Bitcoin block will be mined normally.

Mining Process

When mining New Chain network blocks using Bitcoin’s mining pool algorithms, the goal is to find a block hash that meets both Bitcoin’s consensus and the New Chain’s specific difficulty target, which is often lower. If a pool’s miner finds a block that satisfies the New Chain’s difficulty target, the consensus requirement for the new network is met, allowing the New Chain’s nodes to accept the new block as valid.

Miners complete this process by submitting an NC block with the following structure: The block identifier in the New Chain will therefore be the hash of New Chain Hedaer version 2. While there are alternatives, this is the simplest version. Using the v1 hash is risky as it doesn’t contain the PoW as part of it.

Security Benefits of Merged-Mined Chains

For new blockchain networks, which typically have lower PoW power, the main advantage is that the cost of attacking a merged-mined chain increases significantly when miners are predominantly honest.

Maximizing Security

Maximizing security in merged-mined chains requires incentivizing a majority of miners to participate. By reusing existing infrastructure, miners can initiate mining on the new chain with minimal costs, creating profitable opportunities even if they lack a vested interest in the chain’s security. However, if incentives are poorly aligned, adversaries may exploit this by renting hashing power from miners, making attacks more feasible and less costly than targeting networks with dedicated PoW algorithms and infrastructure.

Selfish Mining Protection

In a selfish mining attack, the miner avoids publishing new blocks immediately to increase their relative hashing power against other miners. Other Bitcoin miners cannot detect or prevent this known attack.

However, this is different for merged-mined chains. If some miners attempt selfish mining on New Chain, they will still have to publish the valid Bitcoin blocks they find, or they’ll lose money. When these blocks are published, other NC participants will see the merged-mining attempt in the published block, but at the same time, they will not see the valid block in the NC blockchain. The exposure of the merged-mining evidence will allow them to take preventive measures against double-spend attacks, such as temporarily increasing the number of block confirmations before accepting a payment.

Reorganization Prevention

Merged-mining can also prevent attempts to produce extensive chain reorganizations (reorgs) on the network. During merged-mining, the NC protocol can access and verify the timestamp of the corresponding Bitcoin block. The system creates a time-based anchor by enforcing a link between the Bitcoin block timestamp and the NC block’s timestamp. Consequently, any attempt at a long reorg would require adversaries to mine Bitcoin blocks with invalid timestamps, significantly increasing the attack’s cost and complexity.

Real networks like Rootstock implement these protective measures; we’ll describe them in detail in future blog posts.

Miner Implementation Pitfalls

For miners, merged-mining adds an extra profit opportunity. However, this comes with additional risks and costs. To include merged-mining capabilities, miners use a modified version of mining pool software. For example, CKpool. With merged-mining enabled, the pool server must now connect not only to the Bitcoin node but also to a New Chain node.

Invalid Blocks and Loss of Rewards

The first risk for miners lies in bugs introduced by modifications made to the mining pool software. A mining pool with merged-mining capabilities becomes more complex and therefore more susceptible to bugs. A possible error when integrating merged-mining into a mining pool is that the blocks produced may no longer be valid for the Bitcoin network.

In 2017, a bug in mining software left a Bitcoin block without a reward, and it was rumored that this could have been due to an error in the merged-mining implementation. In Bitcoin block 501726, the mined block was valid for Bitcoin consensus rules, but the miner received 0 rewards.

Solution

Miners must carefully develop and thoroughly review the modifications made to their mining software source code to identify implementation issues. By adhering to secure development practices and conducting both internal and third-party source code audits, vulnerabilities can be identified and resolved before they reach production.

Increased Update Frequency and Cost

Another issue that arises in mining pools is related to the timing and method of updating miners’ work. A Bitcoin mining pool typically updates miners’ work in two instances:

1. When a new block appears
2. At regular time intervals

This update has an associated networking and time cost. When adding a new network, it’s tempting to update the work in a third instance:

3. When there’s a new block on the new network.

This generates an increase in the cost and complexity of managing mining pools. To a large extent, this is because many new chains aim to reduce the time between blocks.

This complexity increases with the number of merge-mined chains supported by a single pool.

There’s also an additional cost related to the proper inclusion of NC’s mining hash. This reduces the transaction space for other transactions. However, merged-mining benefits will likely exceed this cost.

Solution

One solution is to incorporate uncle blocks into the difficulty adjustment algorithm. The network’s difficulty is typically adjusted based on the time between blocks. However, if this increases miners’ costs, the merged-mining network can modify its consensus to maintain fixed costs.
Uncle blocks are generated when multiple miners create different blocks at the same height, considered sibling blocks. In Ethereum’s PoW system, these uncles increase the chain’s weight without affecting difficulty adjustment.

The network consensus rules can support miners struggling with high work update frequency by counting blocks with uncles as valuable as multiple mainchain blocks. This approach increases the average time between blocks but allows more miners to participate.

Incorporating solutions like these requires niche expertise and careful implementation. For over a decade, Coinspect has guided early-stage blockchain projects, offering the strategic advice and technical insight needed to build secure networks from the ground up.

Block Validation Challenges

The validation of PoW in the NC nodes is possibly the most sensitive aspect of merged-mining. The primary goal is compatibility in mining both chains simultaneously. Anyone who wishes to mine NC should always be mining Bitcoin at the same time. However, mining Bitcoin in parallel will not be a requirement to mine NC. Due to simple incentives, it’s possible that potentially all NC miners will pursue this dual mining approach (or perhaps miners of some blockchain with the same PoW algorithm).

Work Reuse

A fundamental rule in every Proof of Work system is that each attempt to find a valid PoW hash for the current network difficulty must be tied to a single, specific block. If a poor merged-mining implementation breaks this rule, it could lead to security vulnerabilities where miners can exploit the system by using the same work for multiple blocks. For example, if the NC v1 header hash is expected to be found in a Bitcoin transaction, nothing prevents multiple transactions from containing different hashes of valid NC blocks.

Solution

Given that merged-mining is performed by miners, it’s possible to require that the desired hash be forcibly found in the coinbase transaction. Even so, this could allow multiple hashes to be included in the same coinbase, so an extra criterion will need to be selected to define its uniqueness. If the hashes of the blocks to be mined are identified with a prefix, it can be required that this prefix appears only once in the entire coinbase. In this case, we could ensure that only one block is being mined at a time.

Malleability Enables Denial-of-Service Attacks

Another common source of errors is simply reusing partial Merkle tree validation libraries without additional considerations. The first problem is malleability.
Remember that the Merkle inclusion proof will be part of the NC header and therefore will affect its hash. Bitcoin’s Merkle proofs have multiple possible encodings. Once an NC block is mined, publishing the same block with different Merkle proof encodings will result in different NC blocks. All at the same height and with the same transactions, but an attacker could abuse this property to divide the work of hashing power between different branches and increase their relative hashing power capacity. Alternatively, they could consume network resources, spending bandwidth and CPU validating blocks of all nodes in the system.

Solution

The encoding of Merkle inclusion proofs must be guaranteed to be unique. While the specifics will vary in each case, minimizing the information that needs to be part of the proof—such as the Bitcoin header, coinbase, and intermediate hashes—is generally possible using fixed values or predefined encodings in malleable fields. Alternatively, developers can address the root cause by implementing custom proof verification and encoding routines. However, custom implementations must undergo rigorous testing and expert review to ensure reliability and security.

Unlimited Block Size Escalates to Double-Spend

Unlimited block size is a significant issue for blockchain systems, especially those attempting to be decentralized. Excessive block size increases network bandwidth consumption and disk space requirements, increasing cost for nodes’ operators – and, in this case – without a proportional benefit. It also opens the door to Denial-of-Service attacks which, in many cases, can be escalated into double spend or other critical issues.

We found a common error that enabled block size inflation attacks: not limiting the size of the inclusion proof.

We have seen this happen in two ways:

1. Allowing the coinbase to be at any level of depth in the tree
2. Permissive encoding.

In the first case, a malicious miner could generate blocks of any size simply by adding random hashes as intermediate nodes in the Merkle proof.

In the second case, permissive encoding and decoding libraries allow additional trailing data in the inclusion proof that is part of the block but is ignored when decoded.

Other parts of the header are not susceptible to the same problem due to the nature in which this behavior is usually encapsulated when programmed. For a simple abstraction, the origina header fields are:
A new field is added using the original serialization format, the field includes: Bitcoin Header, coinbase transaction, and inclusion proof. A simple error is that the first layer of header processing code ignores the content of each field and allows arbitrary PoW size, while the second layer that properly parses the PoW fails to enforce a maximum size. This missing check not only allows header inflation but would also add another form of malleability to the block.

Solution

Outer layers of the block processing code must enforce size restrictions even if the block serialization format is flexible. This type of problems can be missed if the different functions and libraries involved are reviewed in isolation. In our experience gray-box penetration testing and fuzzing are more effective than source code audits to identify this type of vulnerability.

Conclusion

Merged-mining is a powerful tool for protecting new blockchain networks from “51%” attacks while providing existing miners with additional incentive. However, it introduces complex software components that demand careful development. Implementation requires meticulous attention to detail to avoid potential vulnerabilities and ensure the security and efficiency of both the parent and merged-mined chains.

Coinspect’s L1/2 security services clients successfully fixed the vulnerabilities described in this article before they could impact production or reach a critical stage.
These vulnerabilities serve as illustrative examples rather than a comprehensive checklist. The complexity of innovative blockchain systems demands rigorous security measures beyond what we can cover in a single article. At Coinspect, we specialize in fortifying crypto projects from the ground up. By partnering with us early in your development process, we help you identify and mitigate weaknesses in your web3 systems before they evolve into critical issues.