NC-12: the anchored root — the fact content-serve pins on — comes from ONE hardcoded HTTP third party

[MichaelTaylor3d]

Task

The anchored-root chain fact — the one the content-serve pin acts on — is resolved from a SINGLE
hardcoded HTTP third party on every default install. Corroborate it, or state honestly that it is not.

The path

dig-node-core/src/lib.rs:4460, :4731
  -> default_anchored_resolver()
  -> seams/chia_peer/coinset_resolver.rs:120
  -> resolution_coinset()  (:17 — hardcoded HTTP coinset)

Also single-sourced, same enumeration: lib.rs:2724, :3650, :3709, and melt confirmation
seams/dig_peer/store_melted.rs:588 (partly https://github.com/DIG-Network/dig_ecosystem/issues/2093).

Why this is the NC-12 blocker rather than a nice-to-have

https://github.com/DIG-Network/dig_ecosystem/issues/2790's acceptance requires that every chain fact
the node acts on is corroborated across several concurrently-queried untrusted peers. Measured against
origin/main @ 4efa57fc, most are: peak_height (chain.rs:196-201), coin_record_by_id (:339),
coin_spend (:348) and their cached variants (:359-372) all go through the corroborated path.

The anchored root does not — and it is the fact that decides which bytes a user is served. A single
third party that lies about it redirects content on every default install, with the pin fail-closed
against the wrong root rather than the right one.

NC-12 exists precisely to stop one voice determining a chain fact. This is one voice deciding the
most user-visible fact the node holds.

Also uncorroborated, and in scope

coin_records_by_puzzle_hashes (chain.rs:327), _by_hints (:333), _by_parent (:374), and
mempool submission (:285-291).

Scope — a finite checklist so this can close

• Anchored-root resolution corroborated across several independently-held sources, or the
  single-source property stated in SPEC.md as a named, accepted limitation with its blast radius
• coin_records_by_puzzle_hashes / _by_hints / _by_parent — corroborated, or same treatment
• Mempool submission — corroborated, or stated
• A test per corroborated path proving a single dissenting source causes a refusal, not a repaired
  value, each with a control that kills the always-refuse implementation

"State it honestly" is a real option and sometimes the right one. What is not acceptable is a SPEC
that implies corroboration the code does not perform — that is the false-satisfaction class #2790 was
opened to end.

The trap to avoid

Do not add corroboration by consulting the same endpoint twice. Two providers that both resolve to
api.coinset.org are one voice — that exact defect was found and fixed in dig-wallet on
#354, where a 2-of-2 "independent-group" quorum was satisfied
by one endpoint with max_peers: 0. Independence must be derived from what a fabric can reach, not
from its type.

Context

• Parent: https://github.com/DIG-Network/dig_ecosystem/issues/2790 · epic
  https://github.com/DIG-Network/dig_ecosystem/issues/2760
• Related: https://github.com/DIG-Network/dig_ecosystem/issues/2093
• Measured 2026-08-25 against origin/main 4efa57fc

Effort

High — this is the largest remaining piece of NC-12, and the anchored-root half touches the content-serve
trust boundary.

[MichaelTaylor3d]

Owned by a loop lane. Branch loop/365-366-nc12-anchored-root, draft PR #369, worktree worktrees/dn-365-366. Both taken in ONE branch/PR. Coordinating with the #360/#361/#363/#364/#367 lane: dig-wallet/src/sage/chain.rs belongs to that lane and is NOT touched here.

[MichaelTaylor3d]

Progress — branch loop/365-366-nc12-anchored-root @ a8a482d, PR #369 (DRAFT).

Re-measured against a fresh origin/main @ 4efa57f (unmoved since branching): the single-source
chain is still exactly default_anchored_resolver() -> Arc::new(CoinsetResolver) ->
resolution_coinset(), and the already-corroborated set (peak_height, coin_record_by_id,
coin_spend, cached variants) is unchanged.

The split — CORROBORATED vs STATED.

Corroborated (built): the anchored root, on all three calls the serve decision makes —
anchored_state, verify_pinned_root, verify_lineage_root. New
seams/chia_peer/{endpoints,corroborated_resolver}.rs:

• Endpoints come from DIG_NODE_CHAIN_ENDPOINTS (comma list); DIG_NODE_COINSET keeps its meaning
  when that is unset; default stays https://api.coinset.org. An unparseable entry is DROPPED, never
  defaulted — a typo must not be able to pose as a second voice.
• Independence is derived from REACH, not from type or name. Two endpoints are ONE voice when
  their resolved address sets INTERSECT, transitively. This is the PR#354 trap answered at its root:
  a CNAME costs an attacker nothing, so two names for one machine can never manufacture a quorum.
• Unanimity, never a majority. One dissenter refuses. No tie-break — a majority rule hands the
  answer to whoever can field the most endpoints. Presence vs absence counts as dissent, so one
  source cannot conjure a store into being. An unreachable source is DROPPED rather than counted as
  dissent (outage and attack demand opposite remedies), and fewer than two answers is a refusal.

Stated as an accepted limitation, in SPEC.md §14.4b with its blast radius:

1. The DEFAULT INSTALL still resolves from ONE third party. With fewer than two independent
   voices the node answers from its single source and does NOT claim corroboration. Refusing instead
   was considered and rejected: it stops every unconfigured node serving any content, and removes the
   surface on which an operator would configure a second endpoint.
2. coin_records_by_puzzle_hashes / _by_hints / _by_parent, mempool submission, the melt
   confirmation, and the direct RPC-surface singleton walks. These live in
   dig-wallet/src/sage/chain.rs, which belongs to the harden(dig-wallet): chain.rs:111 with_sources is dead code that builds a single-source peak_height path #360/fix(test): serve integration test leaks a ~57MB temp dir per run — 1,123 dirs / 62.5 GB took the machine to ENOSPC #361/test(dig-wallet): make the sweep guard's worked examples doctests — a backwards example survived four gate rounds #363/ci: version-increment gate should report the comparison it made, not just pass/fail #364/key_mgmt: platform_provider() is hardcoded None and its doc comment says the binding does not exist — it shipped in dig-keystore 0.12 #367 lane — not touched
   here by coordination, and enumerated in SPEC so no reader infers corroboration from the rule above.

Revert-proofs (committed first, then reverted by file copy). Majority-vote instead of unanimity
fails 3 tests; name-based independence instead of reach fails 2; non-transitive merge fails 1 — and
that last one caught a false green of my own: the original transitivity fixture put the bridging
endpoint in the MIDDLE, so there was only ever one existing group and merge-into-all and
merge-into-first agreed on every input. Fixture rewritten with the bridge LAST; it now fires.

Gates so far: cargo fmt --check exit 0, cargo clippy -D warnings exit 0 on both crates. Full lib
suite running. §2.4b: dig-rpc-protocol 0.10.1 -> 0.10.2 and dig-ipc-protocol 0.2 -> 0.3 bumped
(both chia-0.26-line or chia-free); every other dig-* dep is stranded behind the chia 0.36 uplift
(dig-tls 0.4.0, dig-identity 0.7.1 and dig-nat 0.21.0 all declare chia ^0.36.1 against this crate's
^0.26) — reported, not shimmed, per dig_ecosystem#3161/#3152.

[MichaelTaylor3d]

Complete on loop/365-366-nc12-anchored-root @ 2b551b9, PR #369 (DRAFT, awaiting the gate).

Verified against freshly-fetched origin/main @ 4efa57fc.

CORROBORATED

The anchored root, on all three calls the serve decision makes — anchored_state, verify_pinned_root, verify_lineage_root. default_anchored_resolver() now returns a CorroboratedResolver over the endpoints in DIG_NODE_CHAIN_ENDPOINTS.

Independence is derived from REACH — two endpoints are ONE voice when their resolved address sets intersect, transitively — not from type, URL or host name. That is the trap in this ticket answered at its root. Unanimity, never a majority: one dissenter refuses rather than yielding a repaired value; presence vs absence counts as dissent; an unreachable source is dropped rather than counted as dissent, and fewer than two answers is a refusal.

STATED as accepted limitations (SPEC.md §14.4b, each with blast radius)

1. The default install still resolves from ONE third party. Below two independent voices the node answers from its single source and does NOT claim corroboration. Refusing instead would stop every unconfigured node serving any content and remove the surface on which an operator would configure a second endpoint. SPEC states what the limitation does not permit: bytes are still accepted only because they verify against the merkle root.
2. coin_records_by_puzzle_hashes / _by_hints / _by_parent, mempool submission, melt confirmation, and the direct RPC-surface singleton walks — all in dig-wallet/src/sage/chain.rs, which belongs to the harden(dig-wallet): chain.rs:111 with_sources is dead code that builds a single-source peak_height path #360 lane (PR fix(node): dead transport ctor, temp-dir leak, version-gate reporting, executed sweep examples #368). Not touched here, enumerated in SPEC so nobody infers corroboration from the rule above.

chia-query PR#39 was evaluated and is NOT consumable here

Measured, not assumed: dig-node-core declares no chia-query dependency at all (the dormant light client was removed, and its chia-query = "=0.5.1" pin was exactly what held this crate off chia 0.36), and chia-query is now 0.17.0, entirely on chia ^0.36 against this crate's ^0.26. Consuming it re-adds the shed dependency and drags the stranded line — reported, not shimmed. Its principle is the one implemented here, one layer out; and this path does not run through the chia-query router at all, it is the digstore_chain singleton walk.

Checklist

• Anchored-root resolution corroborated across independently-held sources
• _by_puzzle_hashes / _by_hints / _by_parent — stated (same treatment), other lane owns the file
• Mempool submission — stated
• A test per corroborated path proving a single dissenter causes a REFUSAL, each with a control killing the always-refuse implementation

Two defects found in my own work, both by existing guards

• banned_address_patterns caught me building an address by concatenating host and port. Real: this module strips IPv6 brackets when parsing, so re-joining yields ::1:8555 and would fail to resolve every v6 endpoint on a §5.2 IPv6-first dial path. Now lookup_host((host, port)).
• A revert-proof caught a false green of mine: the transitivity fixture put the bridging endpoint in the MIDDLE, so only one group ever existed and merge-into-all and merge-into-first agreed on every input — the revert left it GREEN. Rewritten with the bridge LAST; it now fires.

Evidence

fmt 0 · clippy -D warnings 0 · dig-node-core lib 1000/1000 · dig-wallet lib 656/656 · all five required CI contexts SUCCESS asserted BY NAME, 0 unresolved threads. Revert table in the PR body. Versions bumped 0.155.0 / 0.59.0 / 0.36.0.

Follow-up found, not fixed here: profile_sync's test temp dirs leak (223 measured on this machine). I made the name unrepeatable across runs, which is what removed the red; the leak needs a drop guard per test.

[MichaelTaylor3d]

Gate round 2 — CHANGES-REQUIRED addressed. Took option (a). Branch loop/365-366-nc12-anchored-root, PR #369, still DRAFT.

The finding was real, and I reproduced it before fixing

With T = () the unanimity check answers.iter().any(|a| *a != candidate) is vacuously false — () always equals (). So verify_pinned_root and verify_lineage_root were a flat 2-of-N threshold, and a reached voice's REJECTION landed in refusals and was discarded as unreachability. anchored_state, which carries a value, was correct on byte-identical input. The two calls the read-path pin actually makes were the two without the property.

Why (a), not the (b) floor

The classification already existed at the source and only needed a channel to travel in, so this was contained rather than a rewrite:

• verify_lineage_root already separated the cases structurally — a COMPLETED walk whose history lacks the root is a rejection; a FAILED walk is unreachable. No extra call.
• verify_pinned_root delegates to a digstore function that collapses both into one error, so reachability is probed (unspent_coins_by_hint — the read that function itself begins with) only on the failure path.

New Verdict::{Confirmed, Rejected, Unreachable} plus a narrow ChainVoice trait carry it. AnchoredRootResolver, the node-wide contract consumed across the crate, is unchanged — no breaking surface added.

The residual ambiguity fails in the refusing direction on purpose. The probe races the call it classifies; if the chain drops in between, a genuine unreachability is recorded as a REJECTION, which refuses. The opposite error is the defect being removed and fails open.

The rule now, genuinely shared by all three calls

1. Any reached voice that REJECTS vetoes — decided when seen, never weighed against confirmations.
2. Otherwise two must CONFIRM; unreachable voices are dropped, and too few is THIN EVIDENCE, not disagreement — the messages distinguish them, because an outage and an attack demand opposite remedies.
3. One voice is the default install and answers alone.

The bar rises with N because every added source can VETO, not because more must agree.

Half two — closed by the same fix, and now proven

content_serve.rs:430, dig_rpc/dispatch.rs:102 and module_reshare.rs:931 fall back to verify_pinned_root on a failed tip resolution — exactly where a widened Err would have been laundered into a serve. That is safe only because the fallback now carries the same dissent rule, and since it is a composition property the new test asserts both legs refuse on the same fixture. store_melted.rs:433 matches the same arm and returns MeltStatus::Unknown, already fail-closed.

The missing fixture, added

Voice::Rejects — a REACHED voice that says no. Its absence is exactly why this shipped untested: every earlier fixture scripted only Unreachable, which both semantics treat identically.

fixture	must
2 confirm + 1 reject	REFUSE — the gate's own probe, inverted
9 confirm + 1 reject	REFUSE — the bar rises with N
9 confirm + 1 unreachable	SERVE — control; silence is not dissent
tip refuses → bounded fallback	ALSO refuse — the composition

Revert-proof: restoring the shipped threshold makes this test — and only this test — fail.

SPEC corrected

§14.4b no longer claims a property the code lacks: it states the veto clause, says a flat k-of-N threshold does NOT satisfy it and why, and records that the bar rises through the veto rather than the count.

Non-gating items folded in rather than filed

DIG_NODE_CHAIN_ENDPOINTS added to both env tables · crates/dig-node-core/SPEC.md §4.1 rewritten (it still described CoinsetResolver as production) · §14.4b now recommends three or more, with why two is the most fragile accepted count · voices() per-group failover doc corrected by stating the design (a group's members are the same machine, so a second member is a retry, not a fallback) · DNS lookups now concurrent and bounded at 3s, timeout = unreachable = fail-closed · store-id disclosure to N third parties documented · dig-ipc-protocol pinned =0.3.0.

Evidence

fmt --check 0 · clippy -D warnings 0 · cargo test -p dig-node-core -p dig-wallet --all-targets exit 0 (1001 lib + every integration target + dig-wallet 656, zero failures). Rebased onto 7ea14fe; only the CHANGELOG commit differed, so nothing audited moved.

Process note worth keeping: the earlier IPv6 concat defect was invisible to --lib and only CI caught it. All-targets is now the local bar.

[MichaelTaylor3d]

Rebased onto 240732e6 (PR#368 merged). Three checks the coordinator flagged, all done and all measured.

1. The sources.rs collision resolved — and it merged with NO conflict, which is exactly the case that loses a property silently. So I verified rather than trusted:

• Both rust_files(...) call sites still name BOTH crates. They are driven from swept_roots(), whose list is ["dig-wallet", "dig-node-core"]; the only CARGO_MANIFEST_DIR use left is inside swept_roots deriving the workspace dir. The NC-12: the sole-owner sweep walks dig-wallet ONLY — dig-node-core is unguarded #366 scope widening is intact.
• fix(node): dead transport ctor, temp-dir leak, version-gate reporting, executed sweep examples #368's executed-fixture shape is preserved — its 6 JSON worked-example blocks and its every_worked_example_in_the_docs_is_executed_against_the_real_classifier test.
• My dig-node-core re-measurement paragraph survived.
• sole_owner_tests is now 8/8 — my 7 plus fix(node): dead transport ctor, temp-dir leak, version-gate reporting, executed sweep examples #368's doc harness. That harness passing against the merged doc block is the strongest evidence the resolution is semantically clean: it executes the doc's own claims against the real classifier.

2. The stale [5] numbers — not present in my text. #368's rewrite removed the unwritten-fixture example and its reconstructed fixture measures [6]/[] (lines 597/614). My paragraph never quoted them, so there was nothing to correct.

3. The version trap hit exactly as warned. main had taken 0.155.0 and dig-wallet 0.36.0 — identical to mine — so the rebase dropped both bumps as "already upstream", invisible to git status, the diff, fmt, clippy and tests. Now 0.156.0 / dig-wallet 0.37.0; dig-node-core 0.59.0 was unaffected (main is 0.58.0). Cargo.lock re-resolved.

Post-rebase: fmt --check 0, clippy -D warnings 0. Full --all-targets re-running. Head 5ab2438, PR still DRAFT.

The gating finding was already fixed and pushed before this message arrived — option (a), the Verdict::{Confirmed, Rejected, Unreachable} tri-state, plus the Voice::Rejects fixture and the corrected SPEC. Detail in the PR body and the #365 comment.

[MichaelTaylor3d]

Post-rebase status: GREEN on CI, head 5ab2438, PR #369 still DRAFT.

All five required contexts SUCCESS asserted by name, mergeStateStatus=CLEAN, 0 unresolved threads. check-merge-preconditions.sh exits 1 solely on draft=true.

One thing to know about my local runs, because I am not reporting them as evidence. Two post-rebase --all-targets runs went red on this machine with different failure sets (3, then 8). Both were Os { code: 112, kind: StorageFull } — every single failure, 3-of-3 and 7-of-8 with the eighth a downstream panic. The disk hit 100% (11G free). Not the code, not the rebase, and the differing sets are just which tests happened to run when space ran out. CI, on a clean runner, is green on this exact head.

I have deleted my own worktree's target/ (25G) and .gitnexus per §1.6, taking the machine back to 30G free. I have NOT touched anything outside my worktree — in particular there are 1048 leaked .tmp* directories in %TEMP% from tempfile-based tests across lanes, plus 14 more dig-profile-sync-test-*. That is very likely the real space consumer and it is a cross-lane cleanup, so it is the orchestrator's call, not mine; a sibling lane may be live in those directories right now.

This is the same leak I flagged earlier in this lane: I fixed the profile-sync temp dir's name collision (which was causing false reds), but the leak itself is untouched and needs a drop guard per test. At 1048 directories it has stopped being a tidiness issue.