bdagscan node — climbing toward the tip

Test node: stock v1.0.0 (May-10) syncing from peers with --acctmode OFF, on a disposable copy of the verified 12,085,922 backup. Every imported block is checked against the local bdagscan archive, and the early checkpoints are re-read from the freezer every cycle. Both layers are shown throughout: the EVM chain and the DAG it is derived from run at different numbers (DAG order ≈ 1.296 × DAG height), and mixing them is how a node gets mistaken for being ahead of its peers.

84.036% of the way to the live tip (17,852,415) · we import 0.0 blk/s while the chain produces 0.84 blk/s, so the gap closes at — blk/s · 0 blocks in 6d 23h of sampling · 7 handshake rejections

Known archive checkpoints (recorded in the bdagscan archive and verified field-by-field — see the comparison table below): the consensus split at 14,391,951 and the decisive works↔bdagscan discriminator at 14,412,749. These are archive reference points, not heights this node has reached — the witness head is — (EVM), still below them.

This is a bounded witness: it independently reproduces the bdagscan lineage from peers and will stop at the approved safe height rather than sync indefinitely. All heights below are EVM heights (not DAG order).

Post-fork BDAGSCAN qualification: PENDING — below the decisive discriminator (14,412,749) the restored witness has not yet independently reproduced the post-fork region. (An earlier run previously reproduced BDAGSCAN beyond it; that run was intentionally bounded and restored.) EVM height and DAG order are different units.

The EVM chain is derived from the DAG, so the two run at different numbers: DAG main order is roughly 1.29× the EVM height. Both are ours, live.

The settled row is the freezer — it trails the importing tip by ~90k blocks and is what every verification reads. eth_getBlockByNumber("latest") is not usable on this node: without --acctmode it is pinned at block 1,065,434 while the node imports at 12.8M.

A fork can agree on height and hash prefix while diverging on stateRoot or reward, so each checkpoint is compared field by field: the whole EVM header (parentHash, sha3Uncles, miner, stateRoot, transactionsRoot, receiptsRoot, logsBloom, difficulty, number, gasLimit, gasUsed, timestamp, extraData, mixHash, nonce, baseFeePerGas), the block hash, totalDifficulty from the freezer's own diffs table, and the credited block reward. Headers are decoded straight out of the freezer — this node serves almost no historical blocks over RPC without --acctmode. The decode is self-validating: parentHash must equal the stored hash of N−1.
ALL MATCH — 18 fields compared per block.

Our main order 0, tip ?…. bdagscan publishes no DAG RPC, so DAG hashes can only be cross-checked peer-to-peer — each peer's advertised order and tip is in the peer table above.

v1.0.0 speaks protocol 45. Peers on 46 mostly reset us during the libp2p handshake. 6 full nodes serve us, 0 are observers/crawlers, 1 addresses have refused. Registry holds 33 peers; the pinnable list is /home/bdag/good-peers.txt.
Protocol-46 guard: active — 26 address(es) firewalled off tcp/8291 so mainline nodes cannot feed this chain. Scoped to the test node's port only, so the localhost-bound serving node is untouched.