discussion(kad-dht): monotonic sequence numbers for silent-withholding detection in GET_VALUE

Problem

A GET_VALUE eclipse doesn't require the adversarial closest-set to answer incorrectly — they can simply answer "no record," which is indistinguishable to the resolver from a key that was never published. Silent withholding is currently undetectable at the application layer.

This is distinct from routing-layer hardening (#1383, #1384): even with subnet diversity and disjoint paths in place, an attacker who legitimately occupies the closest-K set for a key can still withhold silently.

Proposal

If the publisher signs a monotonic sequence number into the record, and resolvers retain the highest sequence number seen per key across lookups, then silent withholding degrades from "invisible" to "serving a stale-but-valid record" — which a client can at least flag as suspicious or trigger a re-lookup.

go-libp2p's record.Validator already carries a Select method for exactly this purpose; the IPNS validator uses it to prefer higher sequence numbers. py-libp2p has libp2p/records/ipns.py and libp2p/records/validator.py which are the analogous entry points.

Rough scope

• Extend Record (or a wrapper) to carry a seq: uint64 field
• Publisher increments and signs seq on each PUT_VALUE
• Resolver tracks max_seq_seen[key] in the value store; after a GET_VALUE that returns "not found," if max_seq_seen[key] is set, surface a "possible withholding" signal rather than a clean miss
• IPNSValidator.Select already implements higher-sequence-wins preference — the DHT value store could adopt the same pattern

Why this is a discussion issue

This touches the record format (proto-level change) and implies clients need to persist max_seq_seen across sessions to be useful. It needs:

1. Confirmation that the Record proto can be extended without breaking go-libp2p interop
2. A decision on where sequence numbers live — inside the existing Record.value payload (IPNS already has them), or as a DHT-level wrapper
3. Whether this is purely advisory (log a warning) or load-bearing (affect quorum logic in libp2p/kad_dht/kad_dht.py)

This is deliberately filed as a discussion before any implementation. Happy to draft a spec sketch if maintainers think the direction is worth pursuing.

Related

• #1383 — subnet diversity in k-buckets (routing-layer hardening)
• #1384 — disjoint lookup paths (path-steering hardening)
• #57 — original eclipse attack discussion

/cc @acul71 @sumanjeet0012 @asmit27rai

Start with libp2p/records/ipns.py and libp2p/records/validator.py, then inspect libp2p/kad_dht/kad_dht.py and the Record definition. Resolve whether sequence numbers belong in the existing value payload or a DHT-level wrapper, and whether withholding detection is advisory or affects quorum logic. Done means maintainers have an agreed design covering proto compatibility and persistence across sessions.