# /btcwire:0.5.0/hemi-soak:1.0/ annoucing its address on many ports (82.221.101.217)
**URL:** https://bnoc.xyz/t/btcwire-0-5-0-hemi-soak-1-0-annoucing-its-address-on-many-ports-82-221-101-217/170
**Category:** Observations
**Tags:** addrman, p2p
**Created:** [September 3, 2026, 7:43pm UTC](https://bnoc.xyz/t/btcwire-0-5-0-hemi-soak-1-0-annoucing-its-address-on-many-ports-82-221-101-217/170 "2026-09-03T19:43:06Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@stratospher](https://bnoc.xyz/u/stratospher)
#### Post date: [September 3, 2026, 7:43pm UTC](https://bnoc.xyz/t/btcwire-0-5-0-hemi-soak-1-0-annoucing-its-address-on-many-ports-82-221-101-217/170/1 "2026-09-03T19:43:06Z")
I found it hard to believe the number of IP addresses received including duplicates rose to 460,241 addresses on 31 august in a node I was looking at.
Apparently 99.2% of all the addresses which got rate limited in net\_processing in the node’s debug.log (since it started) came from 1 ip address `82.221.101.217` which advertises it’s own IP addresses on 67 different ports. It sends all addresses with services = 0, so none of them would enter the addrman anyways.
- addresses it sent:
- from Aug 18 - 20: same ip address `82.221.101.217` on 20 contiguous different ports (so an ADDR message was 20 different addresses but it was the same IP on 20 different ports)
- from Aug 20 onwards: same ip address `82.221.101.217` on 67 contiguous different ports from ports 8333–8399.
- frequency: 1 ADDR message every ~30 seconds.
I tried connecting to it:
- it’s version message was `ver=70016 services=0000000000000000 height=1965166 ua='/btcwire:0.5.0/hemi-soak:1.0/'` and the height is roughly double the real network’s ~964,600.
- all its ports were reachable but it disconnected me after ~30 seconds. (I haven’t tried from a real node yet btw)
side note: this isn’t responsible for the recent [increase in KIT’s Unique Addresses per Day graph](https://www.dsn.kastel.kit.edu/bitcoin/#addresses) after mid-august since the graph doesn’t count duplicates.
---
### Author:  [@stratospher](https://bnoc.xyz/u/stratospher)
#### Post date: [September 3, 2026, 8:29pm UTC](https://bnoc.xyz/t/btcwire-0-5-0-hemi-soak-1-0-annoucing-its-address-on-many-ports-82-221-101-217/170/2 "2026-09-03T20:29:38Z")
hmm probably software on some other chain accidentally connecting to us? [seeing this on bitnod.es](http://bitnod.es/node_explorer.php?user_agent=%2Fbtcwire%3A0.5.0%2Fhemi-soak%3A1.0%2F&sort=export_date&dir=desc). seems to have connected to other normal nodes as well.
EDIT: no idea and could 100% be wrong but maybe [https://hemi.xyz](https://hemi.xyz)
---
### Author:  [@jonhbit](https://bnoc.xyz/u/jonhbit)
#### Post date: [September 14, 2026, 6:53pm UTC](https://bnoc.xyz/t/btcwire-0-5-0-hemi-soak-1-0-annoucing-its-address-on-many-ports-82-221-101-217/170/3 "2026-09-14T18:53:31Z")
I couldn’t find that specific UA string in their repo, but it is referenced here:
>
>
> \## 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.
---
### Author:  [@stratospher](https://bnoc.xyz/u/stratospher)
#### Post date: [September 14, 2026, 7:09pm UTC](https://bnoc.xyz/t/btcwire-0-5-0-hemi-soak-1-0-annoucing-its-address-on-many-ports-82-221-101-217/170/4 "2026-09-14T19:09:26Z")
oh wow, thanks for finding that UA! currently seeing 4,298,947 addresses from that IP address which got rate limited. maybe we should open an issue there.
EDIT: created an [issue](https://github.com/hemilabs/heminetwork/issues/1177)
---
### Author:  [@stratospher](https://bnoc.xyz/u/stratospher)
#### Post date: [September 21, 2026, 11:09pm UTC](https://bnoc.xyz/t/btcwire-0-5-0-hemi-soak-1-0-annoucing-its-address-on-many-ports-82-221-101-217/170/5 "2026-09-21T23:09:21Z")
we checked @b10c’s peer-observer graphs and saw this IP disconnecting on 20 sep ~21:18 UTC across many nodes. 🪦 🌼