easyNode for BTX.
Run a node. Support the network.

Where things stand, 9 September 2026

The split, said plainly. On 5 September the network split at block 210,496 and our validator sat on the minority branch for twenty hours; it rejoined the live chain at 20:32 UTC after a 383-block reorganisation. The node engine's own peer rules kept it from the live chain's nodes, and we have reported that upstream. easyNode now shows when a longer chain exists that your node cannot obtain, follows the chain with the most work instead of parking, and carries a seed that is on the live chain. Which chain any reachable node follows is measured on the node census.

Mac. easyNode 0.6.23 is the current Mac build, released 15 September, and all three platforms ride node-v0.6.23. It carries the same BTX 0.34.6 engine as the Linux and Windows builds, from the same commit, built from a pristine tree and smoked before it was packaged. 0.6.22 and 0.6.23 shipped for Linux and Windows first, so for part of 15 September a Mac was offered nothing by the updater; that gap is closed, and a Mac from 0.6.0 onward is offered 0.6.23. It brings the peering work described above, the corrected fork warning, the config lock, the role the node actually fills, and a log of every self-update check. The build before 0.6.17, 0.6.12, stopped at block 199,299 and could not start again on its own: BTX published a change to a difficulty rule at that height on 25 August and withdrew it two days later, and 0.6.12 still carried the withdrawn rule. Updating is what starts such a Mac again.

Your coins are not affected. A node reads the chain, it does not hold your keys. What is out of date is your node's view of the chain, not your balance.

What a Mac does on this network, said plainly. An Apple Silicon Mac proves the block maths on its own GPU and validates as a full consensus node. We measured that on this release on an Apple M5: the engine qualified the GPU at startup with no fall back to the processor, and the node advertised itself as a consensus validator. A Mac that has been off for days does not rejoin instantly. It restarts from the small verified snapshot the app carries and then backfills, and how long that takes depends far more on which peers serve it blocks than on how fast the Mac is.

Updating a Mac that has been stopped for a week is not instant. The update refreshes the small verified snapshot it carries, at height 203,000, so your node rejoins near the tip rather than replaying the fork, and then it backfills the rest. Expect hours rather than minutes, and on a Mac that has been off since the split expect longer than that: our own Mac was catching up at roughly two blocks a minute on 6 September. Leave it running, and keep the wallet closed while it catches up: reading a balance mid catch up slows validation down. The app says where it is on the status screen the whole time.

Linux. easyNode 0.6.23 for Linux is live: released 15 September, and installed AppImage copies from 0.6.0 onward update themselves through the app's own check. Since 0.6.22 it tells you when its own newest block is more than two hours old, a signal that a stuck set of peers cannot fake, and it stops describing a node that holds a signing key as an archive serving history. 0.6.23 moves the engine to BTX's tagged 0.34.6, shows which role your node fills and whether that helps other nodes, and writes every self-update check to a log. A .deb install is told a new version exists and is updated by hand. Its engine is BTX 0.34.6, built by us from the BTX source because the BTX Linux binaries need a newer glibc than Ubuntu LTS carries. It tells you in amber when a longer chain exists that it cannot obtain, and it follows the chain with the most work. 0.6.20 added a switch worth turning on: your node can answer one question for wallets, which block sits at a given height. That is how a wallet checks it is on the right chain, it costs almost nothing, and it works on a node of any size, because it reads the list of blocks rather than the blocks themselves. It answers that and refuses every other question. With a suitable NVIDIA card (verified here on an RTX 3060) the node proves itself at startup and validates blocks as a full consensus validator. Without one, since 0.6.23, the node runs as a trusted mirror: it follows the chain the network's validators have signed and serves history to other nodes, which is what the explorer is shortest of, but it does not check the block maths itself and it trusts the pinned signing keys to have done so. Earlier builds on such a machine started, synced headers, and stalled. The download is large, about 466 MB, because the engine and its GPU math library travel inside the app.

Why the engine changed, said plainly. The previous engine, v0.34.5, could not keep up on our Linux hardware: measured on one machine with the same data and only the binary changed, it connected 0.68 blocks a minute against a chain producing 0.95, so a node on it fell behind for good while reporting itself healthy. The 0.34.6 engine did 3.80 on the same machine and has run on our own validator since 2 September. 0.6.18 through 0.6.22 bundled their release/0.34.6 branch at commit 9eb4e005. BTX tagged 0.34.6 on 13 September at 3013c2c2, one commit past that build: the commit stops counting a peer that only sent headers as a source of block bodies and changes no consensus rule. 0.6.23 moves to that tagged commit, built from a pristine tree by our own CI, and both of our engine checks verify that exact commit. The engine lands on its own with the app update: the install directory carries the commit, so no copy can keep the old build by mistake. An AppImage applies it on its own; a .deb install is told and updated by hand. The Windows build carries the same engine commit, built separately on its own platform; the Mac build stays one commit behind until its 0.6.23 is made. The blocks a minute above were measured on Linux hardware and we have not repeated that measurement elsewhere.

Windows. There is a native Windows build again: 0.6.23. 0.6.21 was the first since 0.6.6, and 0.6.23 follows it with BTX's tagged 0.34.6 engine, the same commit Linux carries. Upstream still publishes no Windows binaries at all, so we cross-compile that engine ourselves and smoke it on a real Windows machine before it ships. Copies on 0.6.6 are offered this one directly — they have always used the working feed — and that matters, because 0.6.6's engine predates the 17 August consensus release and parks at block 191,713, or at 184,999 on a machine that checks blocks on the processor. If you have a Windows node sitting at one of those heights, this is what starts it again.

The WSL2 route is still there and still good: the Linux build under WSL2, the same way the easyBTX miner has run on Windows since July. That is the setup we verified 0.6.17 on — a Windows machine, WSL2, and an RTX 3060, where the node qualifies its own GPU and validates as a full consensus validator. The five minute setup is in the guide. Which you pick depends on your card: the native build has not been measured against a GPU here, and WSL2 has.