Leveraging Bitcoin’s Security: Exploring theDynamics of Merged Mining

By Patricio Gallardo, Researcher Engineer

Merged mining, a mechanism that allows miners to contribute hashing power to multiple blockchains simultaneously, has positioned Rootstock as the most  secure and decentralized layer 2 fully aligned with Bitcoin’s technology and purpose. By leveraging Bitcoin’s robust hash rate, Rootstock also inherits strong security guarantees.

While merged mining is theoretically efficient, the real-world performance of Rootstock’s merged mining process depends on dynamics such as block time variability, sibling block production rate, and mining pool-specific implementations. These dynamics have a direct impact on Rootstock’s performance, particularly block time, which influences everything from transaction confirmation speeds to overall network stability.

In this article, we will dive into these dynamics, presenting findings from an in-depth exploration of Rootstock’s merged mining process to answer one key question:

How can understanding merged mining’s real-world dynamics help reduce Rootstock’s block time while maintaining network stability?

Through data-driven analysis and experimentation, we were able to reveal:

• The impact of block time variability on network efficiency.
• How mining pool behavior and template refresh intervals influence sibling block production.
• The role of Rootstock’s difficulty adjustment mechanism in maintaining stability.
• Simulation results on whether faster block times are feasible without compromising security.
• Proposed optimizations like RSKIP77 for smoother difficulty adjustments and RSKIP62 for improved block propagation.

Whether you’re a miner, developer, or blockchain enthusiast, this article will shed light on the performance of merged mining behind the scenes and reveal opportunities for optimization and improvement.

Disclaimer: The data analyzed in this article was collected before Foundry, a major mining pool, joined Rootstock. With Foundry’s participation, the share of Bitcoin’s total mining power securing Rootstock has increased, with the Bitcoin/Rootstock hashrate ratio now approaching 80%. While this new addition changes the distribution of mining power, it does not affect the core dynamics analyzed here, such as block template refresh rates, sibling block production, and difficulty adjustments. The trends, inefficiencies, and optimizations discussed remain relevant. We are currently working on a follow-up article that will incorporate Foundry’s activity into the analysis.

Experiment setup

To better understand Rootstock’s merge mining dynamics, we conducted an experiment designed to collect key metrics over a 24-hour period. The purpose of this experiment was to gather data on mining pool behavior, such as block generation times, block template refresh rates, and sibling block production.

The experiment included two main components:

• Logs: from a fully synced Rootstock node to collect block production times, sibling blocks (valid block that is mined almost simultaneously with another block but is not included as part of the main chain), mining pool addresses, and other relevant metrics.
• Dummy miner: a custom-developed dummy miner connected to various mining pools to collect block template refresh intervals. This process uses publicly accessible data and does not involve revealing any proprietary or sensitive information. The collected intervals are estimates and may not fully reflect precise pool behavior, but they provide a useful approximation for analysis.

All results presented in the following sections are based on these datasets unless explicitly stated otherwise.

Block time

At the time of this writing, Rootstock blocks are generated at an average interval of 24 seconds, a recent improvement from the previous 30-second interval. This reduction in block time is due to two key factors: mining pools improvements and how the difficulty calculation works, which will be discussed in the following sections. 

Although the average block time is 24 seconds, the time between blocks can vary significantly. Half of all blocks are created within the first 24 seconds, while the other half can take considerably longer, with values like 150 seconds.

This variability arises from the nature of the mining process, which follows a Poisson process. This behavior is independent of the specific hashing algorithm (such as SHA-256) and is instead a result of the probabilistic nature of mining, where each hash attempt has an independent chance of producing a valid block. This Poisson approximation applies to all Proof-of-Work blockchains, with each chain having its own block generation rate. While the number of blocks generated in a fixed time interval follows a Poisson distribution, the time between blocks follows an exponential distribution. The following figure illustrates a sample of this distribution for Roostock:

