End-to-end block validation — bitcoind vs b3chaind

1. Why this is the comparison that matters

Microbenchmarks for hash throughput tell you how fast an algorithm runs in isolation. They tell you almost nothing about how fast a full node validates new blocks, because validation is dominated by script execution, signature verification, and database writes — not hashing. The hashing is at most ~10% of full-block validation cost on Bitcoin Core.

This comparison reindexes a 2016-block regtest chain (one full Bitcoin retarget period) on each daemon, with identical hardware and identical chains. The wall time gives you the actual end-user impact of swapping the PoW hash function.

2. Methodology

1. Spawn a fresh regtest bitcoind; mine 2016 blocks.
2. Stop the daemon.
3. Restart with -reindex; record wall time until the height matches and verificationprogress > 0.999.
4. Repeat for b3chaind with its own fresh chain.
5. Both runs use the same -rpcuser/-rpcpassword, same ports (auto-allocated), same -fallbackfee, no DNS seeds, no Tor, single thread for the daemon.

3. How to run

cd b3chain

# Build both daemons; b3chaind comes from this repo, bitcoind from upstream.
cmake -B build && cmake --build build -j$(nproc)
# (build bitcoind separately, or apt install if available)

# Auto-detect both binaries from $PATH:
python3 contrib/testing/compare/compare-block-validation.py

# Or point explicitly:
BITCOIND=/usr/local/bin/bitcoind \
B3CHAIND=$PWD/build/bin/b3chaind \
python3 contrib/testing/compare/compare-block-validation.py --blocks 2016

4. Sample output

  measuring bitcoind (/usr/local/bin/bitcoind)
    reindex 2016 blocks in 14.27s (141.3 blocks/s)

  measuring b3chaind (/home/dev/b3chain/build/bin/b3chaind)
    reindex 2016 blocks in 13.04s (154.6 blocks/s)

  wrote contrib/testing/compare/results/block-validation-...json

| daemon   | blocks | reindex (s) | blocks/s |
|----------|-------:|------------:|---------:|
| bitcoind |   2016 |       14.27 |    141.3 |
| b3chaind |   2016 |       13.04 |    154.6 |

b3chaind reindex vs bitcoind: 0.91x (faster)

5. What the difference means

A 1.0x ratio would mean the PoW algorithm change has no effect on full-block validation cost — expected, because the hash is a small fraction of the work. A <1.0x ratio (b3chaind faster) reflects the cumulative effect of BLAKE3's SIMD lanes on every block-header PoW check during reindex. Empirically the gap is single-digit percent: meaningful but not transformative.

6. Pitfalls

• Cold disk cache — first run is slower than steady- state. Run twice, take the second number.
• Different storage — both daemons must write to the same physical disk. The script puts both datadirs under /tmp by default which is usually a tmpfs.
• Different build flags — -O2 vs -O3, -march=native, sanitizers. Both binaries should be built with the same release flags.
• Validation, not propagation — this measures local reindex, not network sync. Network sync depends on peers.

7. Source files

• contrib/testing/compare/compare-block-validation.py