0xB10C

{
  "hash": "000000000000000000006840568a01091022093a176d12a1e8e5e261e4f11853",
  "confirmations": -1,
  "height": 809478,
  "version": 708739072,
  "versionHex": "2a3e8000",
  "merkleroot": "eada52603fc0657892fe4dc8be490b0da68df4d2d8c7c50c44d9a3c3aec5df66",
  "time": 1695762922,
  "mediantime": 1695761041,
  "nonce": 1619870272,

0xB10C

0xB10C

[package]
name = "tester"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
octocrab = "0.23.0"
tokio = { version = "1", features = ["macros", "rt-multi-thread"] }

0xB10C

0xB10C

$ grep -E '^\|' printblocktree.txt 
|\
| 90392 (1,40027978) 00000000000ec87057d8  11/8/2010 06:59:03  tx 1
|
|\
| 90676 (1,40261655) 00000000001476bf9bf0  11/9/2010 07:40:40  tx 1
|
|\
| 90858 (1,40369940) 00000000000e21466cd5  11/10/2010 07:41:04  tx 1
|

0xB10C

$ grep -E '^\|' printblocktree.txt 
|\
| 90392 (1,40027978) 00000000000ec87057d8  11/8/2010 06:59:03  tx 1
|
|\
| 90676 (1,40261655) 00000000001476bf9bf0  11/9/2010 07:40:40  tx 1
|
|\
| 90858 (1,40369940) 00000000000e21466cd5  11/10/2010 07:41:04  tx 1
|

0xB10C

# PR 20827 IBD benchmarks

Bitcoin Core PR #20827 reduces the number of UTXO cache flushes to disk by increasing
the number of pruned blk/rev files per prune operation. Each prune operation causes a
dbcache flush. Fewer prune operations cause fewer flushes. Flushes are expensive with
slower disks.

I benchmarked this PR on a otherwise idle, properly cooled, and dedicated server. The
server has two HDDs in a RAID0 and an i7 4c/8t CPU. It runs a fully synced Bitcoin
Core peer that I connect to from the benchmarking node to sync from (to rule out

0xB10C

Can you verify that the tracepoints are NOPs in the binaries? If yes, how?

Yes, we can verify that the tracepoints are indeed nop assembly operations in a Bitcoin Core binary with tracepoints.

Listing tracepoint locations in the binary

The Bitcoin Core doc/tracing.md contains a section on listing avaliabe tracepoints.

For example, readelf -n src/bitcoind can be used to list ELF notes in the binary. There is an ELF note in the stapsdt section for each tracepoint. This note contains the location of the tracepoint in the binary.

0xB10C

0xB10C

#!/usr/bin/env bpftrace

/*

  USAGE:

  bpftrace perf-block-connect.bt <end-height>

  This script requires a 'bitcoind' binary compiled with eBPF support and the
  'validation:block_connected' tracepoint. By default, it's assumed that 'bitcoind' is