fix(forwarded-ask): a hop's absence_established lie STRENGTHENS this node's claim, contradicting the NC-12 comment above it

[MichaelTaylor3d]

Task

crates/dig-node-core/src/seams/dig_peer/forwarded_ask.rs:437-439 asserts a monotonicity property
that the code does not have. Decide whether the CODE should be changed to match the claim, or the
CLAIM narrowed to match the code — and land whichever, with the test that pins it.

The comment, verbatim:

A hop can of course LIE here, like anything else it tells us (NC-12) — but the value can only
ever WEAKEN the claim this node goes on to make, never strengthen it. There is no direction in
which lying about this field buys reach.

The first sentence is false. The second is true.

The measured trace

A peer answering {"result":{"items":[{"available":false,"absence_established":true}]}} when its own
subtree search did NOT complete moves this node from inconclusive to proven-absent:

1. forwarded_ask.rs:349-356 — SubtreeClaim::Established maps to AskOutcome::Answered(records);
   NotEstablished | NoClaim map to AskOutcome::AnsweredInconclusive(records).
2. download.rs:2047-2064 — the Answered arm extends the records and does not clear
   answers.conclusive. Every other arm, including AnsweredInconclusive, sets it false.
3. download.rs:1822-1829 — LocatedHolders { records, conclusive: first_hand_conclusive && forwarded.conclusive }.
4. download.rs:973-975 — establishes_absence() is self.records.is_empty() && self.conclusive.
5. download.rs:963-966 names the two production consumers: NodeContent::miss_outcome and
   Node::availability_answer. The second re-emits absence_established: true to the next hop,
   so this node republishes the lie as its own establishment and the falsehood travels.

So the honest answer (false, or the field absent) yields an inconclusive miss the requestor may
retry, and the lie (true) yields a settled not-found. That is a strengthening, in the exact
direction the comment says is impossible — and it is the manufactured not-found dig-node#273
exists to prevent, which this same doc block names as the harm four paragraphs earlier
(forwarded_ask.rs:425-428).

The file's own tests already demonstrate the mechanism. forwarded_ask.rs:1036-1050
(absence_established_is_read_as_three_states_and_absent_is_not_true) asserts
subtree_claim(Some(true)) == Established and subtree_claim(Some(false)) == NotEstablished. The
comment contradicts the assertions sitting 600 lines below it in the same file.

What bounds it, stated so severity is not overstated

• The forwarded/recursive leg ships DISABLED, so a stock node never reaches this function.
• answers.conclusive is an AND-fold over every peer asked, so a liar cannot manufacture an
  absence over an honest peer's objection. Its marginal power is to remove its own veto —
  decisive exactly when it is the only otherwise-inconclusive voice, which includes the one-peer case.
• The lie buys no ranking or conduct advantage, which is why the comment's second sentence is
  true: ask_routing.rs:178-190 folds Answered([]) and AnsweredInconclusive([]) both to
  dig_sex::AskOutcome::Inconclusive, and download.rs:2038-2044 folds both to
  ConductEvidence::HonestAnswer. A peer gains nothing by lying here except the one flip above.
  That equivalence is itself untested and is worth pinning in the same pass.

The fork this needs decided

Trusting one peer's absence_established: true at face value is a deliberate design choice
(SubtreeClaim::Established, forwarded_ask.rs:411), not an oversight — so this is not a
change to make inside a doc audit.

• (a) Narrow the claim. Say what is actually true: a lie can remove the liar's own veto on
  conclusiveness, and nothing more; it buys no reach. Cheapest, and honest.
• (b) Make the code match the claim — require corroboration before an established absence is
  relayed onward, which is NC-12's ~5-peers-must-agree shape applied to absence as it already is to
  content. Larger, and it changes the wire meaning of a conclusive miss.

Either way the outcome is pinned by a test that fails if the property changes.

Evidence bar

