StartOS 0.4.0, Bitcoin Knots v29.3.knots20260508 (#knots:29.3.1:10), x86 mini PC, non-pruned, txindex + blockfilterindex enabled.
Since the 0.4.0 update, the node’s tip is frozen at height 961633 (block dated 2026-08-08). Peers report 961985+. It has never advanced a single block since.
getchaintips returns only the active tip at 961633 plus old stale forks — no headers-only entry above the tip. So this isn’t stalled block download; headers never arrive at all.
The log shows, repeatedly: peers connect normally (hundreds cycled through), Synchronizing blockheaders, height: 961633 (~99.9%), then Timeout downloading headers, disconnecting peer=N roughly every 15 minutes, and Potential stale tip detected counting steadily upward.
Ruled out so far:
-
Clock:
timedatectlsynced, NTP active, matches log UTC -
MTU:
ping -M do -s 1472to a peer succeeds, 20ms, 0% loss -
Throughput: 7.5 MB/s HTTP download from the host
-
Port 8333: TCP connects instantly to peers
-
Routing: normal LAN gateway, not via any tunnel
-
Mempool: restarted with
mempool.datremoved, no change -
Tor: set
onlynetto ipv4+ipv6, SOCKS refusals stopped, sync unchanged
Two config details I’m unsure about: whitebind=0.0.0.0:8333 alongside bind=0.0.0.0:58333, and the startup warning that 58333 is shared between Tor and clearnet so localhost connections are denied whitelist permissions. Is that expected for this package?
Also seeing ThreadRPCServer incorrect password attempt from 10.0.3.1 (the LXC bridge gateway) on every start, before and after regenerating RPC credentials.
