Bitcoin Core running v07 and earlier versions

Author: Jameson Lopp

Source: https://blog.lopp.net/running-bitcoin-core-v0-7-and-earlier/

This article is one of the results of my research into the historical synchronization performance of all Bitcoin Core distributions, as well as the challenges of building really old versions (hard to find compiled binaries).

Note that if you plan to use these versions of Bitcoin Core to synchronize the blockchain, you will have a hard time. I'm not the first to explore this matter: during my research, I discovered that Sjors Provoost ran a similar experiment in 2017 and also documented it.

Performance of older Bitcoin Core clients – Sjors Provoost

Explore errors during synchronization

No version before v0.8.0 can be synchronized to the top of the current chain, for various reasons.

v 0.3 : Stopped synchronization at block height 12 4275, sending this error:

 ERROR: ConnectInputs() : fb0a1d8d34 VerifySignature failedInvalidChainFound: invalid block=0000000000004939267fheight=124276 work=6613870563198902508

At first glance, this isn't a particularly strange deal. However, if we examine the spending history of this Bitcoin address , we can see that the spender has constructed several strange transactions with hundreds of "0 value" outputs. It’s not a stretch to assume that this is a technician trying to disrupt the network.

Finally, what surprised me was the size of this input signature. 75 bytes is the maximum limit for signatures, and the signatures of most P2PKH transactions are 71 ~ 73 bytes.

You can read about the history of Bitcoin transaction signatures in the following article; it is noted that if you try to use a newer version of OpenSSL (1.0.0p / 1.0.1k) to follow the signatures that appeared on the earlier chain, you will An error is encountered because DER validation is more stringent and rejects certain types of encodings.

Changes in signature size in Bitcoin

The workaround is to either use an older version of OpenSSL to build Bitcoin Core or manually apply this code patch before starting the build. I was a little confused at first, because gitian builder uses Ubuntu 10.04 virtual machine as the build environment, and I thought it should be paired with an older (compatible) version of OpenSSL... However, Andrew Chow pointed out that they backported it in 2015 ( backport) this OpenSSL patch .

Both v0.4 and v0.5 stopped synchronizing at block height 25 8354, sending an error:

 EXCEPTION: 11DbExceptionDb::put: Cannot allocate memorybitcoin in ProcessMessage()ProcessMessage(block, 901212 bytes) FAILEDreceived block 0000000000000023e872REORGANIZE

This is noteworthy because it appears that 25 8355 was the first block to reach the 900 KB size; before that, almost all mined blocks only reached the default “soft cap” of 250 KB.

v0.6 stops synchronizing at block height 36 4670 and issues an error:

 EXCEPTION: 11DbExceptionDb::put: Cannot allocate memorybitcoin in ProcessMessages()ProcessMessage(block, 999787 bytes) FAILEDreceived block 000000000000000001d3

There are similarities here, as it appears that block 36 4671 was the first block to reach 1MB.

v0.7 stops synchronization in the same block, but the error log is different:

 received block 00000000000000000221ERROR: ConnectBlock() : UpdateTxIndex failedInvalidChainFound: invalid block=00000000000000000221 height=364671ERROR: SetBestChain() : SetBestChainInner failedERROR: AcceptBlock() : AddToBlockIndex failedERROR: ProcessBlock() : AcceptBlock FAILED

I guess v0.4 ~ v0.7 were all stopped for the same reason, but what was that reason? Is it the "BDB lock problem" (which caused an unexpected chain split in 2013)?Based on these instructions , I try to create a file ~/.bitcoin/DB_CONFIG :

 set_lg_dir databaseset_lk_max_locks 537000

But every version is still stuck at the same block height. It turns out that you also need to configure set_lk_max_objects , and the initial recommended value (537000) is not high enough (if you want to sync to block 70 0000). The following ~/.bitcoin/DB_CONFIG value works on my machine:

 set_lg_dir databaseset_lk_max_locks 1000000set_lk_max_objects 1000000

Performance results

You can see my rough sync results .

You can hardly see the data about v0.3 because it is almost identical to v0.4 and v0.5, which eventually crashed at block height 12 4000. Below is a logarithmic version to see it a little clearer.

It is worth mentioning that there is a turning point at block 19 0000, from where v0.4 starts to perform better than v0.5. My best guess is that this is the result of a "checkpoint". Bitcoin 0.3.2 introduced a mechanism called "checkpointing" to ensure that new full nodes do not spend a large amount of time during the initial block download verifying competing blocks that are not on the known best chain, thereby preventing denial of service attack.

Bitcoin 0.5.0 builds on these checkpoints to speed up synchronization by skipping signature verification on the blockchain prior to the most recent checkpoint. You may say, "Are you not mistaken? Can't you force nodes to verify all signatures by configuring assumevalid=0 ?" It is true, but this setting has no effect on Bitcoin Core earlier than v0.14. (v0.14 is the first time this configuration parameter was introduced .)

Therefore, I believe that v0.5 is overall slower than v0.4, and that the early sync performance tests are actually cheating/unfair comparisons.

Old version vs. new version

So, how much performance improvement does the latest v22 version have compared with these old versions?

Sync to block 12 4000:

• v22 is 17 times faster than v0.3

These blocks are all empty, so the performance difference is not that noticeable, but it becomes noticeable if more blockchains are synchronized.

Synchronized to block height 25 8000:

• v22 is 77 times faster than v0.4
• v22 is 83 times faster than v0.5

Sync to block 36 4000:

• v22 is 40 times faster than v0.6
• v22 is 38 times faster than v0.7

Forward compatibility is hard

You may often hear the statement that you can run a very old version of Bitcoin software and it will still be compatible with the current network. Of course, the real answer is much more complex and nuanced. In order to synchronize a very old version of the Bitcoin software to the current top of the chain, you need to make some changes to the software. Another tricky thing is that if you reduce it, not all the consensus-important code is written by Bitcoin developers - sometimes it is third-party libraries, and these libraries also change over time, making the software The constructed process itself becomes a possible cause of consensus failure!

(over)