FULL OFFLINE BITCOIN NODE (TRB) SYNC VIA EATBLOCK

What follows here is a summary of an offline bitcoin blockchain sync using trb and eatblock

Environment Info

• Dual Xeon 5650 Processors (24 core)
• 64 Gb RAM
• 1Tb SSD
• Gentoo Linux : hardened/amd64/no-multilib

Cutting Up The Files

In preperation for the test, I copied over blk0001.dat through blk0050.dat onto this environment. I then used asciilifeform's blkcut utility to break each of the .dat files into individual block files to be fed into the bitcoin node. Knowing this process would create 454`254 files, I created a directory for each of the .dat files prior to executing blkcut against the .dat file itself. This left me with 50 directories filled with extracted block files, the first of which had over 180`000 indiviual block files extracted from blk0001.dat!

To feed in all of the files sequentially (as required for eatblock) from each of the 50 directories (one per blk####.dat), I wrote a one line perl script to accomplish this task.

Running The Test

Test was started on April 18th, 2017. Full sync of all 50 cut apart blk####.dat files took about seven days. The final blockheight at the end of the sync was: 454`254.

It should be noted that to eat blocks in this offline fashion, you need to have built trb with asciilifeform_and_now_we_have_eatblock.vpatch and execute trb with the -caneat flag.

The vpatches built with the trb test node:

• genesis.vpatch
• bitcoin-asciilifeform.1.vpatch
• rm_rf_upnp.vpatch
• bitcoin-asciilifeform.3-turdmeister-alert-snip.vpatch
• bitcoin-asciilifeform.2-https_snipsnip.vpatch
• bitcoin-asciilifeform.4-goodbye-win32.vpatch
• asciilifeform_dnsseed_snipsnip.vpatch
• asciilifeform_zap_hardcoded_seeds.vpatch
• asciilifeform-kills-integer-retardation.vpatch
• asciilifeform_zap_showmyip_crud.vpatch
• asciilifeform_dns_thermonyukyoolar_kleansing.vpatch
• asciilifeform_and_now_we_have_block_dumper_corrected.vpatch
• mod6_fix_dumpblock_params.vpatch
• bitcoin-v0_5_3_1-static_makefile_v002.8.vpatch
• bitcoin-v0_5_3_1-rev_bump.7.vpatch
• asciilifeform_ver_now_5_4_and_irc_is_gone_and_now_must_give_ip.vpatch
• asciilifeform_orphanage_thermonuke.vpatch
• asciilifeform_and_now_we_have_eatblock.vpatch
• bitcoin-v0_5_3-db_config.6.vpatch
• asciilifeform_tx-orphanage_amputation.vpatch
• asciilifeform_maxint_locks_corrected.vpatch
• asciilifeform_lets_lose_testnet.vpatch
• asciilifeform_add_verifyall_option.vpatch
• programmable-versionstring.vpatch
• mod6_der_high_low_s.vpatch
• malleus_mikehearnificarum.vpatch
• makefiles.vpatch
• asciilifeform_wires_rev1.vpatch
• blocktimer.vpatch
• blackhole_revealer.vpatch
• blackhole_odometer.vpatch
• blackhole_reads.vpatch

debug.log Availble

I am making the entire gzip'd debug.log available for review here. [SHA512: a7560bbb80816a02ff8112529ca47849203790cf4913601a875b91db6091a5452d7abae2d2d371c7c7bc93f7fc2085c44b4fa691f456869eec82e8674957aac6] [22Mb Compressed / 190Mb Uncompressed].

Block Time Statistics

I collected statitics from the debug.log, many metrics were produced by asciilifeform's blocktimer vpatch.

• CheckBlock    : mean 5.22855545    (ms) :: median 1   (ms)
• AcceptBlock   : mean 1320.88250322 (ms) :: median 411 (ms)
• ProcessBlock  : mean 1326.21217769 (ms) :: median 413 (ms)
• DB Write Wait : mean 130.25303628  (ms) :: median 21  (ms)
• DB Read Wait  : mean 41.67201119   (ms) :: median 11  (ms)

In addtion, ProcessBlock Time (ms) v. DB Write Wait Time (ms) v. DB Read Wait Time (ms) has been plotted here. I did this with the gnuplot tool and the help of diana_coman. [Thanks!] Turned out pretty nice.

NMON Utilized To Collect System Statistics During Sync