Check your own node here, see the known ways a BTX node gets stuck and how to get it going again. This page never shows other people's nodes or addresses.
Check your node
Run btx-cli getblockchaininfo on your node and paste the whole answer below. The network was at block 270,203 when this page was built.
Checked in your browser only: nothing is sent or stored.
Setting up your own node
Every additional node makes BTX stronger. These are the ways to set one up:
BTX releases ↗: The official releases and documentation of the BTX developers.
easynode ↗: An open-source community setup by the easyBTX team; according to its authors it also runs without a GPU.
Stuck peers our archives see right now
Counted per connection of our two archive nodes, no node is named. Heights shared by fewer than two connections are summed up.
CPU-only nodes in consensus mode: no GPU to verify the next MatMul block. How to fix ↓
other heights
21
–
Known reasons and fixes
Stuck at block 126,978
A rebuild from genesis (for example after -reindex) stops at this block because of the unshield-velocity cap. This hits v0.34.15 and also the current v0.35 candidate, because the fix (PR
Stop the node cleanly (btx-cli stop, then wait until it has exited). Never kill it.
Do not run -reindex again until a release contains the fix.
Start from the latest signed datadir snapshot (see below); the node then only syncs the last day.
Stuck at block 184,999 or 228,000
A node in consensus mode without a qualified GPU cannot verify the next MatMul block. At 184,999 that is block 185,000; at 228,000 (the checkpoint and fast-start snapshot base since v0.34.12) it is 228,001. The node retries about every 60 seconds, forever.
Check: the "warnings" field of btx-cli getblockchaininfo says that the next MatMul block cannot be verified.
Either use a qualified GPU, or run as a trusted mirror: matmulvalidation=trusted with at least two pinned signers and threshold 2, as described in doc/btx-matmul-trusted-rpc-mirrors.md in github.com/btxchain/btx.
Trap: pins added while the node stays in consensus mode do nothing. The mode has to be trusted.
Pin only the signers that are live today (see the signers on our status page, taken from the btxscan witness). A pinned signer that no longer signs is what freezes a mirror.
Then restart cleanly; the node continues from where it stopped.
Stuck at block 185,109
Old clients (v0.32, early v0.33) do not know the switch at block 185,000 and follow an old branch that ends here.
Update to the current release v0.34.15.
Then start from the latest signed datadir snapshot (see below).
Far behind and not moving
The node does not get new blocks. Common reasons are an old client, too few synced peers, or a block it refuses.
Check the version (btx-cli getnetworkinfo, "subversion") and update to v0.34.15 if it is older.
On v0.32.11 a node stops around block 140,000: its unshield-velocity cap never ends (v0.34.15 ends it at block 135,000), so it rejects later blocks. Updating fixes it.
Check the peers (btx-cli getpeerinfo); many peers far behind slow down the sync.
Compare the hash of your newest block (btx-cli getblockhash <height>) with an explorer at the same height. If it differs, ask in the community before you change anything.
The quickest way out is often the latest signed datadir snapshot (see below).
Start fresh from a snapshot
Instead of syncing from genesis, start from our daily datadir snapshot: checked in an offline node, checked again and signed by a second archive node. Back up your wallets first, before you touch anything. Stop the node cleanly, unpack the snapshot into an empty datadir, then copy back your btx.conf and your wallets. A leftover chainstate_snapshot/ folder stops the node at startup. Keep prune= the same as the snapshot's source (prune=20000), then start again. Not for signers: they replay history themselves.