Whichever way it lands, the guard must fail for the RIGHT reason. A test that distinguishes
"this node relayed the peer's establishment" from "this node reached its own conclusion" needs
two distinguishable inputs and a pinned inequality — a single-value fixture cannot tell threading
from ignoring (the lesson from PR #353's relay fixture).

Provenance

Found by the NC-12 doc-claim audit, dig-node#356 / PR #504, which measured this claim rather than
rewording it. Not fixed there — the audit's scope discipline holds a security change out of a
sweep so the sweep stays gateable.

Parent: https://github.com/DIG-Network/dig_ecosystem/issues/3128
Audit: #356

[MichaelTaylor3d]

Severity note — MEDIUM/HIGH depending on recursive-download default

From the 15:04Z security review of PR #504:

#508's stated bound — "one liar's marginal power is to remove its OWN veto" — does not hold, because an honest node LAUNDERS the lie:

Once A is lied into conclusive == true, A emits absence_established: true (lib.rs:4155-4160). B reads it through subtree_claim, gets Established, takes the Answered arm, and A's veto is removed at B too. The fold is per-peer and independent, so nothing recovers the suppressed signal at any depth.

Severity: MEDIUM while the recursive leg ships disabled (download.rs:290, :321-327).
Severity: HIGH if it ever defaults on.

Source: loop-security audit on PR #504, section D (15:04Z).

[MichaelTaylor3d]

Lane claimed — orchestrator owns this end-to-end

• Branch: loop/508-absence-establishment
• PR: fix(forwarded-ask): a hop's absence_established must not strengthen this node's absence claim #516 (DRAFT — do not merge)
• Base: origin/main @ 04079d57, version claimed 0.258.0 (was 0.252.4)
• Anchor SHA: f9f6d3bb

Trace verified against origin/main, not re-derived

The ticket's chain holds exactly as written. download.rs is at
crates/dig-node-core/src/download.rs, not under seams/dig_peer/ — the ticket's paths for it are
off by a directory, the line numbers are right.

Two additions the ticket does not carry:

1. The laundering is confirmed at lib.rs:~4150-4162. availability_answer inserts
   absence_established: located.establishes_absence() on the not-held branch, so once this node is
   lied into conclusive == true it republishes the establishment as its own. The next hop reads
   Established, takes the Answered arm, and the liar's veto is removed there too. This refutes
   the ticket's own stated bound ("marginal power is to remove its OWN veto") — the fold is
   per-peer and independent, so nothing recovers the suppressed signal at any depth.
2. The lie is free, and that is now measured. ask_routing.rs:178-190 folds Answered([]) and
   AnsweredInconclusive([]) both to dig_sex::AskOutcome::Inconclusive; download.rs:2038-2044
   folds both to ConductEvidence::HonestAnswer. A peer pays nothing for the lie in either routing
   or conduct. That equivalence is untested today and gets pinned in this pass.

Next action

Shape is with a loop-decider (Opus, high effort) before any implementation — §1.10, and the ticket
is right that SubtreeClaim::Established is a deliberate choice rather than an oversight. The
decider is briefed against three constraints: the fix must make the lie unprofitable rather than
detected, it must separate a refusal to answer from a claimed absence, and if it recommends
corroboration it must state what makes decide_forward's sources independent given an attacker who
can influence the pool.

forwarded_ask.rs:~1052-1063 currently asserts "only Established may become a conclusive miss", so
a code-side fix must deliberately rewrite that test rather than quietly delete it.

Gates queued: loop-reviewer + loop-security + an adversarial loop-decider prompted to REFUTE —
specifically to construct a lie that still profits the hop after the fix.

[MichaelTaylor3d]

Decision — the fork is settled: (b), in a one-line shape

A forwarded ask, once ISSUED, permanently clears this node's conclusive flag.
ForwardedAnswers::asked() (crates/dig-node-core/src/download.rs:1019-1023) returns
conclusive: false instead of true. One field, one call site (:1989).

Why this and not corroboration

Absence has no witness. Content is safe to accept from a stranger only because the merkle root
verifies it; there is no verifier for "nobody has it". So a node may establish an absence only from
its OWN completed search, never from testimony. Every other shape leaves some function
f(stranger's bytes) -> our assertion of absence, and any such function is profitable to lie to.

This reframes the fork as the ticket stated it. The question is not "trust one peer vs trust N
peers". It is whether peer testimony is admissible evidence about absence at all. It is not.

Corroboration was considered and rejected, for three independent reasons, any one sufficient:

1. The ask set is attacker-influenceable. decide_forward selects over dialable_pool() =
   connected_pool, populated by discovery/PEX/address book. A peer that can seed the pool selects
   its own corroborators. N answers from a set the attacker shaped is one answer wearing a hat.
2. Eclipse collapses any bound to 1. A k-of-n threshold becomes k-of-n sockets, not k-of-n
   parties. NC-12's ~5-peers-must-agree survives eclipse only because the thing agreed on is
   content, which verifies independently of who said it. The analogy fails at exactly the point
   that makes NC-12 sound.
3. Even with perfect independence it is unsound. Honest peers agreeing "I did not find it" is
   testimony about their searches, not about the content. A quorum of absence is a quorum of
   ignorance.

This finishes #273 rather than extending it

#273 closed silence-becomes-assertion (unwrap_or(true)). This closes
stranger's-assertion-becomes-our-assertion — the identical class, with one door left open. The
file's own principle at forwarded_ask.rs:425-428 already argues an over-reported inconclusive
costs a retry while an over-reported absence costs content that exists and cannot be found. It just
was not applied to the Some(true)-from-a-stranger case.

The lie is unprofitable, structurally — not merely detected

After the fix the field is not read by any decision, so no value of it can move any decision.
Every row of the attacker-gain table (true, false, absent, malformed, empty items, refusal,
timeout) yields no gain, and the proof is structural rather than case-by-case.

That includes a second route the ticket does not name: the held && !records.is_empty() early
return at forwarded_ask.rs:~347 also takes the Answered arm and preserves conclusiveness today.
If every forwarded record were dropped downstream (merge_answers' hearsay cap, the self-filter,
the dedup) while conclusive stayed true, records.is_empty() && conclusive would fire. It is
unreachable on today's constants only by two accidents — the cap is 8, and the responder's own
record happens to be placed first so it survives take(8). Reorder that vec or set the cap to 0 and
it goes live. Fixing at subtree_claim could not see this route at all; fixing at asked() closes
it structurally. Recorded here so a future cap change re-reads it.

Vacuity, stated explicitly rather than reported as satisfied

After this fix absence_established: true is unreachable for any node that actually issued a
forwarded ask — i.e. recursion-enabled nodes with at least one eligible peer. It stays reachable
for recursion-disabled nodes, which is the shipped default and the only "stock posture" SPEC
names. SubtreeClaim's three states become production-vacuous: the parse and its tests are KEPT
(they pin the wire reading other implementations emit against) but the doc now says so, because a
state distinction that governs nothing while documented as governing something is the exact class
this ticket is about.

The cost is bounded and the contract already tolerates its shape: SPEC 3487-3568 already makes
absence unprovable for a spent budget, a spent hop cap, no eligible peer, no free slot, and a
claimed walk. This adds one more case to a list that exists, and it fails toward keep looking.

recursion_disabled() returning conclusive: true is preserved exactly — breaking it would
make every miss on every stock node inconclusive, the opposite-direction lie.

Wire impact: NO. SPEC impact: YES, this repo only

dig_rpc_protocol::AvailabilityAnswer is untouched and stays Option<bool>. The field's meaning
is the emitter's claim about its own search and is unchanged; what changes is only what this node
does when it reads a stranger's claim. So no dig-rpc-protocol change, no consumer cascade, no
SYSTEM.md change. dig-node's own SPEC.md:3546-3552 three-state table DOES change in the same PR
(§4.2) — its reading column only.

Blast radius by grep + direct read (the gitnexus index is ~301 commits stale on dig-node and returns
false-safe zeroes): LocatedHolders.conclusive has exactly ONE consumer, establishes_absence(),
which has exactly two production callers — NodeContent::miss_outcome and Node::availability_answer.

Pinned by

• T1 three engines differing only in the peer's frame (true / false / ABSENT): all three
  !establishes_absence() and equal to each other, plus the inequality against an engine
  with no asker installed, which MUST establish. Two distinguishable inputs and a pinned inequality
  — a single-value fixture cannot tell threading from ignoring.
• T2 the holder-arm route above.
• T3 the untested equivalence the ticket names: Answered([]) and AnsweredInconclusive([])
  fold identically in routing and conduct, with TimedOut pinned as different so it is not vacuous.
• T4 the existing a_node_that_never_asked_still_answers_a_plain_absence, retained unchanged as
  THE anti-vacuity control — now the only thing standing between this fix and "every miss is
  inconclusive".

Existing tests that INVERT are rewritten deliberately with a doc saying why, never deleted —
including forwarded_ask.rs:~1052-1063 ("only Established may become a conclusive miss") and
forwarded_ask_tests.rs:1022-1036 (a_peer_that_answers_nobody_does_establish_an_absence).

Baseline before the change: seams::dig_peer::forwarded_ask::tests = 20 passed, 0 failed
(1081 filtered out — the filter matches, so this is a real green rather than a vacuous one).

Implementation is in flight on loop/508-absence-establishment / PR #516. Gates queued: reviewer +
security + an adversarial decider prompted to construct a lie that still profits the hop after the fix.

[MichaelTaylor3d]

Version corrected: 0.258.0 -> 0.252.5, and it surfaced a repo-wide wall

The 0.258.0 this branch claimed was unbuildable. All four package jobs failed identically at
"Resolve + validate the package version" (run 33704504183):

package-version: minor version 258 exceeds the MSI ProductVersion limit of 255

scripts/package-version.sh:70-72 caps MAJOR <= 255, MINOR <= 255, PATCH <= 65535, because
Windows Installer either rejects an out-of-range ProductVersion field or silently truncates it,
which would make two different versions compare EQUAL. The validator is correct and was not touched.

The bump was also wrong on its own terms: this branch is a fix, and CLAUDE.md 2.4 maps
fix->patch. A minor was never owed.

Retaken as 0.252.5 — a patch off main's 0.252.4. Legal under the ceiling, correct SemVer, and it
deliberately does NOT consume one of the three remaining legal minor slots. Only Cargo.toml:35 and
Cargo.lock:3034 (dig-node-service) moved; the other 0.258.0 entries in the lock are upstream
wasm-encoder and wasmparser and were left alone — a blind sed would have corrupted them.

The wall is filed separately as #522 and is out of
scope here. In short: origin/main is at 0.252.4, only 0.253/0.254/0.255 remain legal, all three are
already claimed by open PRs, and six open PRs (#505, #515, #517, #518, #519, and this one before
the fix) already sit red at the package gate. After the three legal slots merge, every subsequent PR
in this repo fails four required checks and no package can be built.

Head is now 5fc1b2c2. The code under gate is byte-identical to f7ae07d9; all three gates were
told the SHA moved and why.

[MichaelTaylor3d]

Correction: the severity escalation on this ticket was WRONG, and I repeated it

The implementing lane reported a second exploit route "that does not go through absence_established
at all" — a peer replying "you hold it", whose record the self-filter then removes — and concluded
"#508 was exploitable by a peer that never touched the field the ticket is named after."

That is false. Two independent gates traced the wire path and reached the same answer, and it
matches the reading that prompted me to ask them:

There are exactly two ways to reach AskOutcome::Answered.

1. The held && !records.is_empty() arm (forwarded_ask.rs:347) always leads with
   responder_record, minted for the responder, which survives the self-filter. For it to be
   None you need an unparseable peer hex or empty addrs — and both are unreachable:
   dialable_pool filters addrs.is_empty() (download.rs:2117), and NatForwardedAsk::ask
   returns Unreachable for both before the parser is ever called (forwarded_ask.rs:593-598).
2. SubtreeClaim::Established (:353) — the original wire lie.

The all-dropped state IS production-reachable, but only in the shape "absence_established: true
plus a providers entry naming us". That is the original lie with an extra step, not an
independent door. The one-line fix closes both, and the severity of #508 is unchanged from the
MEDIUM/HIGH already recorded above.

Why this is worth writing down rather than quietly fixing. The claim was asserted in a test's
doc comment, which is where this repo has repeatedly shipped claims that were false in the very
commit that wrote them — the same class as the absence_established comment that #508 exists to
correct. It was caught only because the fixture bypassed parse_forwarded_answer through the
PerPeerAsk test seam, so it demonstrated its scenario without demonstrating that the wire could
produce it. A fixture that reaches a state production cannot reach proves nothing about
production, in either direction.

The test is being KEPT — the merge-layer property it pins (an emptiness produced by FILTERING is not
a search that found nobody) is real and worth guarding. Only its doc and its claimed severity are
being corrected.

And the property is genuinely live somewhere — just on the other leg. The adversarial gate found
that retain_excluding_self runs inside walk_for_providers (download.rs:2201), i.e. after
first-hand conclusiveness is decided, so the same shape exists on the DHT leg that ships by default.
It is not exploitable today only because dig-dht-0.15.0/src/service.rs:596-609 refuses
AddProvider unless provider_peer_id matches the authenticated mTLS caller — a cross-crate
dependency stated nowhere in SPEC.md or in locate_holders. Filed as a follow-up rather than
folded into #508.

[MichaelTaylor3d]

Two findings from the adversarial gate, recorded as COMMENTS rather than tickets

Both are real and both are OUT of scope for #508. Recording them here with file:line rather than
filing, because §1.3c rule 4 caps a lane at net-non-positive issue inflow and this lane has already
opened #522. Promote either to a ticket if you disagree
with the bar — the analysis below is complete enough to act on cold.

1. The first-hand leg has the SAME shape #508 just fixed, on the DEFAULT path, held safe only by a guard in another crate

retain_excluding_self runs inside walk_for_providers (download.rs:2201), and
retain_excluding_self_tagged again at the merge (:1866) — both after first_hand_conclusive
is decided. So a DHT walk that returns N records all naming this node becomes Ok(vec![]) while
conclusive stays true: a proven absence resting on records that named a holder. That is
precisely the defect class #508 fixed, on the leg that ships by default and needs no opt-in.

It is not exploitable today, and the reason is not in this repo.
dig-dht-0.15.0/src/service.rs:596-609 refuses AddProvider unless provider_peer_id matches the
authenticated mTLS caller, so a stranger cannot publish a provider record naming you. The only
records the self-filter can empty are this node's own stale announces — honest, not laundered.

Why it is worth writing down. That cross-crate invariant is stated nowhere — not in
SPEC.md, not in locate_holders' docs, not at either filter site. download.rs:1584-1585 holds
two dormant Empty sources in the union. If a PEX or relay-introducer source is ever un-dormanted
without the same admission rule, a stranger-supplied self-named record yields a false proven
absence on the stock configuration. The cheapest durable fix is to decide first-hand conclusiveness
after the self-filter, mirroring exactly what #508 did for the forwarded leg — which would make
the invariant structural instead of inherited.

Note this is the same property T2 was written to pin. T2 pins it on the forwarded leg, where the fix
has now made it unreachable; it is live here.

2. A recursion-enabled node can no longer emit a terminal not-found, and the retry has no bound

After this fix forwarded.conclusive is permanently false on a recursion-enabled node, so every
miss answers MissOutcome::Inconclusive. miss_refusal_envelope (download.rs:3120-3125) documents
that code as meaning "try again", and each retry costs a full fan-out — where before, a clean
fan-out could terminate the search.

This is the accepted cost of the fix and I judge it correctly chosen: the harm asymmetry holds
(an over-reported inconclusive costs a retry; an over-reported absence costs content that exists and
cannot be found), it falls only on the opt-in configuration, and SPEC states it. But two things are
unguarded: "the answer is now a constant on this configuration" is a property no test asserts, and
the retry side carries no stated bound. Worth either a bound or an explicit
"unbounded retry is intended, and here is why" — currently it is neither.

[MichaelTaylor3d]

Addendum to the 02:28Z correction — two inaccuracies in the correction itself

Caught by the fresh review gate on PR #516 at head 467cef59. Neither changes the conclusion (the severity stays MEDIUM/HIGH as first recorded, and the "exploitable by a peer that never touched the field" claim stays retracted), but a correction that is itself imprecise is the same class this ticket exists to close.

1. Stale line numbers. The correction cites forwarded_ask.rs:347 / :353 and download.rs:1866. Those were right when written and have since moved. Current, verified at 467cef59:

• forwarded_ask.rs:351 — the held && !records.is_empty() arm
• forwarded_ask.rs:355 — SubtreeClaim::Established
• download.rs:1870 — the merge-site retain_excluding_self_tagged call

2. The dig-dht guard was stated without its qualifier, which slightly overstates the safety argument. The correction says dig-dht-0.15.0/src/service.rs "refuses AddProvider unless provider_peer_id matches the authenticated mTLS caller". It does — but only when the transport supplies a caller identity. The crate says so itself (service.rs:596-613):

A caller we cannot identify (handle_request, no transport-supplied identity) cannot be checked and is let through unchanged - that path already deviates from the mTLS-authenticated model.

That matters because the first-hand-leg finding in the 02:30Z comment rests on this guard. The guard is real and the finding is still not exploitable through the mTLS path, but "held safe by another crate's invariant" is more precisely "held safe by another crate's invariant on the authenticated path only". The recommended durable fix is unchanged and is now the better one for exactly this reason: decide first_hand_conclusive after the self-filter, which makes the property structural in this repo instead of inherited from a conditional guard in another.

Both corrections are carried in the test's doc comment at crates/dig-node-core/src/forwarded_ask_tests.rs, so the accurate version lives next to the code rather than only in this thread.