/btcwire:0.5.0/hemi-soak:1.0/ annoucing its address on many ports (82.221.101.217)

jonhbit · September 14, 2026, 6:53pm

I couldn’t find that specific UA string in their repo, but it is referenced here:

github.com/hemilabs/heminetwork

fix(tbc): gate peer acceptance on block frontier, not header tip (#1174)

main ← fix-tbc-inv-header-wedge

opened 10:41AM - 10 Sep 26 UTC

marcopeereboom

+319 -26

## Root cause (already fixed in main; this PR is related hardening) partner-3-0…'s Bitcoin full node wedged — block sync stopped, op-geth couldn't advance the L2, and it did not recover across restarts. **The origin was a missing proof-of-work check on header insertion, in the deployed build.** The node was running a tbc that predated #1117 (`621d1480`, 2026-07), where `verifyHeaderSanity`/`CheckBlockHeaderSanity` did not exist on any insert path. So when a `/btcwire:0.5.0/hemi-soak:1.0/` fleet peer served a **zero-PoW fork** off the real chain (~964992 → 967088), the old code accepted every one of ~2,100 fake headers with no PoW and no difficulty check. Best header became `dd32ed47…2ea9c @ 967088` — a hash with **no leading zeros, i.e. no work** (blocktime 2026-09-01 08:50). That poison persisted in the DB through the 09-02 op-geth upgrade and the 09-03 `SetHead` reset (which unwinds the external-header node, not the full node's own P2P-synced chain). Repointed to real mainnet, every real peer (~965k) was "below" the bogus tip and got rejected → 0 peers → wedge. **#1117 already closes the origin** — it adds `CheckBlockHeaderSanity` (PoW vs `PowLimit`) to `handleHeaders`, `AddExternalHeaders`, and `BlockHeadersInsert`, and makes `CheckBlockSanity` unconditional in `insertBlock`. Under it, those zero-PoW headers are rejected on any real params. It is in `main` but **not in `v2.0.0`, and not in the heminetwork version op-geth currently vendors (2025-03)** — so it wasn't running. The primary remediation is a dependency/release action, not this PR: - bump op-geth's vendored heminetwork to a build containing #1117 and cut a release that includes it; - wipe the poisoned datadir on the affected node (the PoW check guards new inserts; it does not purge already-accepted bad headers). ## What this PR does (related hardening, not the root-cause fix) `handlePeer` rejected any peer whose advertised height was below our **best header** (`BlockHeaderBest`). That is wrong whenever the header tip leads block download — normal headers-first IBD, external-header push, or (as here) a datadir carrying a chain ahead of the live network. In that state every peer at the live tip — the peers holding the block bodies we still need — is "below ours" and rejected, stranding the node with zero peers. The reject reason was also swallowed (`readError` nil) and peer count was only logged mid-block-insert, so a starved node looked healthy. - Gate peer acceptance on the **indexed block frontier** (`peerBehindFrontier`), which only advances on blocks actually downloaded/processed and never runs ahead of the live chain. - Record the reject reason; log peer count every ping tick with a warning at zero. - Also fix two latent header-sync bugs found alongside: `handleInv` abandoned an inv at the first already-known block; the post-index recovery used the missing hashes as the getheaders locator. **Scope:** this reduces the blast radius (a node keeps usable peers and can reorg to a higher-work chain instead of silently stranding) but does **not** fix the origin (that's #1117 + deploy) and does **not** recover an already-poisoned datadir.

And that project is definitely using btcd & related deps. in a few places, for light clients and/or full nodes of some sort.