This variability in block times is crucial to consider when designing protocols aimed at achieving faster block times, as it can significantly impact protocol performance and network stability. This is one reason why many blockchains with super fast block production rates, such as Near, Solana, or TRON, have adopted Proof of Stake. However, the Bitcoin and Rootstock communities highly value the security and decentralization of Proof of Work, making it their preferred approach despite the challenges of variability.

This distribution also highlights why merge mining efficiency is not only about raw hash power but also about how mining pools optimize their mining algorithms to account for this variability. Inefficient mining algorithms can result in miners unintentionally working on the same block twice. In the case of Rootstock, this translates to the production of sibling blocks, which are referenced as uncles to secure the network. However, without the right balance, excessive sibling production can degrade overall network performance by overloading nodes with processing and network communication, and also reducing the block time as we will explore in the following sections.

Block template refresh

A block template is the data structure miners use to create valid blocks. In a mining pool, the block template is generated and refreshed by the pool operator, while individual miners rely on these templates to perform the actual hashing work. In Bitcoin mining, block templates are refreshed according to each pool operator’s policy, to include the most recent and profitable transactions submitted to the network. This ensures that miners maximize their rewards while working on up-to-date data.

For Rootstock, when mining pools delay template updates, they risk working on Rootstock outdated templates, which can lead to the creation of sibling blocks and reduce the overall frequency of main chain blocks.

While prior analyses suggested that mining pools refreshed their templates regularly every 20 to 30 seconds, the reality proved to be quite different. We conducted an experiment that revealed significant variation in template refresh intervals across pools, with some refreshing far more frequently than expected and others less frequently. 

By connecting a dummy miner to various pools and collecting data over approximately 19 hours, we observed the following average refresh intervals:

• Luxor: 10.85 seconds (6143 intervals recorded)
• AntPool: 11.71 seconds (5700 intervals recorded)
• ViaBTC: 13.94 seconds (4813 intervals recorded)
• SpiderPool: 22.47 seconds (3023 intervals recorded)
• F2Pool: 24.45 seconds (2681 intervals recorded)
• SecPool: we couldn’t connect, no intervals recorded.

The results show that F2Pool and SpiderPool have significantly longer template refresh interval averages than other pools. This lag contributes to higher sibling block generation ratios, as miners in these pools are more likely to work on outdated templates. For instance, F2Pool’s 24-second refresh interval average aligns poorly with the current Rootstock average block time of 24 seconds. This means that, on average, F2Pool refreshes its template only once per block cycle, leading to increased chances of mining sibling blocks. In contrast, pools like Luxor and AntPool refresh their templates more frequently, allowing them to produce fewer siblings and more main chain blocks.

To complement these results, the following histograms provide a more granular view of the template refresh interval distribution for each mining pool:

These histograms provide insight into how each mining pool’s refresh logic might be affecting Rootstock’s overall mining performance:

• Luxor and AntPool: both distributions are heavily concentrated in the first 12 seconds, with a fairly uniform spread up to 32 seconds. This indicates consistent refresh behavior that aligns well with Rootstock’s average block time, minimizing the chances of generating sibling blocks.
• ViaBTC: although its average refresh time is 13.94 seconds, its distribution features a tail extending beyond 30 seconds. This suggests occasional variability in refresh times and some potential for sibling block production.
• SpiderPool: in addition to its average refresh interval of 22.47 seconds, SpiderPool’s refresh times show considerable irregularity, with a pronounced peak at 32 seconds. This irregular pattern increases its chances of generating sibling blocks.
• F2Pool: the distribution is significantly wider than the others, with a peak near 52 seconds. This reflects infrequent and irregular template refreshes, resulting in a much higher likelihood of producing sibling blocks, making it the least efficient among the analyzed mining pools.

Sibling blocks

