TL;DR
- Cypherpunk Jameson Lopp benchmarked seven Bitcoin node implementations for full blockchain validation speed
- Bitcoin Core 0.19 completed full sync to block 601,300 in just 399 minutes (6 hours 39 minutes)
- Bcoin, a JavaScript-based node, achieved an 18-hour 29-minute sync after major improvements
- Libbitcoin Node 3.6.0 finished in 27 hours 37 minutes with 100,000 UTXO cache
- The tests highlight significant progress in alternative node implementations over the past year
Renowned cypherpunk and Bitcoin infrastructure researcher Jameson Lopp has published his annual comprehensive comparison of Bitcoin node implementations, revealing dramatic performance improvements across the ecosystem. Testing seven different implementations against block height 601,300, Lopp’s benchmarks provide crucial insights into the state of Bitcoin’s decentralized infrastructure as the network continues to grow.
Running a fully validating node is fundamental to Bitcoin’s security model. As Lopp has consistently emphasized, full validation provides users with the strongest possible security and privacy guarantees — allowing them to verify every transaction and block without trusting any third party. But the computational cost of syncing the entire blockchain from genesis remains a significant barrier, making these performance tests critically important for the ecosystem.
Test Setup and Methodology
Lopp used the same benchmark machine he’s employed since 2018: a high-end consumer PC costing approximately $2,000, equipped with an Intel Core i7 8700 running at 3.2GHz with six physical cores, 32GB of DDR4-2666 RAM, and a Samsung 960 EVO 1TB M.2 NVMe SSD. To ensure a fair comparison, Lopp forced all implementations to verify every transaction signature across the entire blockchain history — bypassing the default optimization where most nodes skip signature verification for blocks older than a year or two.
This approach levels the playing field but also means the results represent worst-case scenarios. Most users running nodes with default settings would see significantly faster sync times, since signature verification is computationally the most expensive part of the validation process.
Bitcoin Core Continues to Lead
Unsurprisingly, Bitcoin Core 0.19 — the reference implementation used by the vast majority of the network — delivered the fastest sync at 399 minutes, or roughly 6 hours and 39 minutes. Lopp noted that the bottleneck remains firmly CPU-bound and that Core has likely extracted near-maximum performance from its codebase. The test used an oversized database cache of 24,000 MB to minimize disk I/O overhead.
Bitcoin Core’s dominance in sync performance is a testament to the years of optimization work contributed by hundreds of developers. While other implementations serve important niche purposes — alternative programming languages, different architectural approaches, or specific feature sets — Core remains the gold standard for raw validation throughput.
Alternative Implementations Show Striking Progress
Perhaps the most remarkable result came from Bcoin, a JavaScript-based implementation running on NodeJS. After struggling with heap crashes during the 2018 tests — requiring about a dozen attempts to find workable parameters — Bcoin completed the 2019 sync in 18 hours and 29 minutes. The Bcoin team had rewritten the block storage system and removed the UTXO cache after discovering it actually decreased syncing performance, changes that clearly paid off.
Gocoin 1.9.7, written in Go, finished in 19 hours and 56 minutes, though Lopp suspects it could have performed better. CPU usage never exceeded 50%, suggesting the implementation may not fully utilize hyperthreading on his 12-virtual-core machine. Despite this, Gocoin retains what Lopp calls “the best admin dashboards of any node.”
Libbitcoin Node 3.6.0, a C++ implementation focused on maximal correctness, completed its full validation sync in 27 hours and 37 minutes with a 100,000-entry UTXO cache. The most challenging aspect was removing hardcoded block checkpoints to force full validation, which required cloning the repository and modifying configuration files before compiling.
btcd’s Remarkable Resurrection
The btcd implementation, written in Go, tells perhaps the most interesting story. Once described by Lopp as “basically a dead project” after its original developers at Conformal abandoned it four years earlier to work on Decred, btcd has been revived under the leadership of Olaoluwa Osuntokun (known as roasbeef), who serves as the primary maintainer. His motivation is practical: the Lightning Network daemon (lnd) uses btcd as a library, giving the project a direct incentive to maintain and improve the codebase.
btcd v0.20.0-beta completed the sync in 3 days, 3 hours, and 12 minutes — still the slowest of the tested implementations, but a massive improvement over the previous year’s results. The team added better stall detection and faster pubkey parsing, enabling btcd to sync an additional year of blockchain data in less total time than the prior test. For a project that was effectively abandoned, this represents an extraordinary comeback driven by the Lightning Network’s dependency on its codebase.
Why This Matters
The health of Bitcoin’s node ecosystem extends far beyond raw benchmark numbers. A diverse set of well-maintained implementations strengthens network resilience — if a critical bug were discovered in Bitcoin Core, alternative implementations provide fallback options that could keep the network running. The dramatic improvements seen across implementations this year demonstrate that the developer ecosystem is vibrant and actively competing to build better infrastructure. As the blockchain continues to grow — block 601,300 represents roughly 10 years of transaction history — the ability to sync quickly from scratch becomes increasingly important for new entrants who want to verify the network independently. Lopp’s annual benchmarks serve as a vital pulse check on this critical dimension of Bitcoin’s decentralization.
Disclaimer: This article is for informational purposes only and does not constitute financial advice. Cryptocurrency investments carry significant risk. Always conduct your own research before making investment decisions.
core finishing in under 400 minutes while the js implementation took 18 hours. says everything about why core is still king
18 hours for a js implementation is actually impressive considering where bcoin was a year earlier. the gap is closing
bcoin at 18 hours with JS is actually insane. respect to the contributors, thats a lot of optimization for a language nobody expected to work for this
pruned_node_ bcoin at 18 hours is wild for javascript. devs at purse.io did serious work optimizing that IBD pipeline
Lopp testing against block 601,300 is solid methodology. block height benchmarks are the only way to compare node implementations fairly since difficulty and UTXO set vary wildly
core benefits from 10+ years of optimization though. fair comparison would be btcd or libbitcoin at the same maturity level
quant_shack the maturity gap is the real story here. core has 10 years of optimization baked in. btcd and libbitcoin are playing catch up with way fewer contributors
lopp has been doing these benchmarks for years and they keep getting better. alternative implementations are finally becoming viable for actual use
Lopp ran all 7 implementations against block 601300. would love to see the same test against block 870000 with current hardware and 10x the chain data
libbitcoin at 27 hours with a 100k UTXO cache. wonder how much faster it would be with modern hardware and a larger cache
399 minutes for core vs 27 hours for libbitcoin is not a fair fight. the real question is whether any alternative can get under 6 hours on current hardware
lopp benchmarks are gold but testing against block 601300 when were past 870000 is stale. someone needs to rerun this with a full chain
399 minutes for a full sync sounds fast until you realize thats only to block 601,300. try syncing from genesis now, its probably 3x that with current chain size
lotta b is right. the real benchmark is IBD from genesis now. 100k UTXO cache was generous for 2019 standards, modern nodes should use 1GB+
399 minutes to block 601300 is impressive but the chain has grown what, 3x since then? would love to see updated benchmarks on current hardware
utxo_cache_ the 100k UTXO cache was tiny even for 2019. Core defaults to 450MB now and syncs in under 5 hours on modern nvme drives
utxo_cache_ 399 minutes to block 601300 was on 2019 hardware. modern nvme with 1GB cache does genesis to tip in under 4 hours on core. the gap with alt clients is even wider now
4 hours genesis to tip on modern nvme is wild. remember when it took 2 days on a spinning disk in 2017
bcoin at 18.5 hours for full sync is actually impressive for a JS implementation. libbitcoin at 27 hours with 100k UTXO cache makes you appreciate core 6.5 hours
the gap between core and alternatives is why production nodes still run C++ despite the smaller talent pool. rust nodes might close it eventually but not soon
Bitcoin Core finishing in 399 minutes while Libbitcoin took 27 hours is not even close. the JavaScript implementation doing 18 hours is impressive though considering it started way behind
the C++ talent pool shrinking while rust keeps growing. give it 3 years and a rust node will be within 2x of core on IBD
ibd_racer_ C++ talent pool shrinking is real but the performance gap speaks for itself. rust nodes wont close 6x in a year no matter how much we want them to
Henrik J. modern NVMe doing genesis to tip in 4 hours is incredible. took me 5 days on a HDD in 2017. the hardware advancement did more for node accessibility than any software optimization
libbitcoin at 27 hours and people still run it. respect for decentralization but at some point you are just torturing yourself
node_tinker_88 libbitcoin users run it for ideological reasons not performance. 27 hours to validate the chain is a commitment to a specific vision of node diversity