This is a continuation of TradeBlock’s block chain and network analysis to address the ongoing block size discussions. It is intended for an audience with at least a fundamental comprehension of block chain technology. If you have not yet done so, we recommend first reading:

Part 1: Macro Block Trends

Part 2: Macro Transaction Trends

Part 3: Miner Incentives

Part 4: Simulating Practical Capacity

Part 5: Stress Test Analysis

Part 6 – Data Propagation

The timely propagation of data within the bitcoin network is essential to the functioning of the ecosystem. Propagation speed can be measured by connecting to a large number of nodes in the network and collecting/storing data on a real-time basis. TradeBlock maintains an extensive bitcoin network data architecture with multiple nodes across geographies. With the ability to view and record every message broadcast to the network, including those that are not extensively relayed, unique insights regarding the network may be derived.

The chart above shows the average block propagation speed in 2015. This is measured by tracking when each node on the bitcoin network relays the block data, and then calculating the time between the very first relay and all subsequent relays. In this piece we explore various aspects of data propagation within the network, how it could change with larger block sizes, and the impact on miner incentives and behavior.

Propagation Speed and Orphan Races

When two or more miners solve a block at similar times, the network is presented with two (or more) alternatives to serve as a reference when solving the next block. Since miners focus their hashing power on the chain with the most work, which generally means the longest chain by number of blocks, speed of propagation is vital during such situations. Generally speaking, the block with greater number of node relays has higher chances of “winning the race” when it is built on by the next found block.

Moreover, the block that is rejected, known as ‘orphan block,’ is not referenced by following blocks and the miner associated with that block does not receive the coinbase reward. The chart below shows the number of orphan blocks mined each day since mid-April. The average equates to 1.3 blocks per day, which translates to an orphan rate of roughly 1%.

The figure below delves a step further into orphan races observed within the last three months. Notwithstanding a few scenarios, it is evident that unsuccessful blocks typically reach a fewer number of nodes (relative to the winners of an orphan race). While there are roughly 6,000 nodes active in the bitcoin network at a given time, the data suggests reaching 3,000 node relays offers 90% certainty that a particular block will win an orphan race. Lastly, it appears that in most orphan races, the winning block is typically the first to be initially sent to the network, evidenced by the fact that majority of races are in the positive section of the x-axis in the chart below.

Next, we examine the size of confirmed blocks that were involved in an orphan race relative to period averages. The chart below suggests that blocks in an orphan race are, on average, ~100kb / 20% larger than regular blocks that are not part of such races. This is likely the result of larger blocks taking longer to relay.

For each marginal transaction in a block, every node must reconcile its own mempool against the block’s transaction list to ultimately validate the block. As a result, each transaction can potentially add more time at each hop through the network, in addition to increased data transfer time. This means other miners are spending more time hashing on the previous block while found blocks are being propagated.

Propagation Speed vs. Block Size and Miner

Given the importance of timely data propagation, we analyzed the relationship between speed of propagation relative to block sizes and miner location. Our data set includes data from April – June 2015. Per the chart below, there appears to be a direct relationship between the size of the block and the time taken to reach the critical 3,000-node relay threshold discussed earlier in this analysis. For instance, a 700kb+ block takes ~17 seconds to propagate, while a 200-300kb block takes only 6 seconds.

We also explored the relationship between individual miners and the average time taken for a block to propagate to 3,000 nodes. With an average time of 9.7 seconds and a median of 7.2 seconds, it appears most miners fall within one standard deviation of the mean. Outliers include BW Pool, a Chinese mining entity on the high-end (21 seconds) and Polmine, a Polish mining company on the low-end (4 seconds).

By tagging each block with the relevant miners’ geographic location, we can develop a broader view of propagation time across geographies. Per the second chart below, it appears regional differences account for very minor variations in propagation speeds. Overall, European miners exhibit slightly faster-than-average speeds, while Chinese and US propagation speeds are roughly the same (when adjusting for BW Pool).

It’s possible data from the Chinese-mined blocks are only measurable once outside the ‘Great Firewall,’ making true propagation times unknown. That said, with TradeBlock connected to low-triple-digit nodes relaying data from Chinese IP addresses, it seems likely that we would observe those blocks in a timely manner from behind the firewall.

Implications for Block Size Debate

The analysis above has important implications for the ongoing block size debate. We have shown that (1) there is a direct relationship between the size of the block and the time taken to propagate through the network and (2) blocks involved in an orphan race are significantly larger, on average, than blocks that are not in a race.

Utilizing the realized propagation speeds for block sizes up to 1MB, we can extrapolate propagation times for larger block sizes. Per the figure below, a best-fit linear regression implies that it would take approximately 137 seconds for a full-sized 8MB block to propagate through the network, assuming technical performance observed to date.

Although our assessment in Part 2 appropriately suggests that one should not expect full 8MB blocks in the near-term, the implication of roughly two additional minutes of propagation time could be viewed as material in the future. Every second of delay further increases the probability of a competing block being mined, which consequently disincentivizes miners to include more transactions. Several solutions to this problem have been proposed, including mining backbone networks, transaction cache updates and Invertible Bloom Lookup Tables; but until these are implemented, large block propagation may pose quantifiable risk to mining returns.

View live block chain data with TradeBlock’s Block Chain tools.

This analysis has been prepared in good faith on the basis of information available at the date of publication without any independent verification. Schvey, Inc. does not guarantee or warrant the accuracy, reliability, completeness or currency of the information in this presentation nor its usefulness in achieving any purpose. Readers are responsible for assessing the relevance and accuracy of the content of this publication. Schvey, Inc. will not be liable for any loss, damage, cost or expense incurred or arising by reason of any person using or relying on information in this publication. This analysis may not be duplicated, shared, or reproduced in its entirety or in part for any reason without the expressed written consent of Schvey, Inc.