Sibling blocks are a key dynamic in Rootstock’s merge mining process, contributing to network security while also highlighting inefficiencies in mining behavior. To better understand their impact, we extended the analysis of block template refresh intervals. The following plot shows the number of main blocks and sibling blocks produced by each mining pool during a random period:

To further highlight the impact of sibling block production on mining pool performance, the following figure extends the previous analysis by showing the percentage of main blocks versus sibling blocks for each mining pool.

This result highlights how differences in template refresh times, as discussed in the previous section, influence the number of main and sibling blocks produced by each pool. For example:

• AntPool, Sec Pool, and Luxor show low sibling block percentages, indicating more efficient mining strategies.
• In contrast, SpiderPool and F2Pool have over 70% of their mined blocks as siblings, suggesting inefficient mining strategies.

These findings confirm the connection between template refresh behavior and sibling block production, with inefficient refresh logic leading to a higher ratio of sibling blocks.

High sibling block production, like that seen in F2Pool, slows the network. This is because the Rootstock difficulty adjustment algorithm, as we explore in the next section, considers both main blocks and sibling blocks when determining difficulty. This means that as sibling block production increases, the overall difficulty rises, resulting in slower block times and reduced network efficiency.

Difficulty calculation

Rootstock’s difficulty adjustment mechanism is designed to maintain a target block time of approximately 14 seconds (source code). However, the process takes into account not only the main blocks but also the sibling blocks, referred to by the Rootstock consensus protocol as uncles. While this design ensures security and fairness, it introduces certain inefficiencies.

The following is an excerpt of the difficulty calculation code implemented by the Rootstock node, which can be found here:

private static BlockDifficulty calcDifficultyWithTimeStamps(
long curBlockTS,
long parentBlockTS,
BlockDifficulty pd,
int uncleCount,
int duration,
BigInteger difDivisor,
BlockDifficulty minDif) {
long delta = curBlockTS - parentBlockTS;
if (delta < 0) { return pd; } int calcDur = (1 + uncleCount) * duration; int sign = 0; if (calcDur > delta) {
sign = 1; // increase diff
} else if (calcDur < delta) {
sign = -1; // drops diff
}

…
}

This calculation considers the following parameters:

1. Delta: the time difference between the current block and the previous block.
2. UncleCount: siblings of parent blocks referenced by the current block.
3. Duration: The target average block time (=14 seconds as we mentioned before).

The logic can be summarized as follows:

• If the current block is being mined faster than the target duration, the difficulty increases.
• If the current block is being mined slower than the target duration, the difficulty decreases.

There are 2 key consequences of the implemented difficulty calculation. The first key consequence lies in the short-term variability of block times caused by the exponential distribution of block generation. Rootstock’s current algorithm primarily considers the last two blocks when adjusting difficulty, which leads to noisy and overly reactive adjustments, as shown in the graph below:

To address this, RSKIP77 proposes a smoother difficulty adjustment algorithm. This approach would calculate difficulty based on a longer history of blocks, reducing the impact of short-term variability. By considering more blocks, the adjustment would respond more gradually to changes in block times, creating a more stable block production process.

The other key consequence is that including sibling blocks in the difficulty calculation can exacerbate the difficulty fluctuations. Pools that generate a high number of sibling blocks (e.g., F2Pool) artificially increase the network’s difficulty, making it more difficult to generate main blocks as well. This results in slower block times across the network.

Reorganizations

Reorganizations occur when a previously accepted block is replaced by a new block, usually because miners do not have an updated view of the blockchain. This can happen, for instance, due to latency in block template refreshing or network delays. While some level of reorgs is inevitable in blockchain networks, excessive reorganizations can disrupt transaction finality and harm network stability.

The analysis of block template refresh rates revealed how critical template refreshing is to network performance. In addition to reducing sibling block production, lower template refresh intervals also reduce the likelihood of reorganizations (reorgs).

