Nothing binds a mirror coin's owner to a DHT peer id — verification cannot name a claimant

[MichaelTaylor3d]

Task

The hint-scan fallback that both dig-node#466 and dig-dht's record.rs prescribe cannot be initiated from a provider record. Give the verifier a way to reach it.

The gap

dig_mirror_coin::discover requires owner_puzzle_hash — the namespace hint is morphed from it, so there is nothing to scan without it. A dig_dht::ProviderRecord carries a peer id, addresses, an expiry, and the optional unverified_mirror_coin_id. It carries no owner, and no peer_id → owner_puzzle_hash resolution exists anywhere in the repo.

So the fallback is unreachable from the only place that needs it.

Why this matters more than it looks

The contract is explicit that absence of the pointer is NORMAL — a publisher that has not created its coin yet, an older publisher, and one mid-epoch-rollover all legitimately omit it — and that a verifier MUST fall back to the hint scan, "slower, not weaker".

With no fallback, that inverts: a publisher who omits the pointer can never be positively verified, only left Unverified. The pointer becomes effectively mandatory for ranking, which is exactly what the contract says it must not be. The field is named unverified_ because it is meant to be an optional shortcut; today it is the only road.

PR #467 delivers the correct effect for the absent case — zero chain reads, holder unmoved, ranked Unverified — and its lane declared this limitation rather than faking a fallback. That is the right call; this ticket is the follow-through.

Two shapes, and the choice is not obvious

1. Add an owner field to ProviderRecord. Direct, but it is a wire change in dig-dht (release-first, §4.1), it grows every record whether or not anyone verifies, and the owner would be self-declared by the announcing peer — so it is another untrusted input, not an authority. A lying owner sends the verifier scanning the wrong hint bucket, which fails closed but wastes the read.
2. Resolve peer_id → owner out of band. No wire change, but it needs a source of truth that does not exist yet, and a lookup on the read path is the cost the pointer was introduced to avoid.

Settle it before building (§1.10). Whichever is chosen, state what happens when the owner is wrong or absent — a scan against a wrong owner must be indistinguishable in outcome from no scan at all.

Two adjacent findings from the same lane, recorded so they are not rediscovered

• ProviderRecord::content_key is a hash, not the content id. A verifier can only obtain (store, root) from the id the caller asked about — so any future consumer holding only a record, with no caller context, cannot verify at all. That constrains where verification can ever live.
• A ContentId::Store-granularity claim is unverifiable by construction. A coin bonds (store, root, owner, epoch), so a store-wide claim names no generation. It is currently Unverified; whether that should be stated normatively is worth deciding.

Acceptance

A provider record with no unverified_mirror_coin_id whose publisher does hold a valid mirror coin is positively verified as Bonded — proven by a test with exactly that setup. Plus the control: a record whose publisher holds no coin stays Unverified or Unbonded, and a wrong owner yields no worse than the absent case.

Parent

Verification #466 · epic https://github.com/DIG-Network/dig_ecosystem/issues/3166

[MichaelTaylor3d]

Re-scoped: this is a BLOCKER for #466, not a follow-up

I filed this as a gap in the hint-scan fallback. The security gate on PR #467 found it is the root of something far worse: the missing peer_id → owner mapping is why verification cannot bind a coin to the peer claiming it at all.

Two HIGH findings, both flowing from it, and together they make the verifier net-negative — it can be used to promote a liar and to demote an honest node:

1. Bonded proves the coin exists, not that the claimant owns it. verdict_for (bond_verify.rs:85) never receives the claiming peer. An attacker reads an honest holder's coin id in cleartext from the DHT — dig-node already attaches real pointers on main (seams/dig_peer/dht.rs:494) — or simply enumerates every mirror coin via the single shared puzzle hash (dig-mirror-coin-0.7.0/src/asset.rs:29). It republishes that coin id as its own and is ranked first, at zero collateral. And since the verdict is now the primary sort key, this outranks connection-verified peers.

2. The coin id is unauthenticated hearsay about a third party. mirror_bond.rs:122-124 reads the pointer off any record and ranks the peer named in provider_peer_id by it. dig-dht-0.15.0/src/service.rs:682 states lookup-collected records are "attributed by NOBODY: an arbitrary peer" and carry no signature. One answered lookup suffices (stop_on_providers = true, lookup.rs:185): return a slate naming honest holder H with H's real addresses and a bogus coin id, and H verifies Unbonded and is ranked last on every read.

dig-dht's own justification for tolerating hearsay — "the merkle bind catches it" — covers addresses, which the content hash validates. It does not cover a field used to judge a third party.

What this changes about the shape

