Rollout blocked: publish v31.1.2 and fix peer discovery

Two things block the 31.1 rollout completely. Until both are done **nobody outside this host can run the fixed node, even if they want to** — so no miner can migrate and the new chain cannot gain hashrate.

Both are entirely within our control. Context and measurements in #3.

---

## :red_circle: Blocker 1 — publish `v31.1.2`

`docker-compose-mining.yml` builds doichaind from **`Doichain/doichain-core`, which is private**. On any host without repo access `docker compose build doichain` fails, so the documented install path is dead for third parties.

- [ ] Publish the image to Docker Hub as **`doichain/core:v31.1.2`**
- [ ] Publish binaries (or make the repo readable) so the build path works too
- [ ] Tag `v31.1.2` on `doichain-core`

**It must be a new version, not `v31.1.1`.** The fixed binary carries four commits that the shipped `v31.1.1` does not, three of them consensus-adjacent:

| Commit | What it fixes |
|---|---|
| `5cddda8` | headers presync never started — gate compared entry count, AuxPoW headers cap on bytes |
| `a87dde5` | presync aborted at height 2016 — nBits rule applied below `DoiPowCheckHeight` |
| `510da7a` | `nMinimumChainWork` pinned to the exact tip → `insufficient work`, endless peer churn |
| `d0ea15d` | branding leftovers (source URL, `EXE_NAME`, `namecoin` target) |

`CLIENT_VERSION_BUILD` and the compose tag are already set to `v31.1.2` on `feat/doichain-31.1`.

---

## :red_circle: Blocker 2 — peer discovery is dead

A fresh node **cannot find the network at all**. Measured on a clean datadir:

```
Loading addresses from DNS seed dnsseed.doichain.org.
Loading addresses from DNS seed seed.doi.works.
0 addresses found from DNS seeds
Adding fixed seeds as 60 seconds have passed and addrman is empty …
Added 0 fixed seeds from reachable networks.
```

`getnodeaddresses` returns **0**. The node sat with 0 peers indefinitely; one run only ever got a single short-lived addr-fetch connection, pulled the whole header chain through it, and was then isolated again.

- [ ] Fix `dnsseed.doichain.org` and `seed.doi.works` so they return addresses
- [ ] Compile **fixed seeds** into the binary as a fallback
- [ ] Until then: ship a documented `-addnode` list (already in the compose on this branch)

Peers observed serving mainnet on 2026‑09‑11: `2.28.75.43`, `136.243.155.62`, `167.233.173.2`, `116.203.99.217`, `128.140.44.20`, `195.201.129.97`, `94.130.57.196`

This also cost us real blocks today: doichaind with 0 peers refuses `createauxblock` with `-9 Namecoin is not connected!`, so p2pool could not merge-mine at all.

---

## Why this is time-critical

**The old chain is currently cheap to rewrite.** Our block 431017 reset the difficulty by a factor of 26 946 (28 232 869 630 → 1 047 741) and, because Doichain never enforced `nBits` historically, the legacy nodes accepted it. Everything mined since is at a tiny difficulty:

| Attacker hashrate | Time to rewrite **all** ~5 800 blocks since the fork |
|---|---|
| 5.19 PH/s (the chain's own) | **2.1 hours** |
| 1 PH/s | 10.6 hours |
| 100 TH/s | 106 hours |

For comparison: before the attack, replacing a **single** block cost 6.5 hours at that hashrate. Doichain is merge-mined, so 5 PH/s is ~0.001 % of Bitcoin's hashrate — trivially rentable.

**And the migration window is closing.** The legacy DAA is ramping the old difficulty back up ×4 per 2016 blocks. The later hashrate leaves, the worse the old chain freezes:

| Hashrate leaves | 10 % remains | 1 % remains |
|---|---|---|
| **now** (diff 4.19 M) | 35 s/block | 6 min/block |
| in ~41 h (diff 268 M) | 37 min/block | 6.2 h/block |
| in ~7 days (diff 725 M) | 100 min/block | **16.7 h/block** |

A retarget needs 2016 blocks *first*, so at 1 % remaining in a week the old chain would need **1 399 days** before it could even correct — permanently dead. Migrating now leaves it survivable; migrating late destroys it.

Our own chain has no such exposure: DigiShield adapts in **8–35 blocks** whatever arrives.

---

## Notes on the migration itself

- It is a **software rollout, not a hashrate race**. A node running the fix rejects the old chain from ~431046 on its own. Out-mining it is neither possible (946× behind, 173× less hashrate) nor necessary.
- **Abandoning the old chain costs no users anything.** Sampled blocks 431500 / 433000 / 436000 all have `nTx = 1` — coinbase only, no user transactions. Only ~5 836 block rewards (~72 950 DOI) are undone, and they went to a third-party `dc1q…` address, not ours. Expect that miner to be the only party objecting.
- Our chain currently has **3 blocks at ~30 TH/s** and is itself trivially reorganisable until real hashrate lands on it. Right now that is the larger risk, not the old chain.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Start with docker-compose-mining.yml and the feat/doichain-31.1 branch, verifying that its v31.1.2 image and build references work without private-repository access. Then inspect the DNS-seed and fixed-seed configuration and test a clean datadir; done means v31.1.2 is published and tagged, a fresh node discovers peers, and the documented -addnode fallback is available.

Written by the indexing model from the issue text.