Add Bitcoin network identity to Template Distribution Protocol handshake

[vnprc]

Problem

The Stratum V2 protocol currently provides no authoritative way for a pool to learn which Bitcoin network the template provider is serving. Network identity is fundamental operational metadata — it affects how dashboards present the node, how operators reason about configuration, and how monitoring systems distinguish production from test environments.

Every downstream SV2 participant (pool, translator, JDC, monitoring dashboard) that needs the network is currently forced into one of these unsatisfying workarounds:

Manual config assertion — the operator asserts the network in a config file. Error-prone: this is an unvalidated claim that can easily be mistaken or missed when switching networks, and there is no mechanism to verify it matches reality.

nbits heuristic — inspect the n_bits field from SetNewPrevHash. This is an unreliable data source: n_bits encodes proof-of-work difficulty, not chain identity. Difficulty adjusts independently on each chain based on mining activity, so there is no authoritative mapping from an n_bits value to a specific network. Only the regtest minimum (0x207fffff) is uniquely identifying. For all other values this is a heuristic, not a reliable signal.

Coinbase output parsing — inspect NewTemplate.coinbase_tx_outputs and attempt to infer network from the coinbase output script. This is an unreliable data source: the wire format contains raw scriptPubKey bytes, not address strings, and no Bitcoin script type encodes network identity in its script bytes — the network discriminator exists only in the human-readable address representation. This approach also degrades over time as coinbase outputs become more creative — commitments, miniscript conditions, and vault-style scripts may not correspond to any parseable address type at all.

Proposed solution

Add a network field to the SetupConnection.Success message in the Template Distribution Protocol. The template provider is the authoritative source of network identity in the SV2 stack — it is directly connected to bitcoin-node and receives its chain identity from startup configuration. SetupConnection.Success is the appropriate place for this field: it is sent immediately upon connection establishment, giving the pool the network identity before any templates are received, with no additional round trips.

Suggested field:

network: STR0_255 // e.g. "main", "testnet4", "regtest", "signet"

Values following getblockchaininfo convention would ensure consistency with existing Bitcoin tooling.

Propagation through the stack

Once the pool receives network in the handshake, it can serve it downstream without any further out-of-band signaling:

sv2-tp (network from startup config)
→ pool (SetupConnection.Success.network)
→ pool monitoring API (GET /api/v1/global)
→ translator (polls pool monitoring)
→ dashboard / proxy

This replaces the current pattern where each hop requires independent manual configuration.

Notes

A near-term workaround (sv2-tp HTTP status endpoint) has been filed separately in the sv2-tp repository. This spec issue tracks the correct long-term solution. The two are not mutually exclusive — the HTTP endpoint can land first as a practical improvement while this spec change works through the review process.