Attach unverified_mirror_coin_id at the DHT announce (blocked on the dig-dht 0.15 cascade)

[MichaelTaylor3d]

Task

Step 7's DHT pointer half — attaching unverified_mirror_coin_id to this node's provider
announce (crates/dig-node-core/src/seams/dig_peer/dht.rs, announce_inventory_ids) and
re-announcing on epoch rollover — is BLOCKED upstream and cannot be unblocked by a version edit in
dig-node.

The measurement, re-taken 2026-08-30 against index.crates.io

crate	latest published	requires
dig-download	0.21.0	dig-dht ^0.13
dig-peer-selector	0.10.0	dig-dht ^0.13
dig-dht	0.15.0	—

^0.13 and 0.15 are semver-INCOMPATIBLE on a 0.x line, so declaring dig-dht = "0.15" in
dig-node resolves two dig-dht lines while cargo prints success. ProviderRecord::unverified_mirror_coin_id
lives in dig-dht 0.15 (dig-dht#23) and a repo-wide grep for that identifier returns zero hits in
the dig-node tree.

Bridging the two lines with a shim is the byte-drift class this ecosystem does not do.

Resume condition — checkable, not a judgement

dig-download and dig-peer-selector both release against dig-dht ^0.15. Then dig-node takes the
tier in one bump (measured from the LOCK, never the caret — name every crate explicitly with
cargo update -p <crate>, since a caret-compatible transitive is invisible to cargo fetch and can
leave two lines alive while reporting success).

What the pointer must then do

• It is UNTRUSTED (NC-12): it tells a verifier where to look, never what the coin is. Its absence
  must not degrade discovery and must not read as a fault.
• A verifier accepts a coin only on the coin's own evidence — at the mirror puzzle hash, genuinely
  $DIG with the asset id re-derived from the creating spend, carrying the declared collateral, and
  MirrorCoin::advertises(store, root, epoch) passing.
• Re-announce on epoch rollover. dig-dht has no clock, and republish re-attaches whatever was
  recorded at announce time — so an un-refreshed pointer is wrong one epoch after publication, and a
  correctly-collateralised node reads as uncollateralised.

Parent

#412 ·
#377 ·
epic https://github.com/DIG-Network/dig_ecosystem/issues/3166

[MichaelTaylor3d]

Cascade STARTED — both blocking crates have lanes, 2026-08-30

The resume condition on this ticket is "dig-download and dig-peer-selector both release against
dig-dht ^0.15". Both are now in flight, in their own worktrees and repos:

crate	at	declares	lane
dig-download (30-network)	0.21.0	dig-dht = "0.13" (Cargo.toml:73)	loop/dht-015-uplift
dig-peer-selector (30-network)	0.10.0	dig-dht = "0.13" (Cargo.toml:171)	loop/dht-015-uplift

They run in parallel, not in sequence. Both sit at level 30-network and Appendix B is
reference-DOWN-only, so neither can depend on the other — checked, and neither declares the other.
dig-dht is at 20-domain, strictly below both. So there is no release-first ordering between
them; both must simply land before dig-node takes the tier.

The two rules each lane carries, because this cascade is where they were learned

§2.4b — bump every dig-*/chia-* dep, not just dig-dht. dig-peer-selector is the named
example of why: it sat two minors behind dig-nat since 2026-08-08 with nothing detecting it,
and dig-peer-selector = "0.9" was itself the invisible edge in a later cascade — 0.9.0 still
declared dig-nat ^0.18, so the old line survived a re-resolve that printed "Locking 9 packages to
latest compatible versions". So I expect dig-nat in that lane's bump list, not only dig-dht.

Verify from the resolved LOCK, never the caret. A caret-compatible transitive is invisible to
cargo fetch, which is exactly how two lines stay alive while cargo reports success — the failure
this ticket exists to prevent. Each lane names every crate explicitly with cargo update -p <crate>
and checks the lock delta is what it expected.

No shim, either way. If a delta does not line up, the lane reports the shape and stops rather
than bridging two versions — that is the byte-drift class, and it is the whole reason this is a
cascade instead of a one-line edit in dig-node.

What is still true and unchanged

dig-node takes the tier in one bump once both are published, measured from the lock. The pointer
itself stays UNTRUSTED (NC-12) — it tells a verifier where to look, never what the coin is, its
absence must not degrade discovery or read as a fault, and it must be re-announced on epoch
rollover, since dig-dht has no clock and republish re-attaches whatever was recorded at announce
time.

[MichaelTaylor3d]

Cascade: one of two SHIPPED, 2026-08-30

crate	before	after	state
dig-peer-selector	0.10.0, dig-dht = "0.13"	0.11.0, dig-dht = "0.15"	MERGED 9b2355c7, publishing to crates.io
dig-download	0.21.0, dig-dht = "0.13"	0.22.0, dig-dht = "0.15"	PR #47, one test left

The guard that fired, and why it is good news

dig-download's tests/dependency_tree.rs:181 — the_locator_is_on_the_cascaded_dht_line — failed
on the uplift. Its split check passed (versions.len() == 1, "one dig-dht only"); it failed only
on the line pin starts_with("0.13.").

That is the test doing exactly its job. Its own doc says what it catches: "a caret like
dig-dht = "0.8" means >=0.8.0, <0.9, which can NEVER reach 0.9.0 … Two dig-dht entries would also
make dig_dht::ProviderRecord two distinct types across the locate boundary." That is a written-down
statement of this ticket's entire premise, guarded by a test, in the consumer.

The property behind the pin survives the uplift, measured in the lock rather than taken from a lane's
report: dig-dht 0.15.0 and dig-nat 0.21.0, one entry each, and 0.15's package dependency list
still includes dig-nat. So 0.13's stated reason — carrying dig-nat 0.21 plus the bounded
ProviderStore::snapshot — holds at 0.15. The pin moves; it is not weakened, and the len() == 1
assertion is untouched.

Two things salvaged from lanes that died to a session cap

Both survived only because of push-early (§1.8), and both are worth recording as the cost of not:

• dig-peer-selector had pushed only a stub commit; the real 0.11.0 + dig-dht 0.15 edit was
  sitting uncommitted in the worktree. Reconciling from remote alone would have read this lane as
  having done nothing.
• The same worktree had a CRLF line-ending flip inflating Cargo.toml to a 407-line rewrite over
  a 13-line change. Restored before commit; the merged diff is 5 insertions / 5 deletions.

Remaining

dig-download #47 lands its repin, then both are published and dig-node takes the tier in ONE bump,
measured from the lock — naming every crate explicitly with cargo update -p <crate>, since a
caret-compatible transitive is invisible to cargo fetch and can leave two lines alive while cargo
reports success.

[MichaelTaylor3d]

CASCADE COMPLETE — both crates published on dig-dht 0.15, 2026-08-30

crate	was	now	merge	on crates.io
dig-peer-selector	0.10.0, dig-dht ^0.13	0.11.0, dig-dht ^0.15	9b2355c7	0.11.0 LIVE
dig-download	0.21.0, dig-dht ^0.13	0.22.0, dig-dht ^0.15	0db2925e	0.22.0 LIVE

The resume condition on this ticket is met. Both verified from index.crates.io after publish, not
from a workflow's conclusion — a cut that produces a tag but never becomes latest still serves the old
version.

The guard that caught the real risk

dig-download's the_locator_is_on_the_cascaded_dht_line (tests/dependency_tree.rs:181) failed on
the uplift. Its split assertion passed — versions.len() == 1, one dig-dht only. Only the line
literal was stale.

Before repinning it, the property behind the pin was re-verified from the lock, not from a lane's
report: dig-dht 0.15.0 and dig-nat 0.21.0, one entry each, with dig-nat still in 0.15's package
dependency list. So 0.13's stated reason — carrying dig-nat 0.21 plus the bounded
ProviderStore::snapshot — holds at 0.15. The pin moved; the len() == 1 assertion was left untouched.

The repin was then proven load-bearing: substituting "0.16." makes it RED with the resolved-version
message, "0.15." GREEN. A test edited until it passes, without that check, is indistinguishable
from a test that no longer tests anything.

Next, and the trap to avoid

dig-node takes the tier in ONE bump. Measure from the resolved LOCK, never the caret, and name
every crate explicitly with cargo update -p <crate> — a caret-compatible transitive is invisible to
cargo fetch and can leave two dig-dht lines alive while cargo prints "Locking N packages to latest
compatible versions". That is the exact failure this ticket exists to prevent, and it reports success
while doing it.

Then ProviderRecord::unverified_mirror_coin_id becomes reachable and the pointer work itself begins —
still UNTRUSTED (NC-12): it tells a verifier where to look, never what the coin is; its absence must
not degrade discovery or read as a fault; and it must be re-announced on epoch rollover, since
dig-dht has no clock and republish re-attaches whatever was recorded at announce time.

[MichaelTaylor3d]

Lane OPEN — the cascade is cleared, dig-node takes the tier

Worktree C:\tmp\worktrees\dn-422, branch loop/422-dht-mirror-pointer, draft PR
#431, base origin/main at 5df3e34.

The resume condition on this ticket is MET — dig-peer-selector 0.11.0 and dig-download 0.22.0
are both live on crates.io against dig-dht ^0.15, so ProviderRecord::unverified_mirror_coin_id
becomes reachable.

Order of work: (1) take the tier in ONE bump, naming every crate explicitly, and verify from the
resolved Cargo.lock that dig-dht, dig-download and dig-peer-selector each resolve to exactly
one line — never from the caret; (2) attach the pointer at announce_inventory_ids; (3) prove the
epoch-rollover re-announce specifically, since a test that only checks the pointer is attached once
passes forever while that half is broken.

Two lines would mean STOP and report, not a shim.

[MichaelTaylor3d]

Tier taken, pointer landed — head aa88106, PR #431 (draft)

The lock, measured rather than inferred

cargo update -p dig-dht -p dig-download -p dig-peer-selector (every crate named explicitly), then
counted from the resolved Cargo.lock:

crate	entries in Cargo.lock	version
dig-dht	1	0.15.0
dig-download	1	0.22.0
dig-peer-selector	1	0.11.0
dig-nat	1	0.21.0
dig-tls	1	0.4.0
dig-peer	1	0.13.0

No shim, no second line. chia-protocol (2) and chia-bls (5) are multi-line, and are unchanged
from origin/main — counted on both locks, pre-existing and not introduced here.

The shape

dig-node-core has no collateral-epoch knowledge of its own, so the pointer arrives through a seam:

• MirrorCoinPointers — epoch() plus a per-content coin_id_for(). Per content because a
  mirror coin bonds one (store, root, owner, epoch) tuple, so one node-wide pointer would send
  verifiers to a coin that does not advertise the capsule they asked about.
• Announce goes through announce_provider_with_collateral; announce_inventory_ids and
  sync_inventory keep their signatures and delegate with None.
• DhtHandle::reannounce_on_epoch_rollover() compares the source's epoch to the epoch the published
  pointers were drawn for, and run_maintenance calls it before republish — after would leave
  last epoch's coin id published for a further whole interval.

Proving the epoch half load-bearing

A test that only checks the pointer is attached once passes forever while the rollover half is
broken, so the fake's epoch and its coin ids move together, and the test pins the ambient truth
in the middle: service.republish() is called and the record is asserted unchanged, so the later
change can only have come from the re-announce.

Reverted only the fix (from a file copy, on committed work): stubbing
reannounce_on_epoch_rollover to return 0 — the "publish once, let republish refresh it"
implementation — makes it RED on "every announced id is re-announced on a rollover".

Residue, stated rather than hidden

The pointer source is not yet injected in production: the mirror coins live in
dig-node-service, and wiring them reaches server.rs, which PR #423 / #430 own. This PR plumbs the
seam end-to-end within dig-node-core and leaves DhtHandle::new publishing no pointer — which is a
normal, fully supported state, not a degraded one. Nothing user-facing claims a pointer is published,
so no surface is made to lie.