Janzeer node 0.1.9

Seventh mainnet release — a hotfix after the mainnet stall of 2026-10-24 (23:20 → 03:21 UTC, 4 h 01 min, no block lost or reverted). Same network, same protocol: any 0.1.x node keeps working, but every validator should install this one, home boards first.

• Network janzeer, protocol 3.4.0, API 1.1.0
• Genesis hash 3a716783ee58bc56335aaede1d489eeda22cd7442c358f085a83213028b7782c
• Native executables, no Java needed

What happened

Finality needs 5 of the 6 registered validators. One validator (a Raspberry Pi) had been silent since 19:06 UTC: it saw a live block ahead of its tip, started a tip re-check, and that re-check was never answered and never gave up — eight hours in PROCESSING without a log line (F-052). When a second validator went offline at 23:20 UTC, four voters remained and no block could be finalized. The four project nodes were healthy and proposed on every slot; a restart of the Pi's node restored the fifth vote and the chain resumed within one slot.

Fixed — a tip re-check is bounded and visible (F-052)

The availability round now logs its retries (first retry, then once a minute) and gives up after 2 minutes (node.tip-check-timeout), returning the validator to SYNCHRONIZED so it votes again; the next live block ahead of its tip re-triggers the check cleanly. The retry loop of a finished sync session is cancelled, and a new request always replaces a stale loop (it used to be silently kept, so the re-check's own request was never re-sent).

Fixed — a vote could freeze the whole set (F-053)

A vote or certificate moved a node's slot bookkeeping to any slot number it carried, before any signature check. One validator with a clock running ahead, or one forged vote from any peer, marked every real block "stale" on every node until the next epoch genesis. Votes are now verified first and must sit within one slot of the local clock; a node whose bookkeeping ran ahead of its clock heals itself.

Second stall, 25 October (06:21 → 10:19 UTC, 3 h 57 min, no block lost or reverted)

The F-053 case happened on the live network before this release was out: a vote with an implausible slot number pushed the four project nodes' slot counters forward, so each node dropped its own blocks as stale without a log line, and five live validators finalized nothing. The upgrade of the project nodes to 0.1.9 ended it — 0.1.9 ignores such votes and logs their sender.

Upgrade from 0.1.8 (or any 0.1.x)

./update.sh (Linux, macOS, Raspberry Pi): downloads this bundle, verifies the minisign signature and the checksum, keeps data/, swaps the files and restarts the service (./update.sh --rollback restores the previous version). Or by hand: stop the node, replace the bundle folder, keep data/, start again. Arch: sudo pacman -U janzeer-node-bin-0.1.9-1-x86_64.pkg.tar.zst && sudo systemctl restart janzeer-node. Windows: stop the node, unpack the new zip over the old folder (keep data), run start.cmd. Docker: ghcr.io/janzeerorg/janzeer-node:0.1.9.

SHA-256

29a24b51338746722e4ed992ac8c6e5c7dda6e7d4233b505a5e2da183ce87518  janzeer-node-0.1.9-mainnet-linux-arm64.tar.gz
a3a7eb35b2a3f1d455f967f05fc704896b1a1d318b391e7d6c103a61dcf05439  janzeer-node-0.1.9-mainnet-linux-x64.tar.gz
ec49c4cecf37d3f3fd53afae8b8ec0167b66b8f34f341160f0afcc03adf3fe2a  janzeer-node-0.1.9-mainnet-windows-x64.zip
ac7f881bfc61bc24dbffea0c16bb1c8bcf82d1c6d8a3e39e13ba0dd740c0f111  janzeer-node-bin-0.1.9-1-x86_64.pkg.tar.zst

SHA256SUMS is signed with the project's minisign key (key id 9F798583B345AE01, public key RWQBrkWzg4V5n5wUBa9GNPpa95Z7WFT2EY5QrabMv/DP+KG+gJsPIgdr): verify with minisign -Vm SHA256SUMS -P <key> and sha256sum -c SHA256SUMS before running.