Ravencoin 4.8.0

Ravencoin 4.8.0

Supersedes 4.6.1.1-hf1. It carries the same KAWPOW header height fixes on top of the
current upstream development branch, so it also includes the asset transfer overflow fix
that 4.6.1.1-hf1 was missing.

Everyone running 4.6.1.1-hf1 should move to this build. Everyone still on 4.6.x or
4.7.0 should upgrade as well. Read the upgrade notes below — the first start takes hours.

Why this release exists

A critical consensus vulnerability has been demonstrated and exploited on the network
since 2026-08-07. Upstream development had published no fix, so 2miners shipped one. This
release brings that work onto the upstream development branch and adds a version of its
own.

---

What is in this release

On top of upstream develop

• Blocks whose declared header height does not match their position in the chain are
  rejected, from height 4487776 — the first affected block.
• Mainnet checkpoint at 4487775, the last unaffected block. 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.
• The chainstate is rebuilt automatically when the block index no longer contains the
  block the coins database points at, 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.

Inherited from upstream

• Asset transfer quantity overflow checks, deployed as a BIP9 soft fork on bit 11
  (transfer_overflow). Note that while the majority of the hash rate was running 4.6.1
  — which does not know about this bit — nothing was signalling it and the deployment
  could not activate. It will now proceed. Watch it with:
  raven-cli getblockchaininfo | jq '.bip9_softforks.transfer_overflow'
• Build system rework and a working boost download URL.

---

The vulnerability

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.

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. On a 32-core
machine this measured about 2.5 hours. 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.

Nodes already running 4.6.1.1-hf1 do not pay this cost again: their coins database
already matches the truncated index, so they start in under a minute.

Until a chain without forged blocks is available, the node settles at height 4487775 and
reports bad-blk-height for block 4487776. That is expected.

Peers to add

Until enough of the network runs a patched build, unpatched peers keep serving header
batches that cannot be linked. A node that falls behind gets those batches, rejects
them, scores the peer and eventually bans it — and can end up with no usable peer left
to sync from. Give it somewhere reliable to go:

addnode=152.53.127.98:8767
addnode=5.161.192.113:8767
addnode=4.194.46.166:8767
addnode=51.210.219.138:8767
addnode=141.95.34.186:8767
addnode=141.95.34.186:18767
addnode=51.89.99.172:8767
addnode=51.89.99.172:18767
addnode=162.19.139.183:8767
addnode=162.19.139.183:18767

Put these in raven.conf and restart, or add them to a running node one at a time with

raven-cli addnode 152.53.127.98:8767 add

addnode connections are held open and are not dropped to make room for other peers, so
they survive the churn. They do no harm once the network has upgraded, but you can remove
them then.

Notes for exchanges

Before you switch: save the raw transactions

Do this first, while your node is still on the old chain. Export the raw hex of every
transaction you care about — deposits credited after block 4487775, and withdrawals you
have sent:

raven-cli getrawtransaction <txid>

Once the chain is reorganised, a transaction that is not in the new chain and not in your
mempool is gone from the node, and you cannot rebroadcast what you no longer have. Save
it now, not later.

Deposits confirmed after block 4487775

They can be rebroadcast and they confirm normally, provided their inputs are still
unspent on the clean chain:

raven-cli sendrawtransaction <hex>

The transaction itself does not need to be rebuilt or resigned. It is valid on the clean
chain as long as the coins it spends exist there and nothing else has spent them since.

Deposits you already credited

You rebroadcast them yourselves. There is no reconciliation mechanism and none is
planned. Treat it as your own recovery pass: after syncing, compare your credited
deposits against the clean chain and resend whatever is missing.

raven-cli getrawtransaction <txid> 1

If the result has no blockhash and no confirmations, the transaction is not in the
clean chain and needs resending.

Which deposits cannot be recovered

A deposit is unrecoverable when the coins it spends were created on the abandoned
branch — that is, when its ancestry leads to a coinbase in a block above 4487775. Those
coins do not exist on the clean chain, so no rebroadcast can succeed.

You do not have to trace the ancestry by hand. The node will tell you: rebroadcast
everything, and anything that fails with

bad-txns-inputs-missingorspent

is spending coins that do not exist on the clean chain. Those are the unrecoverable
ones. Everything that is accepted is fine.

Withdrawals

The same applies to coins going out. Withdrawals confirmed after block 4487775 are
reversed by the reorganisation, which means the funds return to you and the user has not
been paid. Rebroadcast them the same way, and reconcile before you assume any payout
went through.

Confirmations

Raise your confirmation requirement while the situation settles, and do not resume
deposits and withdrawals until your node has followed the clean chain past the point
where the branches diverged.

Identifying upgraded nodes

The user agent becomes /Ravencoin:4.8.0/.

Binaries

Linux x86_64, statically linked against boost, OpenSSL, libevent and Berkeley DB 4.8;
dynamically linked only against libc, libm and libpthread.

sha256sum -c SHA256SUMS

Building from source

git clone https://github.com/2miners/Ravencoin
cd Ravencoin && git checkout v4.8.0
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.