Doichain stack v31.1.6 — a core image that starts on testnet and regtest

Doichain Core v31.1.6, and a core image that starts on testnet and regtest.

Component	Image
Doichain Core	doichain/core:v31.1.6-1 — Core v31.1.6 (commit 373973af51) with this repository's entrypoint fix
ElectrumX	doichain/electrumx:v2.0.0-doi1 — built from Doichain/electrumx v2.0.0-doi1, commit 11877d7b
Bitcoin (merge-mining parent)	doichain/bitcoind:v0.20.0
p2pool	doichain/p2pool:v34.0
dApp	doichain/dapp:v0.0.9.117 with mongo:3.2

What changed with this tag

• Doichain Core v31.1.6. Two fixes on top of v31.1.5, no consensus change and no reindex: plain help works again — the name_doi description began with a newline, which RPCHelpMan::ToString() refuses, and since help renders every command that one string took the whole call down in v31.1.2 through v31.1.5 — and CLIENT_BUGREPORT now names a repository that accepts issues instead of the archived one.
• The core image starts on testnet and regtest again (#8, #9). The entrypoint wrote bind= into the global section of the generated doichain.conf while regtest=1 or testnet=1 stood in that same section; Core refuses that, and because doichaind is PID 1 the container restart-looped. The bind stays — without it Core derives the onion target as P2P+1, which is the RPC port — it just sits in [regtest] or [test] now. This is why the image is tagged v31.1.6-1: doichain/core:v31.1.6 on Docker Hub was pushed at 08:47 UTC on 2026-09-17, the fix landed at 10:22, so that image still carries the old entrypoint. latest carries that same older build — same digest, pushed at 08:52 — so name the tag in your compose file and do not rely on latest.
• The Dockerfile pins a release tag by default. ARG DOICHAIN_VER was feat/digishield-daa, a branch: two builds of the same Dockerfile could hold different code.
• The chain notes say where the chains actually part. The new rules took effect with block 431,017, but that block is on both chains — the old 0.20 nodes accepted it, because Doichain never enforced nBits. They part at 431,018, where this chain has 71d50ff1…4b67 and the old one bab49c13…2d34, both on the same parent. getblockhash 431018 is the question that tells a node's chain apart; 431,017 proves nothing. See docs/stack-31.1.md and the addendum in docs/history-2026-09.md.

Verified

The entrypoint fix was run one container per network against doichain/core:v31.1.6 with the fixed script mounted in: regtest with the bind under [regtest], testnet under [test], mainnet unchanged and global — each node answering, each reporting its own chain, and the failure reproduced beforehand on the unmodified image.

The chain facts were measured on 2026-09-18 against all four *.doi.works ElectrumX servers, doi-explorer.le-space.de and the explorer of the old chain: tips 432,230 here and 444,404 there, the latter ahead because it kept mining at the old difficulty (~203 M against ~717 M).

Upgrading

From v31.1.5-stack1: pull the new core image and restart. No reindex, no data migration, no change to ElectrumX, bitcoind, p2pool or the dApp.

docker compose -f docker-compose-mining.yml pull doichain
docker compose -f docker-compose-mining.yml up -d doichain

A testnet or regtest stack that restart-looped on Config setting for -bind only applied on regtest network when in [regtest] section needs exactly this image; nothing else changes.

Coming from the 0.20.x era, the volume notes of v31.1.5-stack1 still apply: an Opt-In install needs an empty doichain-volume or a doichain-cli migratewallet run first, and an ElectrumX server coming from the 1.15 image needs an empty electrumx-db.