Research report: Bitcoin software version changes in 7 years, where is the biggest change?

Source: BitMEX

Compilation: First Class (First.vip)

The BitMEX research team conducted 35 initial block downloads and used the initial block download time as an indicator of benchmark tests to test the performance of Bitcoin Core. Bitcoin software versions from 2012 to 2019 were used in the tests.

In this test, we used the Bitcoin software version from 2012 to 2019. The results show that the software has made considerable progress in performance, but there are also large differences. Even with the latest computer hardware, older versions of Bitcoin will struggle to overcome the obstacles to rising transaction volumes between 2015 and 2016. Therefore, we conclude that today's fast initial synchronization is almost impossible without enhancing software performance.

• Technical Dry Goods | Deep Understanding of Zcash's Zero-Knowledge Proof System
• Opinion: Three Common Misunderstandings of Blockchain Technology
• BTC and the "Great Wealth Transfer" of Millennials

Figure 1-Bitcoin initial block download time (days)-average time of 3 attempts

(Source: BitMEX research, Note: Block height is synchronized to 602,707)

Summary

To test the performance of Bitcoin Core during the initial synchronization, we tried 35 initial block downloads and recorded the time taken for each attempt. The results are shown in Figure 1, which shows that when Bitcoin Core 0.12.0 was launched in February 2016, the speed of Bitcoin has improved significantly due to the upgrade of signature verification from OpenSSL to libsecp256k1. (First-class warehouse note: After the 0.12.0 upgrade of Bitcoin Core software, the signature verification speed is increased by about 7 times.)

Libsecp256k1 is built specifically for Bitcoin. Since then, the pace of improvement in speed has been much slower. Due to the large difference in the initial block download time, significant improvements can only be seen after repeated download attempts. However, after the release of Bitcoin Core 0.12.0, 0.13.0 to 0.19.0.1 have been successively released, and the performance of each Bitcoin Core version has been gradually improved.

Of course, the initial block download time is only a measure, and the performance of Bitcoin Core can also be evaluated from other angles and conditions. Although the initial block download time (IBD) is not the best indicator of software performance, it consumes a lot of resources and is therefore a good indicator for benchmarking.

This report continues two previous experiments:

· In November 2018, Jameson Lopp tried a similar study, but the analysis focused on the independent implementation of the older version of Bitcoin Core (or simply "Bitcoin" because some older software was named Bitcoin before "Bitcoin Core") .

· Sjors Provoost also tried this experiment in July 2017, but Sjors had fewer syncs.

The complete test results and raw data are as follows

Figure 2-Bitcoin initial block download time (days)

(Source: BitMEX research)

(Note: The block height is synchronized to 602,707)

System specifications and other instructions

Complete results table

(Source: BitMEX research)

Result analysis

As shown in Figure 2, even when the initial software download is attempted using the same software and computers with the same specifications, the reported time also varies considerably.

Figure 3- Initial block download time and client release date (days)-average time of 3 attempts

(Source: BitMEX research)

(Note: For the Bitcoin 0.8.6 client, the above data comes from the average result of 2 attempts)

Figure 3 shows that except for the powerful performance of Bitcoin Core 0.12.0, the performance of other software has gradually improved with the release. However, although there is a clear performance improvement trend in Figure 3, there is a huge difference in the initial block download time for each attempt, which may indicate that there is considerable uncertainty in performance improvement. With regard to the conclusion that performance has continued to improve since 2016, more sample data is needed to be solid. This difference may be due to a connection problem with the Bitcoin P2P network or the Internet. So the best way for further research may be to rescan the speed, that is, the time required to fully verify the blockchain once it is downloaded.

Bitcoin Core 0.12.0 performed well in the above analysis. Probably because Bitcoin Core 0.12.0 enabled libsecp256k but did not verify the transaction input signature of the Segregated Witness. Therefore, Bitcoin Core 0.12.0 did not verify all the signatures of the blockchain after August 2017, which gave it some "unfair advantage".

However, Bitcoin Core 0.13.0 also has this advantage. Of course, all versions before 0.12.0 have the same "unfair" advantage, which dwarfs the disadvantages of using OpenSSL.

Sync client to its release date

Figure 4 illustrates the time required to synchronize a client to the block height of its release date.

Figure 4-Time required to sync initial block download to client release date (days)

( Source: BitMEX research)

(Note: Node data running on Linux. Bitcoin Core 0.19.0.1 only synchronizes block height to 602,707)

It can be seen from the figure that the change trend from Bitcoin Core 0.8.6 to Bitcoin Core 0.14.0 is relatively gentle. At this time, scalability does not follow the time and the growth rate of block height, but it also shows an upward trend. In recent years, the speed of software improvement has decreased. It may be that those improvements that are easy to implement have been achieved, and the rest are difficult to implement. Increased transaction volume may also be one of the reasons. Increasing scalability in the future may be more challenging. Even if the block height limit of 4 million is maintained, and further software upgrades and software performance improvements, the initial block download time will continue to increase.

Initial block download failed

We successfully compiled and ran versions prior to Bitcoin 0.8.6, but between 2015 and 2016, node synchronization slowed down. Pre-0.8.6 nodes, such as 0.7.0 nodes, successfully completed the hard fork in 2013 by manually changing the lock limit. However, due to the increase in transaction volume in 2015, the nodes suspended processing blocks. We restarted the node and it did help, but soon the node stopped again.

Later, we even ran the 0.7.0 version of Bitcoin Core on our new local computer (matching 64 GB of RAM and 8 Intel i9 processors), but this node still cannot cross 2016. Since many of the scaling parameters involved are non-linear parameters, this problem cannot be solved simply by investing more hardware in this problem.

When the node is stuck on a block, we will restart. After 4 restart failures, we give up synchronization. For 0.8.6 Bitcoin Core on MacBook Pro, the lead block stopped syncing in 2016. Although a little disappointing, the remaining 35 attempts were successfully synchronized without restarting.

in conclusion

In addition to being more cautious when publishing the BitMEX research report for MacBook Pros, the data also shows that the expansion performance over the past 7 years has greatly improved. The libsecp256k migration is the most important improvement. The drastic reduction in the initial block download time and the inability of the old nodes to fully synchronize indicate the importance of scalability to Bitcoin, otherwise even if users use the highest configuration hardware, Bitcoin is now basically dead. In addition, the data also shows that technological innovation is unlikely to be synchronized with the growth rate of the blockchain, and the initial block download time will continue to prolong.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!