[krsnak]

Updates the operator runbook from #6 to reflect that #3 has now been merged as commit 75032400914250c7ad857dc29043761680a66485 on 31.1-dogmode.

This keeps the original runbook scope and measured operating data, but removes stale pre-merge instructions that still point operators at the old plain-Core branch tip or the former PR head.

Independent validation performed on Apple Silicon (arm64) against the current merged DOG Mode branch:

• source build completed successfully with wallet, GUI and IPC disabled
• bitcoind and bitcoin-cli report v31.1.0
• test_bitcoin: 680 test cases, no errors

The Linux-specific deployment sections (apt/systemd/etc.) were not validated on macOS.

[dogofbitcoin]

@krsnak, thank you for this, and for building the merged tip on Apple Silicon. It came in on the 9th and nobody answered it; sorry for the silence.

You were right about the stale parts. #6 still describes pull request 3 as it stood before the merge in several places (the head 76ae6e2d in section 1, "the head has no switch", the slot ordering called an open point), and your text fixes each of them against 7503240091. Your test_bitcoin run is credited in #6's closing note, with a link here.

One change on our side that your copy predates: the runbook is maintained by the Dog of Bitcoin Foundation, and #6's attribution lines now say so. Its first line reads "Written 2026-09-02 from the node we run ourselves, updated 2026-09-03 after the policy set merged, and maintained by the Dog of Bitcoin Foundation since 2026-09-14", and its closing note names no operator for the node. Lines 3 and 370 of your file carry the earlier attribution.

Two pull requests adding the same file will make the maintainers choose, so tell us which you prefer and we will do our part the same day:

1. we bring doc: an operator runbook for running a DOG Mode node #6 up to your post-merge text, crediting you in the commit, and close doc: update DOG Mode operator runbook after PR #3 merge #8 in its favour; or
2. you take doc: an operator runbook for running a DOG Mode node #6's two attribution lines into doc: update DOG Mode operator runbook after PR #3 merge #8, and we close doc: an operator runbook for running a DOG Mode node #6 in favour of yours.

Either is fine with us.

[krsnak]

Thanks — let's go with option 2. I've taken #6's two attribution updates into #8 in commit f890e76e7d: the Foundation maintenance attribution at the top, and the operator-neutral closing note. Please close #6 in favor of this PR.

[dogofbitcoin]

Done, and thank you. #6 is closed in favour of this one.

Your f890e76e7d matches #6's opening line word for word, so the attribution now reads the same in both. The closing note is your own rather than #6's, which is fine, but two things #6's last revision carried are not in it. Both are yours to take or leave, and if you would rather not touch this branch again, say so and we will put them up as a follow up against the file once this merges.

The credit. #6's closing note named the independent builds by handle: your test_bitcoin run on Apple Silicon, and J25dunn's Linux and Qt build reported on #3. We hold ourselves to crediting reviewers by the handle they use, in the place the work happened, so we would rather that stayed in the file than drop out because the line it sat on was ours.

One sentence is out of date. "Its provenance does not establish a DOG Mode policy run" was true of that node when the file was written, and stopped being true on 2026-09-05. The merge commit was built on that node's box on 2026-09-03 with the recipe in section 4, the unit suites and functional tests the policy change touches passed, a copy of the node's own chainstate booted on those binaries with DOG_MODE in localservicesnames and needed no reindex, and the node moved to that build on the 5th. Read again today, 2026-09-16: getnetworkinfo on it returns NETWORK, WITNESS, NETWORK_LIMITED, P2P_V2, DOG_MODE.

#6's closing note, with the merge commit written out the way you write it through the rest of the file:

*The node this runbook was written from ran the recipe above on `bbc08805` (pre-merge, plain Core
31.1 behaviour) through its initial sync. The merged tip
(`75032400914250c7ad857dc29043761680a66485`) was built on that node's box on 2026-09-03 with the
recipe in section 4: the unit suites and functional tests the policy change touched pass, and a copy
of the node's own chainstate booted on those binaries answered with `DOG_MODE` in
`localservicesnames` and needed no reindex. The node moved to it on 2026-09-05 and has advertised
`DOG_MODE` since. Independent builds of the merged tip, with thanks: krsnak on Apple Silicon
(`test_bitcoin`, 680 cases, no errors; #8) and J25dunn on Linux with the GUI (152 CTest entries
passing and DOG peering over v1 and v2 on regtest; the full report is on #3). Corrections welcome as
pull requests against this file.*

[dogofbitcoin]

Thank you, @krsnak. 29e2229081 carries the closing note as offered, so both points are in: the independent builds credited by handle, and the note brought up to the merged tip. Read again today, 2026-09-17: the node still returns DOG_MODE in getnetworkinfo, so the note holds. Nothing further from us on this pull request.

[krsnak]

Final field-test update from our side:

We completed a real Windows x86-64 mainnet run of the independent DOG Mode build on an HP Elite Slice. The node completed full IBD successfully and reached current tip with initialblockdownload=false and verificationprogress=1. getnetworkinfo reports Bitcoin Core 31.1.0 with DOG_MODE present in localservicesnames alongside WITNESS, NETWORK_LIMITED and P2P_V2. We did not observe chainstate, reindex, corruption or DOG Mode-specific runtime issues during the completed sync.

In parallel, our independent outbound-only crawler has naturally observed multiple DOG_MODE-advertising peers without manually seeding our own node.

One planned end-to-end check remains intentionally unclaimed: natural inbound discovery of our own HP node by that crawler. The test host is behind ISP CGNAT (and has no usable globally routed IPv6), so it cannot be exposed as a normal inbound-reachable Bitcoin peer without changing the Internet service. We chose not to work around that or manually seed the host, since doing so would weaken the independence of the test.

So from our side the Windows build/mainnet sync and DOG_MODE advertisement test is complete; only the public inbound-discovery leg was blocked by network topology rather than a DOG Mode failure.

Thanks again for the review and coordination.

[dogofbitcoin]

Thank you, @krsnak. A full mainnet sync to the tip on Windows x86-64, with DOG_MODE in localservicesnames, is the first Windows run of the merged commit reported on this repository, and it adds a third operating system to the independent builds this runbook credits.

Leaving the inbound leg unclaimed was the right call. A node behind CGNAT cannot take inbound connections, and our DNS seed meets the same wall from the other side: it can only hand out nodes that accept connections on 8333, so seed.dogofbitcoin.org shows two numbers, the dog nodes it can see (2 today) and the ones it can answer with (1). Working around it would have weakened the independence of your test, as you say.

Nothing further from us on this pull request.