Wire dig-sex conduct (SPEC 8.2A) so peer behaviour actually feeds the dial budget

[MichaelTaylor3d]

Task

dig_sex::conduct -- observe, decay, dial_share, and the ConductEvidence classes -- is implemented, tested, and receives not one observation from dig-node.

Feed it real peer outcomes, and let dial_share shape which peers the node spends its dial budget on.

Why it matters

The SPEC is careful to separate a proven lie (bytes that fail verification against the chain-anchored root) and a self-contradiction (a peer that claimed to hold something, then answered absence) -- both verifiable, both allowed to persist -- from non-performance (timeout, reset, silence, truncation, slowness), which is not verifiable, must decay on elapsed time alone, must never reduce a dial share to zero, and must stay cheap enough that inducing it is not worth an attacker effort.

That distinction exists because an attacker can manufacture distress in an honest third party. None of it does anything today, because nothing calls observe.

Context

• The fetch/verify path is where a proven lie is detectable -- verification failure against the merkle root is the evidence.
• The holder-lookup path is where self-contradiction shows up: a peer that announced the capsule and then answered absence.
• The dial path is where dial_share should bias selection.
• Reputation is local and MUST NOT be gossiped. A shared reputation channel is a defamation primitive; keep it node-local.
• dig-sex SPEC.md section 8.2A.

Evidence

A test that fails without the fix: a peer returning bytes that fail verification loses dial share; a peer that merely times out repeatedly loses some and recovers on elapsed time alone, without needing to be talked to.

Parent

Orchestrator epic: https://github.com/DIG-Network/dig_ecosystem/issues/3138

[MichaelTaylor3d]

Lane loop/batch-digsex (worktree dn-digsex) owns this. Draft PR #456, branch loop/batch-digsex.

Measured before starting: dig-sex latest published is 0.5.0 (not 0.4 as the sibling ticket says), and dig-node already declares dig-sex = "0.5" at crates/dig-node-core/Cargo.toml:509. dig_sex::conduct, dig_sex::admission and dig_sex::reward have zero references anywhere in crates/ — so these three are genuinely unwired, as filed.

[MichaelTaylor3d]

Progress + a scoping finding that changes what "wired" can mean here

Branch loop/batch-digsex, PR #456.

ConductState (crates/dig-node-core/src/seams/dig_peer/conduct.rs) now holds per-peer ConductRecords keyed on RoutedPeer — the mTLS-verified peer_id, the same identity ask_routing ranks on, so conduct cannot be attributed to or escaped by a self-chosen identity. It is fed from the forwarded-ask loop (download.rs, the single ask_routing.record call site) and dialable() now filters the pool before decide_forward ranks it.

Two of the four evidence classes genuinely fire; two do not, and I am not reporting them as satisfied

Firing today: HonestAnswer (peer answered, including an honest absence) and NonPerformance (refused / timed out / unreachable). Both are produced on every forwarded ask.

NOT produced anywhere — ProvenLie and SelfContradiction. This is the vacuity the batch brief warned about, so stating it plainly rather than letting the wiring imply a capability the node does not have:

• ProvenLie needs per-peer attribution of a verification failure, and dig-node does not have it. Chunk attribution happens inside dig-download's engine against chunk_hashes — module_transport.rs:1587 says so explicitly: "The engine clips an overshoot and rejects a short range against chunk_hashes — attribution is ITS job, and duplicating the judgement here would let the two disagree." The node's own DownloadError surface offers only Transport/Sink/NotDownloadable; a whole-capsule mismatch (module_reshare.rs:1858, "assembled module_hash mismatch") is assembled from several holders and so names no single peer. Manufacturing a ProvenLie from a transport error would brand an honest peer on unverifiable evidence — the exact conflation SPEC 8.2A exists to prevent — so I have deliberately not done it.
• SelfContradiction needs the announced-then-denied pair correlated across the holdings-announce and the lookup answer. That correlation does not exist in the node today.

Both therefore need a dig-download change to surface the per-peer verification verdict (release-first, separate repo). Filing that as the follow-up rather than faking the evidence class here.

What the filter actually changes

dial_share returns exactly 0.0 for a proven fault and floors non-performance at MIN_NON_PERFORMANCE_DIAL_SHARE. So dialable() thresholds at "> 0.0", which excludes precisely the verifiably-faulty and can never exclude a merely-slow peer however sustained the slowness — the eviction primitive the floor exists to deny. Given the paragraph above, that exclusion path is currently unreachable in production: nothing produces a proven fault yet. The mechanism is correct and tested; it is dormant until dig-download surfaces attribution.