sec(config): on Windows DIG_BOOTSTRAP_PEERS= is DELETED not empty — an isolated node fell back to mainnet and peered with the production gateway

[MichaelTaylor3d]

Task

On Windows the documented isolation knob DIG_BOOTSTRAP_PEERS= cannot be expressed, so a node
intended to be isolated fell back to the compiled-in mainnet anchor and peered with
rpc-dig-net-node — the production gateway.

Mechanism

On Windows, setting an environment variable to "" DELETES it. So DIG_BOOTSTRAP_PEERS= — the
documented way to say "no bootstrap peers" — is indistinguishable from never setting it at all. The node
read it as unset, took the compiled-in default, and dialled mainnet.

A clean natural experiment confirms it is platform-specific, not a config error: the Linux hosts on
the same run took identical configuration and stayed correctly isolated. Same intent, same string,
opposite outcome.

Remediated on the fleet with DIG_BOOTSTRAP_PEERS=off.

Why this is filed rather than left as a test-harness note

An isolated test fleet reached production infrastructure. Nothing was harmed — it was a read-only peer
connection — but the isolation was believed to hold and did not, and the belief is the dangerous part:
an e2e run that thinks it is isolated will happily do things to what it reaches.

And the empty-string convention is a product surface, not a test convention. Any operator who follows
the documented "set it empty to disable" on Windows gets a node silently dialling mainnet. The
documentation is correct on Linux and wrong on Windows, with no diagnostic either way.

Scope

1. Accept an explicit sentinel that survives Windows — off works and is already in use on the fleet.
   Whatever is chosen, it must be a value that exists rather than an absence.
2. Say so in the docs, per platform. The current wording is true on Linux and false on Windows; a
   reader has no way to know which they are getting.
3. Consider making the default fail loud rather than quiet. A node that cannot tell "the operator
   asked for no peers" from "the operator said nothing" is guessing on a network-reaching decision.
   Logging which branch it took would have made this self-diagnosing.

Check for the same shape elsewhere. Any DIG_* knob documented as "set empty to disable" has this
bug on Windows. This one was found only because an isolated fleet was watched closely enough to notice
what it had connected to.

Evidence

• Reproduce on Windows first: set the variable to "", confirm the process sees it as unset, and
  confirm the node takes the compiled-in anchor.
• Keep the Linux control — it must continue to isolate correctly, or the fix has traded one platform's
  bug for the other's.
• Prove the sentinel: off (or whatever is chosen) must produce zero bootstrap peers on both
  platforms.
• Read passed-counts, never ok.

Related finding from the same run, likely worth the same fix pass

W reported connected=0, peers=[] in 14/14 samples while C reported a stable relayed session to W in
14/14 of the same window. Two nodes disagreeing about whether a connection between them exists — with
one of them, the local one, reporting the falsehood. That may share a cause with
DIG-Network/dig-node#351 (chia_peer_count not being a live measurement), and both are the same class:
a peer-state surface reporting something other than what is held.

Provenance

Found on the mvp5 e2e fleet, 2026-08-25, during eco#853's Windows install leg. The install itself
PASSED — dig-node 0.149.0 via released dig-installer 0.46.1, system-scope service running, RPC
answering.

Parent: https://github.com/DIG-Network/dig_ecosystem/issues/3159

[MichaelTaylor3d]

Owned by loop lane dn-secpeer, branch loop/batch-secpeer, worked as a batch on draft PR #453 (which Closes this ticket on merge). Base origin/main = 3e480dd. Progress logged on the PR.