Analyzing the data sample, we detected 371 reorganizations out of 3,717 blocks, resulting in a reorganization ratio of 0.14 reorgs per block, approximately 1 reorg for every 7.3 blocks. These low rates of accidental reorgs highlight the importance of reducing block transmission latency and improving template refresh logic across mining pools.

Rootstock has implemented an important improvement to block propagation, reducing latency and indirectly lowering the likelihood of reorganizations. This change optimizes propagation by prioritizing the broadcasting of new blocks over their execution. However, further enhancements are possible, such as the RSKIP62 proposal, which introduces Compressed blocks. This approach focuses on transmitting only the essential information required to reconstruct a block, rather than the entire block, significantly reducing data transmission size and enabling faster propagation.

Simulation

Based on the analysis in the previous sections, we developed a merge mining simulation to explore Rootstock’s network dynamics in greater depth. This simulation focuses on validating key observations, such as the relationship between sibling block production, template refresh intervals, and network difficulty. It also explores whether it would be feasible to target a block time lower than 14 seconds while maintaining network stability and security.

The simulation reflects the exact current mining status of Rootstock, including the same number of mining pools, hash rate distribution, and block template refresh intervals. This approach ensures that the results closely mirror real-world conditions, allowing for an accurate exploration of the relationship between sibling block production, template refresh intervals, and network difficulty.

The following table illustrates the results of a simulation, providing insights into how reducing mining difficulty impacts block time and sibling block generation.

Each row shows key metrics and parameters:

• Baseline: the first row represents the current status of Rootstock.
• Mining difficulty reduction: the percentage decrease in mining difficulty.
• Avg. block: the average time (in seconds) between all blocks (main and uncles).
• Avg. main block: the average time (in seconds) between main blocks.
• Block and main block time reductions: the percentage improvement in block and main block times compared to the baseline.
• #blocks and #uncles: the total number of main blocks and uncle blocks generated during each scenario.
• Uncle ratio: the ratio of uncle blocks to main blocks.

As the mining difficulty is reduced, the simulation shows a clear trade-off: block times decrease, producing more blocks in less time, but sibling block generation increases significantly. For example, at 65.7% difficulty reduction, the average new block time drops to 11.36 seconds, but the uncle ratio rises to 1:1.06, meaning sibling block production starts to exceed main block production. At extreme reductions like 99%, the network becomes flooded with sibling blocks, reaching a ratio of 1:5.07.

This simulation illustrates how difficulty reduction requires careful balancing to avoid destabilizing the network with excessive sibling blocks. Not only would the network need to process a significantly higher volume of main and sibling blocks in a short period, but the increased sibling ratio would also raise the likelihood of reorganizations. Furthermore, with more sibling blocks being generated, miners may struggle to keep their view of the blockchain updated, increasing the likelihood of reorganizations.

Conclusion

This analysis unveils practical insights into Rootstock’s merge mining process, diving into block time variability, block template refresh rates, sibling block production, and the impact of these dynamics on network stability. The findings highlight the importance of optimizing mining pool behaviors, such as template refresh intervals, to minimize sibling block production and improve network efficiency.

Implementing RSKIPs like RSKIP77 for smoother difficulty adjustments and RSKIP62 for compressed block propagation can tackle issues like latency, and network synchronization.

Another potential improvement is refining the difficulty calculation algorithm to reduce the weight of sibling blocks in difficulty adjustments. This could help lower block times while maintaining network security.

The simulation looked into whether Rootstock’s block time could be reduced below 14 seconds. It showed that faster block times are possible, but also highlighted the need to lower difficulty gradually. This approach would help avoid problems like too many sibling blocks and more frequent reorganizations, keeping the network secure and efficient as block times get faster.

In conclusion, optimizing Rootstock’s merge mining process requires balancing faster block times with network stability. By leveraging the insights gained from the analysis, implementing targeted RSKIPs, and adopting a measured approach to difficulty adjustments, Rootstock can continue to enhance its performance while remaining aligned with Bitcoin’s core principles.