Neither option I originally listed is sufficient on its own, because both were aimed at finding the coin rather than binding it to the claimant:

• An owner field on ProviderRecord is still self-declared by the announcing peer, so it moves the lie rather than removing it — unless it is signed by the peer's identity key and the coin's owner is checked against that identity.
• Out-of-band peer_id → owner resolution needs an authority that does not exist.

The question to settle: what cryptographically binds a mirror coin's owner to a DHT peer id? Until that is answered, a verdict about a third party's bond cannot be trusted, and ranking on it hands an attacker both directions of the attack.

peer_id = SHA-256(TLS SPKI DER) and the operator wallet's owner puzzle hash are currently unrelated values. Making them relatable is the actual work.

Interim position

PR #467's verifier is correct in its four steps and its reorder-don't-refuse remedy — the gate endorsed both and proved step 4 by mutation. The defect is the input, not the remedy. It must not be wired to production ranking until a claim can be bound to a claimant.

[MichaelTaylor3d]

DECIDED — the coin declares the peer it collateralises, and ranking becomes CREDIT-ONLY

Two parts, and the second is what makes #467 shippable today without waiting on anything.

1. The binding channel already exists and is spend-authenticated

dig-mirror-coin writes memos as [hint(32), store(32), root(32), epoch, tail…] (create.rs:101-110) and decodes the tail as arbitrary UTF-8 strings (coin.rs:490-499 — "a memo is arbitrary bytes… URLs are advisory either way").

Only the owner key can produce that spend. So a term the coin declares is a statement by the coin's owner, verified by executed on-chain code — exactly the property this ticket says is missing, at no new authority, no new key, and no dig-dht wire change. The coin declares the peer_id it collateralises, as a dig-peer:<64-hex> term in the memo tail.

2. CREDIT-ONLY ranking — this is the part that kills both attacks immediately

verdict	effect
Bonded and the coin's memo declares the claiming peer_id	promoted
absent pointer · Unverified · Unbonded	one baseline tier, source order preserved

An unverified or disproven pointer can never rank a peer BELOW where no pointer would have put it.

• Attack 1 (liar republishes an honest holder's coin id) fails — H's coin names H, so the liar gets baseline, not first.
• Attack 2 (bogus coin id attributed to H) fails — Unbonded no longer sinks anyone. Hearsay can withhold credit; it can never subtract it.

Until dig-mirror-coin 0.8.0 ships and coins are recreated, Bonded is simply unreachable and the layer is inert-but-recorded — the interim position, arrived at by construction rather than by a flag.

Rejected

• Signed owner field on ProviderRecord — a dig-dht wire break plus a release-first cascade, grows every record, and still needs the coin-owner check to be worth anything. It buys a property the coin can assert for free.
• Deriving the owner puzzle hash from the peer key — touches key derivation and operator-wallet custody, and permanently couples two rotation lifetimes: a TLS cert re-mint would orphan every live coin.
• Challenge–response at dial — kept as a later strengthening, not the fix: it costs a round trip and cannot inform pre-dial ranking, which is the only place the verdict is used.
• Observability-only — safe, but strictly dominated. Credit-only is equally safe against both attacks and preserves the feature.

What an attacker can still do — stated plainly

• Steal the credit by announcing H's peer_id with its own addresses. The coin binds coin↔peer_id, not record↔address, and the DHT record's peer_id↔address association remains unauthenticated hearsay. The attacker ranks first, then fails the mTLS handshake — it cannot present a cert hashing to H's SPKI. Cost: a wasted dial.
• Buy rank honestly. A well-collateralised attacker with its own coin and peer id ranks first legitimately. That is the design; the defence is the collateral price.
• Withhold credit from H by republishing it with no pointer, or by out-racing its record. Under credit-only that is baseline at worst — the pre-feat(mirror): verify a peer's mirror-coin bond against chain on the download path #467 status quo — never below it.
• Pre-0.8.0 coins are permanently unbondable. Honest holders sit at baseline until they recreate at the next epoch. A degradation, not a lie.

Open, and it changes only the residual statement — not the plan

Whether an outbound dial pins the expected peer_id. If it does not, the credit-stealing attack upgrades from "a wasted dial" to "traffic redirected to an attacker holding a stranger's rank".

I looked. peer.rs:4758's test comment asserts that a mismatched listener means "every dial to this node fails closed with peer_id mismatch: expected <advertised>, got <gossip-cert>", which implies the dialer checks. But that is a claim in a doc comment, not verified source — dig-gossip is a git dependency and is not in the local registry, so I could not read its dial path. Treat this as unverified, and settle it in dig-gossip before relying on the residual-risk statement above.