Database Dumps
For some tasks like extracting lots of blockchain data (e.g. all transactions over a 2 month period) it’s better to use our dumps feature instead of using our API or other services. It’s possible to download the entire database dumps in TSV format and insert the data onto your own database server (like Postgresql or whatever) to further analyze it. Dumps are updated daily. The total amount of data available is over 1 Tb (compressed)!
Here’s the list of available dumps:
Our database dumps are available here: https://gz.blockchair.com, field descriptions are available here.
You can download 1 file at a time and the speed is limited to 10 kB/s. If you are a business or an academia/non-profit organisation that requires a higher speed, please contact us at .
Feel free to use our API as well. It allows to filter and sort samples and get aggregated data (for example, the average fee for transaction grouped by day or month) without downloading the entire set.
Full Node Dumps
Since syncing a full node can take quite some time (for example, syncing a full archival Ethereum node takes more than a month) we decided to make it possible to download data snapshots. Once you’ve downloaded a snapshot you’d need just to put it to a correct data folder and run the node.
Here is the list of snapshots we’re providing:
Our node dumps are available here: https://tar.blockchair.com
You can download 1 file at a time and the speed is limited to 10 kB/s. If you are a business or an academia/non-profit organisation that requires a higher speed, please contact us at .
Источник
Bitcoin’s Initial Block Download
Abstract: We test the performance of Bitcoin Core by successfully conducting 35 initial block downloads (IBDs) and recording the amount of time the node takes to synchronize with the network. We used software releases in the period spanning from 2012 to 2019. The results show a considerable and consistent improvement in the performance of the software, but also a high degree of variance. Even with the latest computer hardware, older versions of Bitcoin struggled to get past the pickup in transaction volume which occured in the 2015 to 2016 period. Therefore we conclude that without the software enhancements, an initial synchronization today could be almost impossible.
Figure 1 – Bitcoin Initial Block Download Time (Days) – Average Of 3 Attempts
(Source: BitMEX Research)
(Notes: Synchronization up to block 602,707. Further details in the notes below)
To test the performance of Bitcoin Core during the initial synchronization, we successfully conducted 35 initial block downloads (IBDs) and recorded the amount of time each attempt took. The results are shown in Figure 1 above and illustrate that there was a significant improvement in speed when Bitcoin Core 0.12.0 was released in February 2016, due to the upgrade from OpenSSL to libsecp256k1 for signature verification. Libsecp256k1 was built specifically for Bitcoin. Since then, the improvements in speed were much slower and due to the high variance in IBD times, the improvements are only clearly visible after multiple attempts. However, even after Bitcoin Core 0.12.0 was released in February 2016, a small gradual improvement in performance is still visible after each software release from Bitcoin Core 0.13.0 to Bitcoin Core 0.19.0.1.
Of course, IBD time is only one metric, and there are plenty of other angles and considerations that one can use to evaluate the performance and capabilities of Bitcoin Core. While the IBD time may not be the perfect or complete measure of overall software performance, it is highly resource-intensive and therefore potentially a good metric to benchmark.
This report follows on from two previous experiments:
- In November 2018 Jameson Lopp conducted a similar exercise , however that analysis focused on independent implementations, while this analysis focuses on older versions of Bitcoin Core (or just “Bitcoin”, as some of the older software pre-dates the name “Bitcoin Core”).
- Sjors Provoost also conducted this experiment in July 2017, although Sjors provided data for fewer synchronization attempts.
Full Results and Raw Data
Figure 2 – Bitcoin Initial Block Download Time (Days)
(Source: BitMEX Research)
(Notes: Synchronization up to block 602,707, further details in the notes below)
System Specification & Other Notes
640GB Flash Storage
dbcache=24000
maxmempool=500
Full Table of Results
(Source: BitMEX Research)
Analysis of the Results
As Figure 2 above illustrates, even when conducting the IBD with the same software and with a machine with the same specification, there is considerable variance in the reported times.
Figure 3 – IBD time vs Client Release Date (Days) – Average Time of 3 Attempts
(Source: BitMEX Research)
(Note: For the Bitcoin 0.8.6 client, the results above are an average of only 2 attempts)
Figure 3 above indicates that the performance of the software improved incrementally with each software release, with the exception of the strong performance of Bitcoin Core 0.12.0. However, despite the apparent clear trend in the above chart, the large variance and in IBD times on each attempt could indicate there is considerable uncertainty. One may need more sample data before drawing strong conclusions about improvements in performance since 2016. It is possible the variation is primarily caused by issues in the Bitcoin P2P network or the internet connection and therefore a good area of further study may be to compare the re-scan speed, the time taken to fully verify the blockchain once it has already been downloaded.
Bitcoin Core 0.12.0 performs well in the above analysis. This may be because Bitcoin Core 0.12.0 has libsecp256k enabled, but does not validate signatures for transaction inputs where the witness is segregated ( Segregated Witness ). Therefore Bitcoin Core 0.12.0 does not validate all the signatures in the blockchain post August 2017, giving the client somewhat of an “unfair advantage”. However this advantage may also apply to Bitcoin Core 0.13.0, despite this node not appearing to be an outlier. Of course all the versions prior to Bitcoin Core 0.12.0 have that same “unfair” advantage, but this is dwarfed by the disadvantages of using OpenSSL.
Syncing The Client Up To Its Release Date
The below chart ( Figure 4 ) illustrates the time it takes to synchronize a client, up until the block height on the date the software was released.
Figure 4 – IBD Time Up To Client Release Date (Days)
(Source: BitMEX Research)
(Note: Data for the nodes running on Linux only. Bitcoin Core 0.19.0.1 only synced up to height 602,707)
The chart shows that the trend was reasonably flat from Bitcoin Core 0.8.6 to Bitcoin Core 0.14.0, at that point the scalability improvements could not match the impact of time progressing and the blockchain increasing in height, and the chart shows an upward trend. Unfortunately the rate of software improvement has been reduced in recent years, perhaps as the low-hanging fruit improvements have already been made. Higher transaction volume may have also contributed to this. Future scalability improvements may be a lot more challenging, and even if the 4 million unit blockweight limit is maintained, IBD times may continue to increase going forwards, despite further software upgrades and moderate increases in hardware performance.
The Failed IBD Attempts
We did successfully compile and run versions of Bitcoin prior to 0.8.6, however, the synchronization became slow when the node reached the 2015 to 2016 period. The pre-0.8.6 nodes, such as 0.7.0, did successfully get past the apparent hardfork in 2013, by manually changing the lock limit , however 2015 proved too challenging due to the increased transaction volume, and the node stopped processing blocks. We tried restarting the node, which did help push it forwards, but then it only got stuck again. We then even tried running Bitcoin Core 0.7.0 on our brand new local machine, with 64 GB of RAM and 8 Intel i9 processors, however the node was still unable to get past 2016. With many of the scaling parameters involved being non-linear, one cannot simply throw more hardware at the problem.
On occasions when the nodes got stuck on a block and we re-started, we abandoned the synchronization after 4 restart attempts. For Bitcoin Core 0.8.6 on the MacBook Pro, the synchronization was abandoned when the leading block was in 2016. Although this is slightly disappointing, no restarts were required for the remaining 35 successful synchronizations.
Other than the fact that the BitMEX IT department should be more cautious when issuing BitMEX Research with MacBook Pros, the data illustrates the significant scalability enhancements which have been delivered over the last seven years. The transition to libsecp256k being the most significant improvement. The large reductions in IBD times and the inability of old nodes to fully synchronize indicates that if it were not for these scalability enhancements, by now Bitcoin would be essentially dead, even if users had the highest specification hardware available. The data also shows that technological innovation is unlikely to keep up with the growing blockchain going forward and that IBD times will increase.
Источник
Download — Bitcoin
Latest version: 0.21.1
Or choose your operating system
Bitcoin Core Release Signing Keys v0.11.0+ 01EA5486DE18A882D4C2684590C8019E36C2E964
Refresh expired keys using:
gpg —keyserver hkp://keyserver.ubuntu.com —refresh-keys
Check your bandwidth and space
Bitcoin Core requires a one-time download of about 400GB of data plus a further 5-10GB per month. By default, you will need to store all of that data, but if you enable pruning, you can store as little as 6GB total without sacrificing any security. For more information about setting up Bitcoin Core, please read the full node guide.
Verify your download
Download verification is optional but highly recommended. Click one of the lines below to view verification instructions for that platform.
Windows verification instructions
Click the link in the list above to download the release for your platform and wait for the file to finish downloading.
Download the list of cryptographic checksums: SHA256SUMS.asc
Open a terminal (command line prompt) and Change Directory (cd) to the folder you use for downloads. For example:
Run the following command to generate a checksum of the release file you downloaded. Replace ‘bitcoin-0.21.1-win64-setup-unsigned.exe’ with the name of the file you actually downloaded.
Ensure that the checksum produced by the command above matches one of the checksums listed in the checksums file you downloaded earlier. We recommend that you check every character of the two checksums to ensure they match. You can see the checksums you downloaded by running the following command:
If you haven’t previously installed GNU Privacy Guard (GPG) on your system, install it now or see other installation options.
Obtain a copy of the release signing key by running the following command:
The output of the command above should say that one key was imported, updated, has new signatures, or remained unchanged.
Check the output from the above command for the following text:
A line that starts with: gpg: Good signature
A complete line saying: Primary key fingerprint: 01EA 5486 DE18 A882 D4C2 6845 90C8 019E 36C2 E964
The output from the verify command may contain a warning that the «key is not certified with a trusted signature.» This means that to fully verify your download, you need to ask people you trust to confirm that the key fingerprint printed above belongs to the Bitcoin Core Project’s release signing key.
Click the link in the list above to download the release for your platform and wait for the file to finish downloading.
Download the list of cryptographic checksums: SHA256SUMS.asc
Open a terminal (command line prompt) and Change Directory (cd) to the folder you use for downloads. For example:
Verify that the checksum of the release file is listed in the checksums file using the following command:
In the output produced by the above command, you can safely ignore any warnings and failures, but you must ensure the output lists «OK» after the name of the release file you downloaded. For example: bitcoin-0.21.1-osx.dmg: OK
If you haven’t previously installed GNU Privacy Guard (GPG) on your system, install it now or see other installation options.
Obtain a copy of the release signing key by running the following command:
The output of the command above should say that one key was imported, updated, has new signatures, or remained unchanged.
Check the output from the above command for the following text:
A line that starts with: gpg: Good signature
A complete line saying: Primary key fingerprint: 01EA 5486 DE18 A882 D4C2 6845 90C8 019E 36C2 E964
The output from the verify command may contain a warning that the «key is not certified with a trusted signature.» This means that to fully verify your download, you need to ask people you trust to confirm that the key fingerprint printed above belongs to the Bitcoin Core Project’s release signing key.
Click the link in the list above to download the release for your platform and wait for the file to finish downloading.
Download the list of cryptographic checksums: SHA256SUMS.asc
Open a terminal (command line prompt) and Change Directory (cd) to the folder you use for downloads. For example:
Verify that the checksum of the release file is listed in the checksums file using the following command:
In the output produced by the above command, you can safely ignore any warnings and failures, but you must ensure the output lists «OK» after the name of the release file you downloaded. For example: bitcoin-0.21.1-x86_64-linux-gnu.tar.gz: OK
Obtain a copy of the release signing key by running the following command:
The output of the command above should say that one key was imported, updated, has new signatures, or remained unchanged.
Check the output from the above command for the following text:
A line that starts with: gpg: Good signature
A complete line saying: Primary key fingerprint: 01EA 5486 DE18 A882 D4C2 6845 90C8 019E 36C2 E964
The output from the verify command may contain a warning that the «key is not certified with a trusted signature.» This means that to fully verify your download, you need to ask people you trust to confirm that the key fingerprint printed above belongs to the Bitcoin Core Project’s release signing key.
Snap package verification instructions
While the Snap packages use the deterministically generated executables, the Snap tool itself does not provide a streamlined way to reveal the contents of a Snap package. Thus, the Bitcoin Core project does not have the information necessary to help you verify the Bitcoin Core Snap packages.
Additional verification with reproducible builds
Experienced users who don’t mind performing additional steps can take advantage of Bitcoin Core’s reproducible builds and the signed checksums generated by contributors who perform those builds.
Reproducible builds allow anyone with a copy of Bitcoin Core’s MIT-licensed source code to build identical binaries to those distributed on this website (meaning the binaries will have the same cryptographic checksums as those provided by this website).
Verified reproduction is the result of multiple Bitcoin Core contributors each independently reproducing identical binaries as described above. These contributors cryptographically sign and publish the checksums of the binaries they generate.
Verifying that several contributors you trust all signed the same checksums distributed in the release checksums file will provide you with additional assurances over the preceding basic verification instructions. Alternatively, reproducing a binary for yourself will provide you with the highest level of assurance currently available. For more information, visit the project’s repository of trusted build process signatures.
Bitcoin Core is a community-driven free software project, released under the open source MIT license.
Источник