Rollback

Rollback Procedure for BitNet Nodes

In rare cases where a chain upgrade fails or causes consensus issues, validators may need to roll back to a previous BitNet version.

The process involves restoring a valid database state and the signing state file to resume operations without triggering double-signing penalties.

---

⚠What You Need to Roll Back

To perform a successful rollback, ensure you have the following:

1. A backup of the node’s data directory Usually located at:

   ~/.bitnetd/data

2. A copy of priv_validator_state.json This file tracks the last signed block and is essential for avoiding double-signing.

If priv_validator_state.json is missing, your validator risks signing the same block twice after rollback — leading to slashing.

---

Rollback Steps

1. Stop Your Node

Gracefully halt your BitNet validator:

bitnetd stop

---

2. Restore from Backup

Assuming you have a full backup in a folder named backup/bitnetd/:

rm -rf ~/.bitnetd/data
cp -r backup/bitnetd/data ~/.bitnetd/

Also ensure priv_validator_state.json is restored:

cp backup/bitnetd/data/priv_validator_state.json ~/.bitnetd/data/

---

3. Install Previous BitNet Version

From your BitNet source directory:

git fetch --all
git checkout <previous_version>
make install

Confirm the version:

bitnetd version --long

---

4. Restart the Node

Once the old binary and valid state are in place:

bitnetd start

The node will now resume operations from the last valid height prior to the failed upgrade.

---

If You Don't Have a Backup

If your validator lacks a data backup:

• Request a snapshot from another validator or trusted peer.

• Validate the database hash.

• Use the provided priv_validator_state.json if you can trust its accuracy.

---