Ravencoin 4.6.1.1-hf1

Ravencoin 4.6.1.1-hf1

Emergency release addressing a consensus flaw in KAWPOW header validation that is being
actively exploited on mainnet since 2026-08-07.

Every node operator, pool, exchange and explorer should upgrade. Read the upgrade
notes below before starting the new binary — the first start takes hours.

Why this release exists

Upstream Ravencoin development is inactive and no fix has been published. The chain is
being exploited right now, and waiting is not an option, so we have taken the decision
to ship one ourselves. This build is maintained by 2miners.

---

The problem

The nHeight field carried inside a KAWPOW block header was never compared against the
actual height of the block in the chain. That field is not decorative: it feeds the
proof-of-work hash, and it selects the DAG epoch and the ProgPoW period.

CheckBlockHeader skips full proof-of-work verification for blocks at or below the last
checkpoint, validating only the final hash over the supplied mix_hash and never
checking that mix_hash is a genuine ProgPoW mix. Because the decision is taken on the
height the block declares about itself, a block can opt into that path from any position
in the chain.

Blocks produced this way carry no ProgPoW work at all. Producing one costs a plain hash
search with no memory-hard step, orders of magnitude cheaper than mining honestly at the
same difficulty.

Two further consequences follow from the same field, and both were observed on mainnet:

• Nodes die on restart. The block index stores the chain-derived height, so on
  reload the block hash is recomputed from the wrong value, proof of work does not
  verify, and LoadBlockIndexGuts aborts the entire load with
  Error loading block database. The block data on disk is intact; the diagnosis is
  false.
• Catch-up synchronisation is impossible. Headers are served rebuilt from the index,
  so an affected header is served with a different hash than the one its child points
  at. The receiving node reports non-continuous headers sequence, scores the peer and
  eventually bans it. With affected blocks roughly every twenty blocks, no headers batch
  can pass, and any node that falls behind can never catch up.

Measured on mainnet between 4489527 and 4491615: 96 affected blocks out of 2089.

What this release changes

• Blocks whose declared header height does not match their position in the chain are
  rejected from height 4487776, the first affected block.
• A mainnet checkpoint is added at 4487775, the last unaffected block. This pins
  history below the fork point and restores the cheap proof-of-work path below it, which
  matters for the chainstate rebuild described below.
• Loading the block index no longer aborts on entries whose proof of work does not
  verify. Such entries are skipped, and entries left with a broken ancestry are dropped.
• If that leaves the coins database ahead of the block index, the node rebuilds its
  chainstate instead of stopping with an error a daemon cannot answer.
• The asset databases are wiped together with the chainstate. They hold chain-derived
  state and were previously only wiped on a full -reindex, so a chainstate rebuild
  replayed blocks against a stale asset registry and stopped at the first re-issuance:
  asset_name 'VOTE' has already been used. This also affected plain
  -reindex-chainstate before this release.
• depends now fetches boost from archives.boost.io. The previous host was retired and
  serves an error page, which broke the build on a truncated archive.

Upgrading

Stop the node, replace the binary, start it again. No manual steps, no -reindex.

The first start takes several hours. The node drops the affected index entries,
finds its coins database ahead of the index, and rebuilds the chainstate by replaying
the chain from genesis — roughly 4.49 million blocks and 28 million transactions. It is
working, not hung. Progress is visible in debug.log:

LoadBlockIndexGuts: skipped N unverifiable block index entries
LoadBlockIndexDB(): dropped N block index entries with broken ancestry
Coins database is ahead of the block index, rebuilding chainstate
UpdateTip: new best=... height=...

Plan for the downtime. If you run several nodes, upgrade them one at a time.

The node will settle at height 4487775 and refuse to follow the affected chain,
reporting bad-blk-height for block 4487776. That is expected: it is waiting for a
chain that does not contain forged blocks.

Identifying upgraded nodes

The user agent becomes /Ravencoin:4.6.1.1/, so getpeerinfo shows who has upgraded.
The version string and log banner read v4.6.1.1-<commit>-hf1.

Binaries

Linux x86_64, statically linked against boost, OpenSSL, libevent and Berkeley DB 4.8;
dynamically linked only against libc, libm and libpthread. Built from the tag with the
bundled depends system.

Verify before use:

sha256sum -c SHA256SUMS

Building from source

git clone https://github.com/2miners/Ravencoin
cd Ravencoin && git checkout <tag>
cd depends && make NO_QT=1 NO_UPNP=1 NO_ZMQ=1 && cd ..
./autogen.sh
CONFIG_SITE=$PWD/depends/x86_64-pc-linux-gnu/share/config.site ./configure --prefix=/ --without-gui
make

Timeline

Exploitation has been observed on mainnet from 2026-08-07 to the present, carried out
by an unidentified party. The first affected block is 4487776, mined 2026-08-07
15:44:01 UTC. No affected block exists anywhere before that height: a sample of 4600
blocks spread across the six years from KAWPOW activation to 2026-08-06 contains none.