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.

Doichain stack v31.1.5 + ElectrumX 2.0

The first tagged state of this repository: one combination of images and compose files that has been run end to end.

Component	Image
Doichain Core	doichain/core:v31.1.5
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

• All three stacks now run Doichain Core 31.1 and follow the DigiShield chain. The two Double Opt-In stacks pulled a 0.20.x image until now, which follows the branch the network left behind at block 431,017.
• ElectrumX moved from 1.15.0 (2020) to upstream 2.0.0, on Python 3.14 with RocksDB. The name index is now reachable for wallets — 1.15.0 built it but exposed no RPC for it.
• Neither the node RPC nor MongoDB is published on the host in any stack. Both used to be, the RPC together with rpcallowip=0.0.0.0/0; they are now reachable inside the compose network only.
• Documentation reorganised: the README is an entry point again, and the 31.1 notes are split into what runs today (docs/stack-31.1.md) and the relaunch work log (docs/history-2026-09.md).

Verified

From empty volumes on Docker Desktop: the node had every block after ~20 minutes and the ElectrumX index was complete after ~22, with the tip hash identical to a fleet node's at the same height, 0 errors, and the name index answering blockchain.name.get_value_proof for the name_doi in block 431,320.

Upgrading

An Opt-In install from the 0.20.x era needs an empty doichain-volume, or a doichain-cli migratewallet run first: that volume carries the abandoned chain's data and a BerkeleyDB wallet, which Core 31 cannot load. See README.md.

An ElectrumX server coming from the 1.15 image needs an empty electrumx-db: 2.0 changed the on-disk schema and ships no migration path.