fix(payment): verify single-node issuer closeness against over-query window

[jacderida]

Problem

After #140 removed the reachability re-rank from the closeness-verification checks, most uploads recovered — but on a 30%-NAT testnet, uploads paid via the single-node (legacy) median path still fail a few percent per chunk (multiplicatively per file), while uploads paid via the merkle batch path succeed cleanly.

Observed on a staging testnet: a 1000 MB upload (merkle-dominated) had zero closeness rejections, while 20 MB uploads (single-node) failed ~60% of the time, entirely on:

Paid quote issuer <peer> is not among this node's local 7 closest peers for <chunk>

Cause

The two payment paths verify issuer/candidate closeness very differently:

	Single-node path	Merkle batch path
Lookup source	node's local routing table	authoritative find_closest_nodes_network
Window width	close_group_size (7)	2 * CANDIDATES_PER_POOL (32)
Match rule	exact membership of one issuer	9-of-16 majority

The uploader selects single-node quotes by querying 2 * CLOSE_GROUP_SIZE peers and keeping the CLOSE_GROUP_SIZE closest successful responders (ant-client get_store_quotes). When closer peers are slow or NAT-stuck, the honestly-paid issuer legitimately lands at positions 8–14 by XOR distance. Verifying against only the node's local top-7 with exact membership rejects those honest payments — the same divergence the merkle path was already hardened against (its code comment: such peers appear at "positions 17–32 … when the closer peers are slow or NAT-stuck. The storer must look at the same window or it will reject honest pools with no security benefit").

Fix

Bring the single-node issuer check in line with the merkle path:

• Widen to 2 * close_group_size, mirroring the uploader's over-query window.
• Keep XOR-only ordering (find_closest_nodes_local_with_self reranks by reachability and would demote the XOR-close relay-only / NAT'd peers the uploader legitimately quoted — the fix(payment): use XOR-only local lookup for close-group verification #140 fix).
• Hybrid source: check the cheap local routing-table view first; only on a local miss fall back to an authoritative find_closest_nodes_network lookup (the same view the uploader used to pick the quotes), wrapped in the existing CLOSENESS_LOOKUP_TIMEOUT. Reject only if the issuer is in neither view.

Note on cost

The fallback can issue a per-chunk network lookup on the single-node path when the local view misses. The local fast-path keeps that off the hot path for issuers we already know. The merkle path amortizes its network lookups with a single-flight + pass-cache keyed by pool hash; this change does not add caching (each chunk is a distinct address, so it is less reusable), but that is an option if lookup load proves high in practice.

Builds on #140.

🤖 Generated with Claude Code

[dirvine]

Hermes review

Thanks — I reviewed the diff and ran focused local checks.

Verdict: changes requested before merge, primarily because formatting is currently red.

Blocking

• cargo fmt --all -- --check fails on src/payment/verifier.rs around the new match tokio::time::timeout(...) block. This matches the failing GitHub Format Check job. Running cargo fmt should fix it.

Logic review

The hotfix direction looks broadly sound:

• the single-node paid issuer check remains after content-address and peer/pubkey binding;
• receiver/storage admission is still checked before payment verification in storage/handler.rs;
• the check keeps XOR-only ordering, avoiding the reachability re-rank issue fixed in fix(payment): use XOR-only local lookup for close-group verification #140;
• the network fallback mirrors the Merkle-path authoritative-view rationale, while keeping a local fast path.

Documentation / invariant clarity

One thing I would tighten before merge: nearby comments still describe this as checking the issuer against the configured close group, but this PR deliberately widens single-node issuer locality to 2 * close_group_size.

Suggested places to update:

• src/payment/verifier.rs: PaymentVerifierConfig.close_group_size comment
• src/payment/verifier.rs: VerificationContext comment around the paid-issuer locality invariant

It would be clearer to state that the legacy/single-node issuer check uses the uploader over-query window, not strict close-group width. Given this is an economic/security boundary, a small regression test or explicit comment explaining why issuer width can be wider than local storage-admission width would also help future reviewers avoid accidentally re-tightening or over-widening the wrong side of the invariant.

Local checks run

• cargo fmt --all -- --check → failed on formatting
• cargo test test_legacy_paid_median_issuer_close_group_rejection --lib --no-fail-fast → passed
• cargo test payment::verifier::tests --lib --no-fail-fast → passed, 74 tests

CI at review time: format failing; docs/clippy/security audit and several build/test jobs passing; some OS matrix jobs still pending.