chore(release): v0.256.0 -- reward distributor prover, peer claim loop, prover-status RPC - #602
Merged
Conversation
* chore: open lane for #574 * feat(mirror): persist mirror-bond coin ids so a restart cannot double-create Bond identity was reconstructed from a live chain scan on every read (`mirror/observe.rs`), with no persistence of its own. A restart, a cold replica, or a lagging/flaky chain source all rendered a real, unspent, confirmed bond as "no bonds" -- and because the in-flight suppression is keyed on pending/submitted audit entries, a bond whose create had already CONFIRMED was not suppressed either, so the same short scan that emptied the read surface also cleared the one thing that would have stopped a second coin being paid for collateral that already exists (dig-node#574). Persist the (store, root, epoch) -> coin_id mapping in the EXISTING spend audit record (spend-audit.jsonl) rather than a new store: a mirror-coin create already writes store_id + AuditedBond{root, epoch} + amount there, and the coin id itself becomes durable the moment resolve_landed_spends confirms it. This adds the one missing piece -- the advertised URL a create carries -- and a read-side query, confirmed_mirror_bond, that returns the newest CONFIRMED record naming a triple. Chain stays authoritative. mirror::local_bond::recheck_missing_bonds never trusts the record: for a held bond the live scan did not cover, it asks the record for a candidate coin id, then re-verifies that SPECIFIC coin against chain via the same independent check (chain_bond_verdict) that verifies an untrusted peer's claimed bond. Only a fresh `Bonded` verdict is folded back in, as covered; `Unbonded`/`Unverified` fall through to an ordinary create, exactly as if no record existed. Version: 0.254.86 (patch -- per #522 the MSI ProductVersion minor field is exhausted and the counter lives in patch). Co-Authored-By: Claude <noreply@anthropic.com> * test(mirror): prove the recovery wiring end to end through PassRunner::run Adds two integration-level tests over the REAL pass pipeline, not just the isolated recheck_missing_bonds unit tests: a bond missing from the live scan with a chain-reverified durable record is recovered (no double create, correct Bonded state reported), and the control -- the same record but chain disproves it -- correctly falls through to an ordinary create. Together these are the concrete regression test for the cold-start/lagging-chain-source double-create scenario the ticket asked to have measured. Also refactors in_flight_creates to take the already-folded SpendLedger instead of re-reading the log itself, so PassRunner::run reads the audit file once per pass and shares it with the new recovery step, and fixes a doc comment on in_flight_creates that the recovery step would otherwise have made stale on landing ("a Confirmed create has a coin the chain observation already sees" is no longer unconditionally true). Co-Authored-By: Claude <noreply@anthropic.com> * chore(fmt): wrap long test signatures to satisfy rustfmt Co-Authored-By: Claude <noreply@anthropic.com> * chore(clippy): use slice::from_ref instead of cloning for a single-element slice Co-Authored-By: Claude <noreply@anthropic.com> * chore(release): bump to v0.254.89 Base branch moved to develop after PR #576 merged there at v0.254.88 (main and develop are currently identical), leaving this branch's carried-forward .88 as a zero-increment against the new base. Bumped to the next free integer after fetching and verifying both origin/main and origin/develop tip at .88. Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>
serve_accepted_relay_conn served every accepted relayed circuit (full mTLS auth, full L7 peer RPC) while registering it nowhere, so connected_peers under-reported every relayed inbound peer -- the relay-leg twin of the direct-inbound defect #402/#523 already fixed. adopt_inbound_peer_in_pool now dispatches by TraversalKind: Relayed routes to dig-gossip's already-published adopt_relayed_inbound_handle (v0.32.0, the rev this repo already pins), every other tier keeps the unchanged adopt_direct_inbound_handle path. serve_accepted_relay_conn adopts before serving and releases after, mirroring the direct listener exactly. Refs: DIG-Network/dig_ecosystem#3124
…isions (#582) * chore: open lane for #3189 * fix(cli): guard the exit-code namespace shared with diga against collisions dign and diga deliberately share one process exit-code numbering (dig-app's outcome.rs says so in its own doc comment), so a number is free only if it is unoccupied ecosystem-wide. dig-node#407 assigned exit 7 to NODE_UNREACHABLE by checking only this repo's own table, where 7 genuinely was free -- and collided with diga's NOT_CONNECTED. A reviewer caught it by hand; nothing failed automatically. Adds scripts/check-exit-code-collisions.sh: parses both enums' code()/name() match arms straight from their own source -- this repo's ExitCode, and a live fetch of dig-app's outcome.rs at its default branch -- and fails if a number carries two different names, or if either side draws a number from the reserved shell signal range (126, 127, 128+N). Ships with an 18-case hermetic test harness (scripts/tests/check-exit-code-collisions.test.sh) covering the actual #407 collision shape, arm-order independence, arm-count mismatch, the reserved-range boundary from both sides, the live-fetch path itself, and fail-closed behaviour on an empty/missing/unreachable table. Wires a real (unstubbed) invocation into ci.yml's existing "Release-script tests" job so a collision introduced by a future PR, on either side, is a red required check on that PR -- not a note a reviewer has to catch. The fetch retries twice (2s backoff) since this becomes a required, network- dependent check; a fetch failure still fails closed after retrying, never silently passing as "diga has no codes". Updates SPEC.md 8.4 to point at the mechanical guard instead of leaving "re-check both tables" as unenforced prose, and records that the extension's WALLET_WS_ERR.NOT_CONNECTED = -33001 is a separate JSON-RPC error-code space, not a rival of this one. Adds a doc-comment to the existing transcribed collision test pointing future readers at the live script as the authoritative check; the transcription remains as a narrower, hermetic regression pin for the #407 shape specifically. No renumbering: every currently-assigned code is unchanged. Refs #3189 Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>
…rrupted strings (#3190) (#583) * chore: open lane for #3190 * fix(hygiene): port the lost-continuation guard to 4 crates, fix 48 corrupted strings Replicates dig-node-service::continuation_guard (dig-node#526/#501) into dig-node-core, dig-wallet, dig-runtime and dig-chat-protocol, line-for-line apart from crate-specific constants -- ported rather than reinvented, per dig_ecosystem#3190. Wiring the guard in surfaced 48 pre-existing lost-continuation defects the ticket's own "no measured corruption in these four crates" note did not anticipate: 36 in dig-node-core, 12 in dig-wallet, mostly test-assertion prose where a multi-line message lost its `\` continuation and shipped the source's own indentation as a mid-sentence space run (one as the worse `\n`-plus-indentation variant). All 48 are collapsed to the single space the sentence always meant, with surrounding indentation and wording otherwise untouched. Two lines are real column-alignment, not defects, and get a targeted EXCLUDED_LINE_RANGES entry on dig-node-core instead of a rewrite: download.rs's `claimed(...)` fixture-table trailing comments, and net.rs's `label : value` debug-print alignment. Refs DIG-Network/dig_ecosystem#3190 Refs DIG-Network/dig_ecosystem#3130 Co-Authored-By: Claude <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com>
… the current advertise URL Automatic half (D1-D4) of the daily mirror-URL reconcile: derived personal-day offset, two-observation hysteresis, nine ordered gates with K sized as a self-funding prefix before any reclaim, `submitted` never `completed`, audit lines gain `reclaim_reason` + `trigger`. Gates at b4c0986: loop-reviewer PASS (review 5129272285), loop-security PASS @ 175304e (tree byte-identical, `git diff 175304e b4c0986` empty), adversarial loop-decider PASS (comment 5567083644; SHOULD-FIX findings ticketed separately). Refs #570 Refs DIG-Network/dig_ecosystem#3203
…tem#3212) Nine commits from the #3212 serve-path lane, gated at 899cc68 (reviewer review 5130425808, security comment 5568662836), plus the single semver bump to 0.255.0 for the develop -> main batch. - store_id/root case normalised at the CapsuleKey boundary; cache delete targets the matched entry - tier-0 occupancy reads the eviction-aware ledger - profile-sync outbound budget in bytes; announcer asked first - melt confirmation depth on the terminal spend, fail-closed - EngineWarming (-32002) while the peer tier attaches, never -32004 - window completeness derived from the bytes read - deps: dig-stun 0.2, chia-query 0.24.3, dig-nat 0.21.2, dig-logging 0.2.2 Refs DIG-Network/dig_ecosystem#3212
… squash Content-neutral. main@5eac531a is the squash of develop@194a0163 (tree-identical, verified with `git diff --quiet 194a016 origin/main`), so develop already carries every byte main has; this merge only records the ancestry so PR #588 (develop -> main) stops reading as CONFLICTING and GitHub can build its merge ref again (the Commitlint and Check Version Increment pull_request-event checks never attached to e11434a for that reason). Refs DIG-Network/dig_ecosystem#3212
…ash + changelog) Content-neutral: develop already carried every byte of the #588 squash; this brings in the chore(release): v0.255.0 changelog commit so develop == main in content for the next batch. develop is branch-protected against force-push and deletion, so it is synced by merge, not recreated from main. Refs DIG-Network/dig_ecosystem#3212
* chore: untrack gitnexus-generated agent files These files were generated by `gitnexus analyze` as a side effect of indexing this repository. They are development-loop private tooling output, not product code, and carry no secrets. They are removed from tracking going forward via .gitignore; history is deliberately NOT rewritten. Refs #3177 * chore: drop private-repo reference from gitignore comment The ignore comment named a private repository and an internal issue number in a public file, which is the same disclosure class this change set exists to remove; the reference is dropped and the guidance kept.
…enforced self-exclusion, bounded spend (#593) The always-on reward-prover engine: ~2,000 lines under `crates/dig-node-core/src/rewards/`, built against the merged `dig-rewards-coin` SPEC. Library only -- nothing spawns it, and the sole production `RewardsChainPort` refuses every call, so it cannot spend. Wiring the composed system is #3265, which carries its own gate. The epic's premise -- "anytime the process isn't running, rewards are not being distributed" -- is half wrong, and the false half is the dangerous one. `Sync`, `NewEpoch` and `InitiatePayout` need no manager authority, so funder downtime does not stop rewards: it FREEZES THE ENTRY SET while accrual and payouts continue. Peers that stopped mirroring keep earning; peers that started cannot begin. That shaped the whole design. Liveness honesty (SPEC 2.4). The status record carries no `healthy`/`ok`/`up` boolean and no precomputed staleness, because a wedged loop cannot report its own wedging -- whatever it last wrote stays there, so a writer-set flag reads true forever after the failure it exists to reveal. The reader derives staleness from `last_cycle_completed_at` against `observed_at` and its own clock. A recursive JSON-key test enforces the absence at every nesting depth; asserting on keys and never substrings, since `ProverState::Running` legitimately serializes the VALUE "running". The one legal staleness signal is chain-derived (SPEC 12.4: 48 hours AND a non-zero reserve, from the singleton's own spend history) and lives on the distributor read, where a wedged prover cannot fake it. Self-exclusion is a compile error, not a habit. dig-node#261's lesson is that an invariant enforced on some paths is not an invariant. `admit` is the single admission point, checks both SPEC 5.2 coordinates (own peer_id OR a payout puzzle hash this wallet controls), and mints an `AdmittedPeer` with private fields and no public constructor -- so `EntryAction::Add` cannot be built by a path that skipped admission. A prover's own fault can never strike a peer. `GateError` is a distinct type from `GateIneligibleReason` and `record_prover_fault` takes `&self`, so SPEC 3.6 clause 4 is enforced by the borrow checker rather than by comment. Without that, a misconfigured operator -- one missing mirror-collateral epoch ordinal -- would strike every peer at once and evict its entire 250-entry set in three hours, each eviction a fee it pays plus a settlement out of its own reserve. The money bounds are stated where a human reads them (`rewards/mod.rs`): 24 bundles/day, 192 entry actions/day, a fee ceiling of 24x the configured standard fee, 192 removals/day worst case with 96/day sustained churn. Recorded honestly: SPEC 6.3's rate bound and fee ceiling are ONE control, not two. Three gate rounds, every leg fresh-context. Round 3 at this head: reviewer PASS, adversarial decider RATIFY (leg closed), security CHANGES-REQUIRED on a finding the decider ratified deliberately -- adjudicated in #593 (comment) and carried to #3265 with the remedy corrected, because the proposed fix would have persisted a poison flag to the very store whose writes were failing. Found and fixed under gate: a census ordinal off by one in both directions (SPEC 4.6 requires n-1 exactly); an unreachable grace window leaving a named constant with no reader; a missing `NewEpoch` spend; an absent-ordinal path attributing a prover fault to peers; and a daily fee ceiling 24x too high because a per-bundle fee was consumed as a daily ceiling. Refs DIG-Network/dig_ecosystem#3250 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* chore: open lane for #3269
Bump dig-rpc-protocol to 0.11.0 (adds dig.getRewardProverStatus and
the other reward RPC methods to the wire).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* test(rewards): fail-closed Reward-tier guard + dig-rpc-protocol 0.11 line assertion
- dependency_tree.rs: assert the resolved dig-rpc-protocol line is 0.11 (was 0.10);
documents the known-red two-version state pending the dig-peer 0.14.0 /
dig-download 0.23.0 cascade (#3269).
- reward_methods_tier_guard.rs: fail-closed guard over the live Method::ALL
catalogue -- every Reward-named method must be Tier::Control and not
peer-reachable, so a fifth reward method added later is caught at the wrong
tier automatically rather than inheriting a wrong default (binds #3261's rule
node-side).
- peer.rs: sibling unit test exercising the real (pub(crate)) is_peer_reachable_method,
since an external integration test cannot see it -- same guard, executed against
this node's own allowlist rather than only the shared crate's.
Refs #3269
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* style: remove trailing blank line in reward_methods_tier_guard.rs
* feat(rpc): serve dig.getRewardProverStatus at Tier::Control
Adds the missing handler for PR#595: a new reward_prover_statuses
registry + accessors on Node (empty until #3265 spawns a prover loop,
so the registry read is real, not a stub), a dispatch.rs arm inside
the Method enum match (never the string pre-match), and a
field-for-field mapping from dig-node-core's internal
rewards::state::RewardProverStatus (camelCase-tagged) onto
dig-rpc-protocol 0.11's wire RewardProverStatus (snake_case-tagged
struct, camelCase-tagged ProverState value), widening entry_count
u32 -> u64 explicitly and hex-encoding the three [u8; 32] identity
fields.
An all-zero launcher_id (what an uninitialised registry slot
hex-encodes to) is omitted at this boundary rather than rendered as
a real distributor with a plausible-looking id -- the money-hole
class the dig-rewards-coin driver's adversarial gates found three
times.
Tests (in dig-node-core::lib.rs's existing test module, where the
pub(crate) registry accessors are visible) drive the real dispatch
entry point (handle_rpc -> RpcDispatch::dispatch -> the Method arm)
and assert field-for-field on the serialized JSON body: populated
registry, empty registry (-> {"statuses": []}), zero-id omission,
tier/peer-reachability, enum-match-not-string-prematch, and
launcher_id filtering. The no-health-boolean / no-staleness
assertion is by key set, not substring.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* style: rustfmt the reward-prover-status registry + tests
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* chore(deps): bump dig-download 0.23, dig-peer 0.14, dig-rpc-protocol 0.11
Closes the two-versions-of-dig-rpc-protocol split (#3269): dig-download 0.23.0
and dig-peer 0.14.0 both now resolve dig-rpc-protocol ^0.11, matching
dig-node-core's own dig-rpc-protocol = "0.11.0" line, and dig-node-service's
two 0.10 lines (main dep + dev-dependency restatement for
openrpc_drift_guard.rs) move to 0.11 to match.
Manifests only. cargo update / Cargo.lock intentionally NOT run yet: a fourth
capper, dig-peer-selector ("0.11" in dig-node-core/Cargo.toml), still requires
dig-peer = "^0.13" in every published version through 0.11.1, so the tree
cannot fully resolve until a dig-peer-selector release picks up dig-peer 0.14.
CI will stay red on this commit for that reason, which is expected.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* feat(rpc): close dig-rpc-protocol 0.11 cascade + attribute payout figures
Bump dig-peer-selector 0.11 -> 0.12 (the release that moves onto dig-peer
^0.14) and run cargo update, closing the two-versions-of-dig-rpc-protocol
split: Cargo.lock now resolves exactly one dig-rpc-protocol, at 0.11.0,
alongside dig-peer 0.14.0, dig-download 0.23.0, dig-peer-selector 0.12.0.
Add a subject-attribution test and doc comments to
reward_prover_status_to_wire: total_paid_out_base_units and
reserve_base_units are per-distributor totals (this distributor's payout to
ALL its mirrors, and this distributor's own reserve), never the querying
node's own earnings and never summed/cross-attributed across distributors.
This is the defect class a sibling adversarial gate found in dig-app#403's
rewards pane, which rendered a distributor total as one mirror operator's
personal earnings and overstated by up to 250x.
Checked: rewards/state.rs, rewards/port.rs and rewards/mod.rs contain no
Eligible/verdict/payout_hash symbol, so nothing in this mapping surfaces a
persisted EligiblePayoutHash verdict.
Refs #3269
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rpc): silence dead_code on register_reward_prover_status pending #3265
Clippy's non-test lib target has no production caller for
register_reward_prover_status yet, because #3265 (the always-on prover loop
that would call it from bring-up) has not landed -- only tests call it today.
cfg_attr(not(test), allow(dead_code)) stands in for that missing caller
until #3265 wires a real one.
Refs #3269
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rpc): make the all-zero identity guard non-silent and cover all three fields
Security (blocking) and the adversarial leg both found the same defect in the
zero-launcher_id filter: it checked only launcher_id, so a registration bug
that zeroed store_id or root beside a valid launcher_id would pass through as
a plausible record, and dropping the bad record silently destroyed the
evidence a registration bug happened at all -- SPEC Sec2.4 clause 1's exact
prohibition.
zeroed_identity_fields() now checks launcher_id, store_id AND root. The
dispatch filter still excludes a record with any zeroed field (never renders
an uninitialised slot as a real distributor), but first fires a
tracing::warn! naming which field(s) were zero, so a bad registration is
observable rather than swallowed. Kept isolated in dispatch.rs rather than
woven into the wire mapping, since this belongs at #3265's writer once that
lands.
Replaced get_reward_prover_status_omits_an_all_zero_launcher_id (which
proved the omission but not the observability, and never exercised a zeroed
store_id/root beside a valid launcher_id) with
get_reward_prover_status_logs_and_excludes_a_zeroed_identity_field, covering
both a zeroed launcher_id and a zeroed store_id beside a valid launcher_id,
and asserting the tracing::warn! output via the crate's existing
capture_sync_logs test utility.
Fixed a now-false "Known-red" doc comment on
tests/dependency_tree.rs::the_workspace_carries_exactly_one_module_wire_crate:
the dig-peer 0.14.0 / dig-download 0.23.0 / dig-peer-selector 0.12.0 cascade
already landed in this PR's Cargo.toml/Cargo.lock, so the assertion is green,
not red. Assertion itself untouched -- still exact-version.
Refs #3269
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rpc): correct a born-false "shipped dig-app 15.5.0" doc claim
dig-app's latest release is v15.4.0 -- there is no v15.5.0 tag -- and
dig-app#403 (the pane that would consume dig.getRewardProverStatus) is OPEN
and unmerged. Point the doc comment at the real, unmerged consumer instead
so a future reader doesn't take this as evidence a shipped consumer depends
on the guard, which would wrongly discourage relocating it to #3265's writer.
Refs #3269
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rpc): correct doc placement, assert the zeroed field by name, treat root as an observation
Three findings from the correctness gate on PR#595 at 134864a.
1. The zeroed-identity helper's doc block was spliced onto the end of
reward_prover_status_to_wire's block with no separator, so the wire-mapping
rationale documented a boolean predicate and the mapping function was left
with no doc at all. Each doc block now sits above the item it describes.
2. The log assertion `logs.contains("launcher_id")` was a tautology: the warn
emits launcher_id as a structured field on every fire, so the property the
guard exists to add -- naming which field was zeroed -- was unasserted.
Deleting `zeroed_fields = ?zeroed` from the warn left every assertion green.
The test now asserts the zeroed_fields value itself, which the fixture makes
exact and disjoint across cases.
3. `root` is an observation, not an identity. A registered prover that has not
completed its first cycle plausibly has no root, and a writer that zero-inits
it would have made a healthy prover invisible. A zeroed launcher_id or
store_id still excludes the record; a zeroed root alone warns and returns.
Refs #3269
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(rpc): restore zeroed_fields structured field dropped from the pushed warn
The previous commit (080be3d) landed with `zeroed_fields = ?zeroed` missing
from the tracing::warn! call in the GetRewardProverStatus filter -- a
one-line regression introduced while proving the new log assertion goes red
without it, never restored before the commit was made. Without this field
the log line never names WHICH field was zero, so an operator sees only
that something was excluded, and the test asserting `zeroed_fields=[...]`
per case would fail. Restored; all 7 reward-prover-status tests green.
Refs #3269
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rpc): split zeroed-field logging by level -- WARN for a missing
identity, DEBUG for a zeroed root
A zeroed launcher_id or store_id is a real registration bug: the record is
excluded and now logs at WARN, naming the exact field(s) via
`zeroed_fields=[...]`. A zeroed root alone is an ordinary pre-first-cycle
state, not a fault: the record is still returned, and now logs at DEBUG
instead of WARN, so an operator polling this endpoint sees warn-level
volume proportional to real registration bugs, not to every
not-yet-cycled prover on every poll.
Updated the doc comments on `zeroed_fields`, the dispatch filter and the
test to describe the level split, and extended the regression test to
assert on level (WARN vs DEBUG) as well as the `zeroed_fields` value.
Proved both directions: flipping the DEBUG branch back to WARN turns the
test red on the level assertion; flipping the field-name assertion back to
a bare `contains("launcher_id")` would have passed unconditionally (the
prior tautology) and is no longer possible since the assertions now pin
`zeroed_fields=[...]` plus the level string.
Refs #3269
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
…adence (#3251) (#594) * feat(rewards): peer claim loop skeleton -- discovery, cadence, config, claim port * test(rewards): write all twelve acceptance tests for the peer claim loop * feat(rewards): wire the seven rewards_claim submodules into the crate mod.rs declared no submodules, so types.rs/port.rs/config.rs/cadence.rs/ parser.rs/engine.rs/hints.rs (1,435 lines, 25 tests) were never part of the crate and never compiled. Declare them and re-export the public surface. * style(rewards): cargo fmt the rewards_claim submodules * chore(deps): bump dig-node-control-interface 0.33->0.35, dig-rpc-protocol 0.10->0.11.0 dig-rpc-protocol 0.11.0 is merged and tagged upstream; the other dig-*/chia-* deps of dig-node-service were already at the latest permitted-by-caret version in Cargo.lock. crates/dig-node-core/Cargo.toml is untouched (#3250's file set). * chore(deps): revert dig-node-control-interface and dig-rpc-protocol bumps Both create a duplicate-version split in this PR's scope and neither can be closed without editing a sibling crate's manifest this lane does not own: - dig-rpc-protocol 0.11.0 duplicates against dig-node-core/Cargo.toml:194 ("0.10.2"), which is #3250's live file set (dig-node#593). - dig-node-control-interface 0.35.0 duplicates against dig-wallet/Cargo.toml:81 ("0.33"), a sibling crate this lane does not own; the observed Clippy break (BalanceAsset/Asset type-identity mismatch, missing url_reconcile/url_current/urls fields) came from THIS duplicate, not from dig-rpc-protocol. Both belong to their own sequenced dep-bump unit of work, not this ticket. * fix(rewards-claim): fault laundering, permanent no-entry blacklist, fee ceiling magnitude Three independent gates on dig-node#594 (51516e6) found four logic defects; this addresses A, B and C per the corrected fix brief (D is documented only, not fixed here per the brief's own instruction). Defect A -- the anti-silence surface laundered every real fault into `Nominal`: - A1: `fault_reported` had no fault-bearing ClaimLoopState to fall through to, so a chain adapter erroring every cycle read `Nominal` forever. Added `ClaimLoopState::Faulted { cycles }`, outranking Nominal/ClaimableButNotClaiming, under ChainSourceUnavailable. - A2: inverted the test that asserted A1's bug as correct behaviour. - A3: `ClaimableButNotClaiming` compared a per-cycle snapshot (`distributors_claimable`) against a lifetime-cumulative counter (`claims_submitted`), so it latched healthy forever after one lifetime success. Added `claims_submitted_this_cycle` (per-cycle) as the correct comparand; kept `claims_submitted` as a cumulative counter. - A4: `last_discovery_at`/`last_cycle_at` were stamped even on a failed discovery or an all-faulted cycle, destroying the staleness signal a reader depends on. Now only stamped on success; added `last_attempt_at` to prove liveness separately. `fault_reported` and `distributors_faulted` now reset per cycle instead of latching for the process's lifetime. Defect B -- "terminal, stop retrying" was implemented as a process-lifetime blacklist (`terminal_no_entry: HashSet<Bytes32>`, never cleared). That blocked SPEC 12.5 clause 2's re-entry path (evicted, re-challenged, re-admitted never claims again) and permanently punished a peer that discovered a distributor before the funder's AddEntry landed. Removed the blacklist entirely -- `own_entry` is a cheap chain read, re-issued every cycle for every candidate, matching clause 3's "never cache across cycles". `NoEntrySlot` is now a per-cycle observation, not a lifetime sentence. Defect C -- the fee ceiling didn't bind anything and there was no aggregate cap: - C1: default `CLAIM_FEE_CEILING_MOJOS_DEFAULT` lowered from 1_000_000_000 (transplanted from `MIRROR_SPEND_FEE_CEILING_MOJOS`, sized for a mirror-coin spend) to 200_000 -- 2x the observed routine Chia fee range (5,000-100,000 mojos), so it actually binds instead of leaving 4-5 orders of magnitude of slack. - C2: added a per-cycle aggregate fee budget (`max_cycle_fee_budget_mojos`, default 10x the per-claim ceiling) checked across all claims in a cycle, closing the attacker-cost gap where funding K distributors could force a victim to spend K x the per-claim ceiling per cycle. New `ClaimOutcome::SkippedCycleBudgetExhausted`. Tests: rewards_claim test count 26 -> 37 (11 new: repeated_discovery_faults_never_ read_as_nominal, failed_discovery_leaves_last_discovery_at_unchanged, a_reported_ fault_surfaces_as_faulted_not_nominal, a_lifetime_submission_does_not_mask_a_ later_cycle_that_submits_nothing, no_entry_slot_then_re_admitted_produces_a_claim_ on_the_later_cycle, distributors_each_under_ceiling_do_not_collectively_exceed_ the_cycle_budget, the_default_per_claim_ceiling_actually_binds_a_routine_fee, plus renamed/rewritten no_entry_slot_is_non_terminal_and_re_checked_every_cycle). Refs #3251 * fix(rewards-claim): refuse a claim entry for the wrong payout puzzle hash CI fix: cadence.rs's RewardsClaimConfig literal was missing the max_cycle_fee_budget_mojos field added in the previous commit (E0063, caught by CI's Clippy/Test jobs -- the local cargo check for this workspace is too slow to use as the compiler here). Defect E (security-gate finding, folded in before this pass closes): submit_initiate_payout was called with entry.payout_puzzle_hash -- whatever the chain port handed back -- with no check against this node's own own_payout_puzzle_hash. UnavailableClaimChainPort is the only production adapter today so nothing can exploit this yet, but the whole point of the ClaimChainPort seam is that #3249 swaps in a real adapter with nothing above it changing, so deferring this would ship the landmine live with no review pass watching for it. Added an equality guard before the spend: a mismatch refuses to submit, counts (ClaimStatus::claims_refused_payout_mismatch), surfaces its own named outcome (ClaimOutcome::PayoutPuzzleHashMismatch), and is reported as a fault (a divergent entry means the port is confused or hostile, not that there is nothing to claim) -- never corrected by substituting our own hash and proceeding. Defect D: documented, not wired, per instruction -- added the "not yet wired into node startup" paragraph to mod.rs's module doc (the PR body carries the same paragraph) so the next reader arrives at the caveat in the code, not only in a merged PR description. Refs #3251 * fix(rewards-claim): B1 -- ClaimableButNotClaiming is a magnitude comparison, not a zero-test submitted_this_cycle < claimable_this_cycle now fires the anti-silence state, carrying the shortfall as ClaimableButNotClaiming { claimable, submitted }. The previous submitted_this_cycle == 0 zero-test let one submission mask any number of same-cycle skips (claimable=10, submitted=1 read Nominal). Also folds in B3's precedence fix (ChainSourceUnavailable > Faulted > ClaimableButNotClaiming > Idle > Nominal) and the per-distributor payout_hash_mismatches_this_cycle counter so a per-distributor fault can no longer pin the cycle-wide Faulted state, plus R2's rename of terminal_no_entry_slot to no_entry_slot_this_cycle now that it is no longer terminal. * fix(rewards-claim): B2/B3 -- value-ordered budget with rotation, per-distributor fault isolation B2: run_cycle now splits into a pre-budget phase (asset/entry/hash/threshold checks, producing the claimable set) and a budget phase, ordering the claimable set by accrued value descending before applying the fee ceiling and cycle budget. Dust distributors (low accrued value regardless of attacker-controlled fee) now sort last and are the ones the budget drops, closing the claim-suppression attack where ten high-fee dust distributors could consume the whole cycle budget ahead of a victim's real earnings. A rotation_cursor tie-breaks only WITHIN equal-accrued-value tiers so a genuinely tied honest tail that exceeds one cycle's budget every cycle still rotates through and is eventually served, rather than dropping the same tail forever. B3: the payout-hash mismatch check in evaluate_pre_budget now increments the per-distributor payout_hash_mismatches_this_cycle counter instead of setting fault_reported, so one hostile or buggy entry can no longer pin the cycle-wide Faulted state and bury ClaimableButNotClaiming for every other healthy distributor. R2: terminal_no_entry_slot -> no_entry_slot_this_cycle throughout. * fix(rewards-claim): R5 -- document not-yet-wired loop; persist B2 rotation cursor An operator reading their own rewards-claim.json and seeing enabled: true has no way to know from that file alone that no startup path constructs a ClaimEngine yet (#3268) -- mod.rs said so, but a config file reader does not arrive at a module doc. Also gives RewardsClaimConfig a rotation_cursor: Option<Bytes32> field so B2's tie-break cursor survives a save/load round-trip -- an in-memory-only cursor resets on every restart, which would starve a legitimately tied honest tail forever on any node that restarts daily. * fix(rewards-claim): clippy collapsible-match + SPEC v0.1.3 wording refresh Collapses the nested if into the outer match arm in run_cycle (clippy::collapsible_match). Also refreshes NoEntrySlot / no_entry_slot_this_cycle doc comments now that dig-rewards-coin v0.1.3's SPEC §12.5 amendment is merged and tagged: absence is terminal for one claim attempt only, never for the distributor, must not be cached, and must not accumulate into a permanent exclusion set -- confirming rather than diverging from the re-read-every-cycle behaviour already implemented. * fix(rewards-claim): add missing rotation_cursor field in cadence.rs test literal Struct literal in the cadence test module was not updated when RewardsClaimConfig gained rotation_cursor (R5 commit) -- CI's Clippy/Test jobs caught the missing field (E0063) that a local cargo check could not (killed by memory pressure before this workspace-wide build completed). * fix(rewards-claim): F1 -- ChainSourceUnavailable is per-cycle, never a latch compute_state() compared against self.state -- last cycle's OWN computed output -- so once any cycle took an Unavailable port path, every later cycle re-asserted ChainSourceUnavailable forever, even after the chain came back and real claims were submitting. A node still syncing, or one dropped connection, was enough to trip this permanently. Add ClaimStatus::chain_unavailable_this_cycle, reset to false at the top of every run_cycle and set true only on a cycle that actually took the Unavailable path; compute_state now reads that flag instead of self.state, so the reading is live again. Test: a_transient_unavailable_cycle_does_not_latch_state_for_the_rest_of_the_process (engine.rs) drives cycle 1 unavailable, cycle 2 healthy with a submission, and asserts cycle 2 reads Nominal. Plus a compute_state-level regression in types.rs. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(rewards-claim): F3/F4/F5 -- fix stale counters, dedup candidates, correct version doc F3: reset EVERY per-cycle counter (distributors_known/with_own_entry/ claimable/faulted, claims_submitted_this_cycle, no_entry_slot_this_cycle) at the TOP of run_cycle, before any early return. The three ChainUnavailable early-return paths skip the end-of-function assignment block entirely, so a cycle that hit one used to leave the PRIOR cycle's counts sitting on self.status while last_attempt_at stamped fresh for THIS cycle -- a stale count under a fresh timestamp, exactly what SPEC §2.4's staleness reasoning forbids. types.rs's doc sentence for no_entry_slot_this_cycle now correctly says it is dated by last_attempt_at (the field stamped unconditionally every cycle), not last_cycle_at. F4: dedup `candidates` by launcher id before phase 2. A real adapter scanning §1.3 launch comments across every (store_id, root) this node mirrors can plausibly return the same launcher id twice; without dedup phase 2 would evaluate it twice and submit InitiatePayout twice against one entry slot in one cycle -- the second spend is invalid but the fee is paid anyway. F5: dig-rewards-coin is v0.1.3, published on crates.io -- correct the stale "v0.1.1" module-doc claim. Tests: a_chain_unavailable_cycle_does_not_leave_prior_cycles_counters_stale (F3), a_duplicated_launcher_id_submits_exactly_once (F4). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(rewards_claim): fold payout-hash mismatches into the shortfall predicate (F2) A payout-hash mismatch never enters the eligible set, so it was counted in NEITHER distributors_claimable NOR claims_submitted_this_cycle -- the shortfall lived in neither term of compute_state's magnitude comparison. All-K-distributors mismatching therefore read Nominal (falsely healthy). Fold payout_hash_mismatches_this_cycle into the comparison's denominator: submitted < claimable + mismatches. The result is ClaimableButNotClaiming (a shortfall), never the cycle-wide Faulted -- Defect B3 stays fixed. Inverts the assertion at what was engine.rs:1305 (a_payout_mismatch_never_sets_the_cycle_wide_fault_or_masks_other_distributors): it previously asserted ClaimLoopState::Nominal across three cycles of an ongoing mismatch, which pinned the defect as intended behaviour (an A2-class test). It now asserts ClaimableButNotClaiming { claimable: 1, submitted: 1 }. Adds all_distributors_mismatching_is_a_shortfall_not_nominal, covering the brief's exact "what if every distributor refuses for the same reason" case. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(rewards-claim): F1/F3 -- AtomicU32 in fake ports, not Mutex, keeps discovery Send CI's Clippy job (the compiler for this crate, per brief) caught it: holding a std::sync::MutexGuard across the .await in FlakyThenHealthyPort and HealthyThenUnavailablePort's discover_distributors made the returned future not Send, which #[async_trait]'s generated trait signature requires. Neither fake needs a lock -- each holds one call counter, incremented once per call, never read-modify-written across an await point. AtomicU32's fetch_add removes the guard (and the Send bound violation) entirely. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(rewards-claim): F7 -- persist the fee window and cadence gate across restart The per-cycle aggregate fee budget and the 24h cadence clock both lived only in memory: `spent_this_cycle_mojos` was a `run_cycle` local and nothing on disk recorded a completed cycle. Every fresh process got a full `max_cycle_fee_budget_mojos` and an empty cadence clock, so a node stuck in a crash-restart loop could spend unbounded XCH on fees, one full budget per restart. Adds three `#[serde(default)]` fields to `RewardsClaimConfig` (`fee_window_start_unix`, `fee_spent_in_window_mojos`, `last_cycle_completed_at`) and a new opt-in `ClaimEngine::with_persisted_fee_ window(dir, cadence_seconds)` that: - restores the window/cadence state from `dir` at construction, - refuses to start a cycle until the cadence has elapsed since the last completed one, - rolls a fresh budget window only once the cadence has elapsed since it opened, otherwise keeps enforcing the budget against the persisted spend, - persists the spend BEFORE every chain submission (write-then-spend), never batched to cycle end, and persists the completed-cycle timestamp when a cycle finishes. Engines that never call `with_persisted_fee_window` (every pre-F7 test) are unaffected -- this is additive, opt-in state beside the existing rotation cursor, not a change to B2's value-ordering or rotation mechanism. `ClaimStatus`'s own counters stay in-memory on purpose (observability, meant to reset on restart); only the spend bound and the cadence gate persist. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(rewards-claim): F7 -- update cadence.rs test literal for new persisted fields The three new persisted RewardsClaimConfig fields (fee_window_start_unix, fee_spent_in_window_mojos, last_cycle_completed_at) broke this crate's only remaining full struct literal outside config.rs/engine.rs's own test modules -- E0063 missing fields, caught by CI's Clippy job. Switched to ..RewardsClaimConfig::default() so the next added field cannot break this literal again, the same fix already applied once before for rotation_cursor. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(rewards-claim): F8/F14 -- atomic state write, fail closed on a corrupt window Salvaged from a lane killed by a weekly cap before it could commit. Uncompiled at commit time; CI is the compile signal. Covers the fourth gate pass findings on the F7 persisted spend bound: - F8: RewardsClaimConfig::save_to now writes atomically (temp file + rename in the same directory), reusing the pattern already used by mirror/reconcile_state.rs for the same class of state. load_from distinguishes an ABSENT file (clean first run, defaults are correct) from a PRESENT but unparsable one, which fails CLOSED: the window is treated as fully spent and nothing is submitted. Never Default, and never a silent clamp downward, which would hand back the budget the corruption was hiding. - F14: the budget comparison uses saturating arithmetic so a corrupt disk-seeded fee_spent_in_window_mojos cannot panic under the release profile's overflow-checks. - F9/F10/F12/F13 in progress in the same files. Refs #3251 * fix(rewards-claim): negate with ! rather than the unimported Not trait Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com> * fix(rewards-claim): F13 -- correct stale test literals to the folded shortfall compute_state (types.rs) already reported the folded shortfall denominator (distributors_claimable + payout_hash_mismatches_this_cycle) as `claimable` -- that part of F13 landed in f478516. The two engine.rs tests asserting this state were written against the pre-fold, un-folded numbers and never updated, so CI showed the implementation producing the correct folded value (`claimable: 2`, `claimable: 1`) while the test literals still expected the stale un-folded one (`claimable: 1`, `claimable: 0`). Update both literals -- and the comments describing them -- to the folded values the F13 fix actually produces. No production code change; compute_state's predicate and payload were already correct. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * feat(rewards-claim): add ClaimOutcome::Faulted variant Add the seventh ClaimOutcome variant: the type could only say a peer was legitimately not paid, never that a chain call failed. Carries the launcher id, a bounded (200 char) copy of the chain port's error text, and whether a pre-committed fee was reversed, so a reader can tell no money moved. Engine wiring at the two fault arms (engine.rs:332, :377) follows in the next commit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(rewards-claim): both fault arms now push ClaimOutcome::Faulted engine.rs:332 and :377 used to increment `faulted` and discard the outcome, leaving a definitively-failed claim absent from the outcome stream -- indistinguishable from a cycle that never touched that distributor. Both PreBudgetResult::Fault and BudgetPhaseResult::Fault now carry the chain port's (bounded) error text, and the submit_initiate_payout failure path also carries the fee it reversed, so a reader can tell no money moved. The counter stays; it is not a substitute for the outcome. 7 call sites needed updating: 3 PreBudgetResult::Fault constructions (reserve_asset_id, own_entry, payout_threshold), 2 BudgetPhaseResult::Fault constructions (required_fee_mojos, submit_initiate_payout), and the 2 consuming match arms -- exactly the set that was silently discarding a failure before this change. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * test(rewards-claim): a failed submission produces a Faulted outcome Regression for the rework: reuses F12's fixture (a submission that definitely never broadcast) to prove both facts from one cycle -- the outcome exists and carries the reversed fee, and the persisted window still reflects zero net spend. Also fixes a rustfmt diff on the PreBudgetResult::Fault variant Clippy's Rustfmt job flagged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(rewards-claim): delete fee_window_poisoned, stop latching self-healing state Finding 1 (dig-node#594 pass 6): a future-dated clock is self-healing by construction (`t > now` goes false the moment real time passes it), but the engine ORed it into `self.fee_window_poisoned` and set that field `true` permanently -- an RTC glitch or VM resume froze the claim loop forever instead of until the skew passed. This is the third instance of one mechanism (pass 3 latched ChainSourceUnavailable, pass 4 left a stale cadence-gate `state`), so the fix removes the FIELD, not just the bug: with no `fee_window_poisoned` on `ClaimEngine`, `self.fee_window_poisoned = true` is a compile error, not a convention to remember. Per-cycle conditions (corrupt + future-dated-clock) now live in a `CycleConditions` value built fresh at the top of every `run_cycle` from `now` plus a freshly reloaded `RewardsClaimConfig`, used, and dropped -- never stored on the engine. `corrupt` is now re-read from disk every cycle too (it previously latched at construction only), matching what `ClaimLoopState::PersistedStateCorrupt`'s doc already claimed but the code never did. Rewrites the single-cycle f10 regression into a two-cycle test: cycle 1 with a future-dated clock refuses; cycle 2, after the clock catches up and the cadence elapses, MUST claim. The old one-cycle version was green whether the latch bug was present or not. Refs #594 * fix(rewards-claim): satisfy clippy doc-list indent and rustfmt Clippy failed with 3x doc_lazy_continuation on the PersistedStateCorrupt doc comment (types.rs:165-167): continuation lines of a `-` bullet must be indented under the marker, not left flush. Indent them. Rustfmt failed on the new fail_reserve_asset_for early-return in FakeChainPort::reserve_asset_id (engine.rs:888): the Err(...) call exceeded the line-length limit unwrapped. Let rustfmt wrap it. Refs #594 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * test(rewards-claim): red proof for corrupt-then-repaired stale read Cycle 1 refuses a corrupt fee-window file; the file is then repaired to valid values with a fully-spent window and a recent completed-cycle time. Cycle 2 must neither grant a fresh budget nor skip the cadence gate. Fails against current `with_persisted_fee_window`, which loads the three fee-window fields once at construction and never refreshes them from the per-cycle `cfg` -- see engine.rs:149-157, #594. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(rewards-claim): resync fee-window fields from disk every cycle `with_persisted_fee_window` only loaded fee_window_start_unix, fee_spent_in_window_mojos and last_cycle_completed_at once, at construction. Once the now-deleted fee_window_poisoned latch stopped masking it, a file corrupt at construction and repaired later left those three fields stuck on poisoned()'s None/0/None placeholders -- a fresh budget and a skipped cadence gate, and persist_fee_window then overwrote the repaired disk values with them. CycleConditions now carries the three fields from the SAME freshly reloaded cfg it already used for the corrupt/future-dated check, and run_cycle copies them onto self before the cadence gate or window-roll logic runs, but only on a read that is neither corrupt nor future- dated. This also fixes Finding 2b: future_dated_clock now reads cfg's own clocks instead of self's stale ones. Corrects the doc claim at the old lines 236-238 to describe what the code now does for both halves. Closes #594. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * refactor(rewards-claim): make disk the sole store for the fee window Delete `fee_window_start_unix`, `fee_spent_in_window_mojos` and `last_cycle_completed_at` from `ClaimEngine`. `run_cycle` already re-reads `RewardsClaimConfig` fresh every cycle for the corrupt/future-dated check, so caching a copy on the engine bought nothing and cost exactly the stale-read defect class F16 just fixed. A local `FeeWindowState`, scoped to one `run_cycle` call, now threads the in-flight values through `evaluate_budget_phase`/`uncommit_fee`/`persist_fee_window` instead. With no field left to cache into, a future `self.fee_window_start_unix = ...` outside this file is an E0609 compile error, the same enforcement `fee_window_poisoned`'s removal already has. No behaviour change: every early return, the corrupt/future-dated fail- closed path, the cadence gate, the window roll, write-then-spend pre-commit/uncommit and the per-claim ceiling are unchanged -- only where the three values live changed. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Contributor
Author
The
|
A develop -> main release-cut PR was linting main..develop, the full inherited commit range, instead of just the commits it introduces. Every commit in that range was already linted at its own PR while it was still mutable; re-linting it at cut time adds no information and cannot be satisfied once merged (gitlinks and rev-pinned deps make history immutable). Use commitDepth: 1 on a main-base PR; keep the full-range lint unchanged for develop-base PRs, where authors can still fix the commits. Also fix the PR-title lint's blind spot: GitHub's squash merge lands "$PR_TITLE (#$PR_NUMBER)" as the commit subject, about eight characters longer than the title alone, so a title that passes header-max-length can still produce an over-limit commit subject that nothing checks. Lint the exact string that will land. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3 tasks
MichaelTaylor3d
added a commit
that referenced
this pull request
Sep 10, 2026
The previous cut (#602) landed develop content on main as new files rather than merging develop history, so main and develop hold the same paths with independent histories and every later cut PR reports DIRTY with add/add conflicts. GitHub attaches no workflow runs to an unmergeable ref, which is why all six required checks read NOT YET rather than pending. Resolved deterministically and verified by content, not by trusting the merge: develop wins every source file and Cargo.lock; main wins commitlint.yml, whose commitDepth:1 release-cut path and (#N)-suffixed title lint exist only on main and must not be reverted; the workspace version goes to 0.257.0. Against origin/develop the resulting tree differs in exactly three files -- commitlint.yml, Cargo.toml, Cargo.lock -- and driver.rs is byte-identical at 1381 lines, so no shipped work was lost. Refs DIG-Network/dig_ecosystem#3268 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
MichaelTaylor3d
added a commit
that referenced
this pull request
Sep 11, 2026
* chore(release): v0.256.0 -- reward distributor prover, peer claim loop, prover-status RPC (#602)
* feat(mirror): persist mirror-bond coin ids (#575)
* chore: open lane for #574
* feat(mirror): persist mirror-bond coin ids so a restart cannot double-create
Bond identity was reconstructed from a live chain scan on every read
(`mirror/observe.rs`), with no persistence of its own. A restart, a cold
replica, or a lagging/flaky chain source all rendered a real, unspent,
confirmed bond as "no bonds" -- and because the in-flight suppression is
keyed on pending/submitted audit entries, a bond whose create had already
CONFIRMED was not suppressed either, so the same short scan that emptied
the read surface also cleared the one thing that would have stopped a
second coin being paid for collateral that already exists (dig-node#574).
Persist the (store, root, epoch) -> coin_id mapping in the EXISTING spend
audit record (spend-audit.jsonl) rather than a new store: a mirror-coin
create already writes store_id + AuditedBond{root, epoch} + amount there,
and the coin id itself becomes durable the moment resolve_landed_spends
confirms it. This adds the one missing piece -- the advertised URL a
create carries -- and a read-side query, confirmed_mirror_bond, that
returns the newest CONFIRMED record naming a triple.
Chain stays authoritative. mirror::local_bond::recheck_missing_bonds
never trusts the record: for a held bond the live scan did not cover, it
asks the record for a candidate coin id, then re-verifies that SPECIFIC
coin against chain via the same independent check (chain_bond_verdict)
that verifies an untrusted peer's claimed bond. Only a fresh `Bonded`
verdict is folded back in, as covered; `Unbonded`/`Unverified` fall
through to an ordinary create, exactly as if no record existed.
Version: 0.254.86 (patch -- per #522 the MSI ProductVersion minor field
is exhausted and the counter lives in patch).
Co-Authored-By: Claude <noreply@anthropic.com>
* test(mirror): prove the recovery wiring end to end through PassRunner::run
Adds two integration-level tests over the REAL pass pipeline, not just the
isolated recheck_missing_bonds unit tests: a bond missing from the live
scan with a chain-reverified durable record is recovered (no double
create, correct Bonded state reported), and the control -- the same
record but chain disproves it -- correctly falls through to an ordinary
create. Together these are the concrete regression test for the
cold-start/lagging-chain-source double-create scenario the ticket asked
to have measured.
Also refactors in_flight_creates to take the already-folded SpendLedger
instead of re-reading the log itself, so PassRunner::run reads the audit
file once per pass and shares it with the new recovery step, and fixes a
doc comment on in_flight_creates that the recovery step would otherwise
have made stale on landing ("a Confirmed create has a coin the chain
observation already sees" is no longer unconditionally true).
Co-Authored-By: Claude <noreply@anthropic.com>
* chore(fmt): wrap long test signatures to satisfy rustfmt
Co-Authored-By: Claude <noreply@anthropic.com>
* chore(clippy): use slice::from_ref instead of cloning for a single-element slice
Co-Authored-By: Claude <noreply@anthropic.com>
* chore(release): bump to v0.254.89
Base branch moved to develop after PR #576 merged there at v0.254.88
(main and develop are currently identical), leaving this branch's
carried-forward .88 as a zero-increment against the new base. Bumped
to the next free integer after fetching and verifying both origin/main
and origin/develop tip at .88.
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
* fix(peer): count accepted relayed circuits in the connected pool (#579)
serve_accepted_relay_conn served every accepted relayed circuit (full mTLS
auth, full L7 peer RPC) while registering it nowhere, so connected_peers
under-reported every relayed inbound peer -- the relay-leg twin of the
direct-inbound defect #402/#523 already fixed.
adopt_inbound_peer_in_pool now dispatches by TraversalKind: Relayed routes to
dig-gossip's already-published adopt_relayed_inbound_handle (v0.32.0, the rev
this repo already pins), every other tier keeps the unchanged
adopt_direct_inbound_handle path. serve_accepted_relay_conn adopts before
serving and releases after, mirroring the direct listener exactly.
Refs: https://github.com/DIG-Network/dig_ecosystem/issues/3124
* fix(cli): guard the exit-code namespace shared with diga against collisions (#582)
* chore: open lane for #3189
* fix(cli): guard the exit-code namespace shared with diga against collisions
dign and diga deliberately share one process exit-code numbering (dig-app's
outcome.rs says so in its own doc comment), so a number is free only if it
is unoccupied ecosystem-wide. dig-node#407 assigned exit 7 to
NODE_UNREACHABLE by checking only this repo's own table, where 7 genuinely
was free -- and collided with diga's NOT_CONNECTED. A reviewer caught it by
hand; nothing failed automatically.
Adds scripts/check-exit-code-collisions.sh: parses both enums' code()/name()
match arms straight from their own source -- this repo's ExitCode, and a
live fetch of dig-app's outcome.rs at its default branch -- and fails if a
number carries two different names, or if either side draws a number from
the reserved shell signal range (126, 127, 128+N). Ships with an 18-case
hermetic test harness (scripts/tests/check-exit-code-collisions.test.sh)
covering the actual #407 collision shape, arm-order independence, arm-count
mismatch, the reserved-range boundary from both sides, the live-fetch path
itself, and fail-closed behaviour on an empty/missing/unreachable table.
Wires a real (unstubbed) invocation into ci.yml's existing "Release-script
tests" job so a collision introduced by a future PR, on either side, is a
red required check on that PR -- not a note a reviewer has to catch. The
fetch retries twice (2s backoff) since this becomes a required, network-
dependent check; a fetch failure still fails closed after retrying, never
silently passing as "diga has no codes".
Updates SPEC.md 8.4 to point at the mechanical guard instead of leaving
"re-check both tables" as unenforced prose, and records that the
extension's WALLET_WS_ERR.NOT_CONNECTED = -33001 is a separate JSON-RPC
error-code space, not a rival of this one. Adds a doc-comment to the
existing transcribed collision test pointing future readers at the live
script as the authoritative check; the transcription remains as a narrower,
hermetic regression pin for the #407 shape specifically.
No renumbering: every currently-assigned code is unchanged.
Refs #3189
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
* fix(hygiene): port the lost-continuation guard to 4 crates, fix 48 corrupted strings (#3190) (#583)
* chore: open lane for #3190
* fix(hygiene): port the lost-continuation guard to 4 crates, fix 48 corrupted strings
Replicates dig-node-service::continuation_guard (dig-node#526/#501) into dig-node-core,
dig-wallet, dig-runtime and dig-chat-protocol, line-for-line apart from crate-specific
constants -- ported rather than reinvented, per dig_ecosystem#3190.
Wiring the guard in surfaced 48 pre-existing lost-continuation defects the ticket's own
"no measured corruption in these four crates" note did not anticipate: 36 in dig-node-core,
12 in dig-wallet, mostly test-assertion prose where a multi-line message lost its `\`
continuation and shipped the source's own indentation as a mid-sentence space run (one
as the worse `\n`-plus-indentation variant). All 48 are collapsed to the single space the
sentence always meant, with surrounding indentation and wording otherwise untouched.
Two lines are real column-alignment, not defects, and get a targeted EXCLUDED_LINE_RANGES
entry on dig-node-core instead of a rewrite: download.rs's `claimed(...)` fixture-table
trailing comments, and net.rs's `label : value` debug-print alignment.
Refs https://github.com/DIG-Network/dig_ecosystem/issues/3190
Refs https://github.com/DIG-Network/dig_ecosystem/issues/3130
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
* feat(mirror): detect an IP change daily and reconcile mirror coins to the current advertise URL
Automatic half (D1-D4) of the daily mirror-URL reconcile: derived personal-day offset, two-observation hysteresis, nine ordered gates with K sized as a self-funding prefix before any reclaim, `submitted` never `completed`, audit lines gain `reclaim_reason` + `trigger`.
Gates at b4c09866: loop-reviewer PASS (review 5129272285), loop-security PASS @ 175304e1 (tree byte-identical, `git diff 175304e1 b4c09866` empty), adversarial loop-decider PASS (comment 5567083644; SHOULD-FIX findings ticketed separately).
Refs DIG-Network/dig-node#570
Refs DIG-Network/dig_ecosystem#3203
* feat(serve): content hosting + serve path batch, v0.255.0 (dig_ecosystem#3212)
Nine commits from the #3212 serve-path lane, gated at 899cc68f (reviewer review 5130425808,
security comment 5568662836), plus the single semver bump to 0.255.0 for the develop -> main batch.
- store_id/root case normalised at the CapsuleKey boundary; cache delete targets the matched entry
- tier-0 occupancy reads the eviction-aware ledger
- profile-sync outbound budget in bytes; announcer asked first
- melt confirmation depth on the terminal spend, fail-closed
- EngineWarming (-32002) while the peer tier attaches, never -32004
- window completeness derived from the bytes read
- deps: dig-stun 0.2, chia-query 0.24.3, dig-nat 0.21.2, dig-logging 0.2.2
Refs DIG-Network/dig_ecosystem#3212
* chore: untrack gitnexus-generated agent files (#590)
* chore: untrack gitnexus-generated agent files
These files were generated by `gitnexus analyze` as a side effect of
indexing this repository. They are development-loop private tooling
output, not product code, and carry no secrets. They are removed from
tracking going forward via .gitignore; history is deliberately NOT
rewritten.
Refs #3177
* chore: drop private-repo reference from gitignore comment
The ignore comment named a private repository and an internal issue
number in a public file, which is the same disclosure class this
change set exists to remove; the reference is dropped and the
guidance kept.
* feat(rewards): always-on prover loop engine -- honest liveness, type-enforced self-exclusion, bounded spend (#593)
The always-on reward-prover engine: ~2,000 lines under
`crates/dig-node-core/src/rewards/`, built against the merged `dig-rewards-coin`
SPEC. Library only -- nothing spawns it, and the sole production
`RewardsChainPort` refuses every call, so it cannot spend. Wiring the composed
system is #3265, which carries its own gate.
The epic's premise -- "anytime the process isn't running, rewards are not being
distributed" -- is half wrong, and the false half is the dangerous one. `Sync`,
`NewEpoch` and `InitiatePayout` need no manager authority, so funder downtime does
not stop rewards: it FREEZES THE ENTRY SET while accrual and payouts continue.
Peers that stopped mirroring keep earning; peers that started cannot begin. That
shaped the whole design.
Liveness honesty (SPEC 2.4). The status record carries no `healthy`/`ok`/`up`
boolean and no precomputed staleness, because a wedged loop cannot report its own
wedging -- whatever it last wrote stays there, so a writer-set flag reads true
forever after the failure it exists to reveal. The reader derives staleness from
`last_cycle_completed_at` against `observed_at` and its own clock. A recursive
JSON-key test enforces the absence at every nesting depth; asserting on keys and
never substrings, since `ProverState::Running` legitimately serializes the VALUE
"running". The one legal staleness signal is chain-derived (SPEC 12.4: 48 hours
AND a non-zero reserve, from the singleton's own spend history) and lives on the
distributor read, where a wedged prover cannot fake it.
Self-exclusion is a compile error, not a habit. dig-node#261's lesson is that an
invariant enforced on some paths is not an invariant. `admit` is the single
admission point, checks both SPEC 5.2 coordinates (own peer_id OR a payout puzzle
hash this wallet controls), and mints an `AdmittedPeer` with private fields and no
public constructor -- so `EntryAction::Add` cannot be built by a path that skipped
admission.
A prover's own fault can never strike a peer. `GateError` is a distinct type from
`GateIneligibleReason` and `record_prover_fault` takes `&self`, so SPEC 3.6 clause
4 is enforced by the borrow checker rather than by comment. Without that, a
misconfigured operator -- one missing mirror-collateral epoch ordinal -- would
strike every peer at once and evict its entire 250-entry set in three hours, each
eviction a fee it pays plus a settlement out of its own reserve.
The money bounds are stated where a human reads them (`rewards/mod.rs`): 24
bundles/day, 192 entry actions/day, a fee ceiling of 24x the configured standard
fee, 192 removals/day worst case with 96/day sustained churn. Recorded honestly:
SPEC 6.3's rate bound and fee ceiling are ONE control, not two.
Three gate rounds, every leg fresh-context. Round 3 at this head: reviewer PASS,
adversarial decider RATIFY (leg closed), security CHANGES-REQUIRED on a finding
the decider ratified deliberately -- adjudicated in
https://github.com/DIG-Network/dig-node/pull/593#issuecomment-5601784815 and
carried to #3265 with the remedy corrected, because the proposed fix would have
persisted a poison flag to the very store whose writes were failing.
Found and fixed under gate: a census ordinal off by one in both directions (SPEC
4.6 requires n-1 exactly); an unreachable grace window leaving a named constant
with no reader; a missing `NewEpoch` spend; an absent-ordinal path attributing a
prover fault to peers; and a daily fee ceiling 24x too high because a per-bundle
fee was consumed as a daily ceiling.
Refs DIG-Network/dig_ecosystem#3250
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat: serve dig.getRewardProverStatus at Tier::Control (#595)
* chore: open lane for #3269
Bump dig-rpc-protocol to 0.11.0 (adds dig.getRewardProverStatus and
the other reward RPC methods to the wire).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* test(rewards): fail-closed Reward-tier guard + dig-rpc-protocol 0.11 line assertion
- dependency_tree.rs: assert the resolved dig-rpc-protocol line is 0.11 (was 0.10);
documents the known-red two-version state pending the dig-peer 0.14.0 /
dig-download 0.23.0 cascade (#3269).
- reward_methods_tier_guard.rs: fail-closed guard over the live Method::ALL
catalogue -- every Reward-named method must be Tier::Control and not
peer-reachable, so a fifth reward method added later is caught at the wrong
tier automatically rather than inheriting a wrong default (binds #3261's rule
node-side).
- peer.rs: sibling unit test exercising the real (pub(crate)) is_peer_reachable_method,
since an external integration test cannot see it -- same guard, executed against
this node's own allowlist rather than only the shared crate's.
Refs #3269
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* style: remove trailing blank line in reward_methods_tier_guard.rs
* feat(rpc): serve dig.getRewardProverStatus at Tier::Control
Adds the missing handler for PR#595: a new reward_prover_statuses
registry + accessors on Node (empty until #3265 spawns a prover loop,
so the registry read is real, not a stub), a dispatch.rs arm inside
the Method enum match (never the string pre-match), and a
field-for-field mapping from dig-node-core's internal
rewards::state::RewardProverStatus (camelCase-tagged) onto
dig-rpc-protocol 0.11's wire RewardProverStatus (snake_case-tagged
struct, camelCase-tagged ProverState value), widening entry_count
u32 -> u64 explicitly and hex-encoding the three [u8; 32] identity
fields.
An all-zero launcher_id (what an uninitialised registry slot
hex-encodes to) is omitted at this boundary rather than rendered as
a real distributor with a plausible-looking id -- the money-hole
class the dig-rewards-coin driver's adversarial gates found three
times.
Tests (in dig-node-core::lib.rs's existing test module, where the
pub(crate) registry accessors are visible) drive the real dispatch
entry point (handle_rpc -> RpcDispatch::dispatch -> the Method arm)
and assert field-for-field on the serialized JSON body: populated
registry, empty registry (-> {"statuses": []}), zero-id omission,
tier/peer-reachability, enum-match-not-string-prematch, and
launcher_id filtering. The no-health-boolean / no-staleness
assertion is by key set, not substring.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* style: rustfmt the reward-prover-status registry + tests
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* chore(deps): bump dig-download 0.23, dig-peer 0.14, dig-rpc-protocol 0.11
Closes the two-versions-of-dig-rpc-protocol split (#3269): dig-download 0.23.0
and dig-peer 0.14.0 both now resolve dig-rpc-protocol ^0.11, matching
dig-node-core's own dig-rpc-protocol = "0.11.0" line, and dig-node-service's
two 0.10 lines (main dep + dev-dependency restatement for
openrpc_drift_guard.rs) move to 0.11 to match.
Manifests only. cargo update / Cargo.lock intentionally NOT run yet: a fourth
capper, dig-peer-selector ("0.11" in dig-node-core/Cargo.toml), still requires
dig-peer = "^0.13" in every published version through 0.11.1, so the tree
cannot fully resolve until a dig-peer-selector release picks up dig-peer 0.14.
CI will stay red on this commit for that reason, which is expected.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* feat(rpc): close dig-rpc-protocol 0.11 cascade + attribute payout figures
Bump dig-peer-selector 0.11 -> 0.12 (the release that moves onto dig-peer
^0.14) and run cargo update, closing the two-versions-of-dig-rpc-protocol
split: Cargo.lock now resolves exactly one dig-rpc-protocol, at 0.11.0,
alongside dig-peer 0.14.0, dig-download 0.23.0, dig-peer-selector 0.12.0.
Add a subject-attribution test and doc comments to
reward_prover_status_to_wire: total_paid_out_base_units and
reserve_base_units are per-distributor totals (this distributor's payout to
ALL its mirrors, and this distributor's own reserve), never the querying
node's own earnings and never summed/cross-attributed across distributors.
This is the defect class a sibling adversarial gate found in dig-app#403's
rewards pane, which rendered a distributor total as one mirror operator's
personal earnings and overstated by up to 250x.
Checked: rewards/state.rs, rewards/port.rs and rewards/mod.rs contain no
Eligible/verdict/payout_hash symbol, so nothing in this mapping surfaces a
persisted EligiblePayoutHash verdict.
Refs #3269
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rpc): silence dead_code on register_reward_prover_status pending #3265
Clippy's non-test lib target has no production caller for
register_reward_prover_status yet, because #3265 (the always-on prover loop
that would call it from bring-up) has not landed -- only tests call it today.
cfg_attr(not(test), allow(dead_code)) stands in for that missing caller
until #3265 wires a real one.
Refs #3269
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rpc): make the all-zero identity guard non-silent and cover all three fields
Security (blocking) and the adversarial leg both found the same defect in the
zero-launcher_id filter: it checked only launcher_id, so a registration bug
that zeroed store_id or root beside a valid launcher_id would pass through as
a plausible record, and dropping the bad record silently destroyed the
evidence a registration bug happened at all -- SPEC Sec2.4 clause 1's exact
prohibition.
zeroed_identity_fields() now checks launcher_id, store_id AND root. The
dispatch filter still excludes a record with any zeroed field (never renders
an uninitialised slot as a real distributor), but first fires a
tracing::warn! naming which field(s) were zero, so a bad registration is
observable rather than swallowed. Kept isolated in dispatch.rs rather than
woven into the wire mapping, since this belongs at #3265's writer once that
lands.
Replaced get_reward_prover_status_omits_an_all_zero_launcher_id (which
proved the omission but not the observability, and never exercised a zeroed
store_id/root beside a valid launcher_id) with
get_reward_prover_status_logs_and_excludes_a_zeroed_identity_field, covering
both a zeroed launcher_id and a zeroed store_id beside a valid launcher_id,
and asserting the tracing::warn! output via the crate's existing
capture_sync_logs test utility.
Fixed a now-false "Known-red" doc comment on
tests/dependency_tree.rs::the_workspace_carries_exactly_one_module_wire_crate:
the dig-peer 0.14.0 / dig-download 0.23.0 / dig-peer-selector 0.12.0 cascade
already landed in this PR's Cargo.toml/Cargo.lock, so the assertion is green,
not red. Assertion itself untouched -- still exact-version.
Refs #3269
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rpc): correct a born-false "shipped dig-app 15.5.0" doc claim
dig-app's latest release is v15.4.0 -- there is no v15.5.0 tag -- and
dig-app#403 (the pane that would consume dig.getRewardProverStatus) is OPEN
and unmerged. Point the doc comment at the real, unmerged consumer instead
so a future reader doesn't take this as evidence a shipped consumer depends
on the guard, which would wrongly discourage relocating it to #3265's writer.
Refs #3269
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rpc): correct doc placement, assert the zeroed field by name, treat root as an observation
Three findings from the correctness gate on PR#595 at 134864a9.
1. The zeroed-identity helper's doc block was spliced onto the end of
reward_prover_status_to_wire's block with no separator, so the wire-mapping
rationale documented a boolean predicate and the mapping function was left
with no doc at all. Each doc block now sits above the item it describes.
2. The log assertion `logs.contains("launcher_id")` was a tautology: the warn
emits launcher_id as a structured field on every fire, so the property the
guard exists to add -- naming which field was zeroed -- was unasserted.
Deleting `zeroed_fields = ?zeroed` from the warn left every assertion green.
The test now asserts the zeroed_fields value itself, which the fixture makes
exact and disjoint across cases.
3. `root` is an observation, not an identity. A registered prover that has not
completed its first cycle plausibly has no root, and a writer that zero-inits
it would have made a healthy prover invisible. A zeroed launcher_id or
store_id still excludes the record; a zeroed root alone warns and returns.
Refs #3269
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(rpc): restore zeroed_fields structured field dropped from the pushed warn
The previous commit (080be3df) landed with `zeroed_fields = ?zeroed` missing
from the tracing::warn! call in the GetRewardProverStatus filter -- a
one-line regression introduced while proving the new log assertion goes red
without it, never restored before the commit was made. Without this field
the log line never names WHICH field was zero, so an operator sees only
that something was excluded, and the test asserting `zeroed_fields=[...]`
per case would fail. Restored; all 7 reward-prover-status tests green.
Refs #3269
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rpc): split zeroed-field logging by level -- WARN for a missing
identity, DEBUG for a zeroed root
A zeroed launcher_id or store_id is a real registration bug: the record is
excluded and now logs at WARN, naming the exact field(s) via
`zeroed_fields=[...]`. A zeroed root alone is an ordinary pre-first-cycle
state, not a fault: the record is still returned, and now logs at DEBUG
instead of WARN, so an operator polling this endpoint sees warn-level
volume proportional to real registration bugs, not to every
not-yet-cycled prover on every poll.
Updated the doc comments on `zeroed_fields`, the dispatch filter and the
test to describe the level split, and extended the regression test to
assert on level (WARN vs DEBUG) as well as the `zeroed_fields` value.
Proved both directions: flipping the DEBUG branch back to WARN turns the
test red on the level assertion; flipping the field-name assertion back to
a bare `contains("launcher_id")` would have passed unconditionally (the
prior tautology) and is no longer possible since the assertions now pin
`zeroed_fields=[...]` plus the level string.
Refs #3269
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
* feat(rewards): peer-side claim loop -- watch distributors, claim on cadence (#3251) (#594)
* feat(rewards): peer claim loop skeleton -- discovery, cadence, config, claim port
* test(rewards): write all twelve acceptance tests for the peer claim loop
* feat(rewards): wire the seven rewards_claim submodules into the crate
mod.rs declared no submodules, so types.rs/port.rs/config.rs/cadence.rs/
parser.rs/engine.rs/hints.rs (1,435 lines, 25 tests) were never part of the
crate and never compiled. Declare them and re-export the public surface.
* style(rewards): cargo fmt the rewards_claim submodules
* chore(deps): bump dig-node-control-interface 0.33->0.35, dig-rpc-protocol 0.10->0.11.0
dig-rpc-protocol 0.11.0 is merged and tagged upstream; the other dig-*/chia-*
deps of dig-node-service were already at the latest permitted-by-caret version
in Cargo.lock. crates/dig-node-core/Cargo.toml is untouched (#3250's file set).
* chore(deps): revert dig-node-control-interface and dig-rpc-protocol bumps
Both create a duplicate-version split in this PR's scope and neither can be
closed without editing a sibling crate's manifest this lane does not own:
- dig-rpc-protocol 0.11.0 duplicates against dig-node-core/Cargo.toml:194
("0.10.2"), which is #3250's live file set (dig-node#593).
- dig-node-control-interface 0.35.0 duplicates against
dig-wallet/Cargo.toml:81 ("0.33"), a sibling crate this lane does not own;
the observed Clippy break (BalanceAsset/Asset type-identity mismatch,
missing url_reconcile/url_current/urls fields) came from THIS duplicate,
not from dig-rpc-protocol.
Both belong to their own sequenced dep-bump unit of work, not this ticket.
* fix(rewards-claim): fault laundering, permanent no-entry blacklist, fee ceiling magnitude
Three independent gates on dig-node#594 (51516e62) found four logic defects; this
addresses A, B and C per the corrected fix brief (D is documented only, not fixed
here per the brief's own instruction).
Defect A -- the anti-silence surface laundered every real fault into `Nominal`:
- A1: `fault_reported` had no fault-bearing ClaimLoopState to fall through to, so a
chain adapter erroring every cycle read `Nominal` forever. Added
`ClaimLoopState::Faulted { cycles }`, outranking Nominal/ClaimableButNotClaiming,
under ChainSourceUnavailable.
- A2: inverted the test that asserted A1's bug as correct behaviour.
- A3: `ClaimableButNotClaiming` compared a per-cycle snapshot
(`distributors_claimable`) against a lifetime-cumulative counter
(`claims_submitted`), so it latched healthy forever after one lifetime success.
Added `claims_submitted_this_cycle` (per-cycle) as the correct comparand; kept
`claims_submitted` as a cumulative counter.
- A4: `last_discovery_at`/`last_cycle_at` were stamped even on a failed discovery
or an all-faulted cycle, destroying the staleness signal a reader depends on.
Now only stamped on success; added `last_attempt_at` to prove liveness
separately. `fault_reported` and `distributors_faulted` now reset per cycle
instead of latching for the process's lifetime.
Defect B -- "terminal, stop retrying" was implemented as a process-lifetime
blacklist (`terminal_no_entry: HashSet<Bytes32>`, never cleared). That blocked
SPEC 12.5 clause 2's re-entry path (evicted, re-challenged, re-admitted never
claims again) and permanently punished a peer that discovered a distributor
before the funder's AddEntry landed. Removed the blacklist entirely -- `own_entry`
is a cheap chain read, re-issued every cycle for every candidate, matching clause
3's "never cache across cycles". `NoEntrySlot` is now a per-cycle observation, not
a lifetime sentence.
Defect C -- the fee ceiling didn't bind anything and there was no aggregate cap:
- C1: default `CLAIM_FEE_CEILING_MOJOS_DEFAULT` lowered from 1_000_000_000
(transplanted from `MIRROR_SPEND_FEE_CEILING_MOJOS`, sized for a mirror-coin
spend) to 200_000 -- 2x the observed routine Chia fee range (5,000-100,000
mojos), so it actually binds instead of leaving 4-5 orders of magnitude of
slack.
- C2: added a per-cycle aggregate fee budget
(`max_cycle_fee_budget_mojos`, default 10x the per-claim ceiling) checked
across all claims in a cycle, closing the attacker-cost gap where funding K
distributors could force a victim to spend K x the per-claim ceiling per cycle.
New `ClaimOutcome::SkippedCycleBudgetExhausted`.
Tests: rewards_claim test count 26 -> 37 (11 new: repeated_discovery_faults_never_
read_as_nominal, failed_discovery_leaves_last_discovery_at_unchanged, a_reported_
fault_surfaces_as_faulted_not_nominal, a_lifetime_submission_does_not_mask_a_
later_cycle_that_submits_nothing, no_entry_slot_then_re_admitted_produces_a_claim_
on_the_later_cycle, distributors_each_under_ceiling_do_not_collectively_exceed_
the_cycle_budget, the_default_per_claim_ceiling_actually_binds_a_routine_fee, plus
renamed/rewritten no_entry_slot_is_non_terminal_and_re_checked_every_cycle).
Refs #3251
* fix(rewards-claim): refuse a claim entry for the wrong payout puzzle hash
CI fix: cadence.rs's RewardsClaimConfig literal was missing the
max_cycle_fee_budget_mojos field added in the previous commit (E0063,
caught by CI's Clippy/Test jobs -- the local cargo check for this
workspace is too slow to use as the compiler here).
Defect E (security-gate finding, folded in before this pass closes):
submit_initiate_payout was called with entry.payout_puzzle_hash -- whatever
the chain port handed back -- with no check against this node's own
own_payout_puzzle_hash. UnavailableClaimChainPort is the only production
adapter today so nothing can exploit this yet, but the whole point of the
ClaimChainPort seam is that #3249 swaps in a real adapter with nothing
above it changing, so deferring this would ship the landmine live with no
review pass watching for it. Added an equality guard before the spend:
a mismatch refuses to submit, counts
(ClaimStatus::claims_refused_payout_mismatch), surfaces its own named
outcome (ClaimOutcome::PayoutPuzzleHashMismatch), and is reported as a
fault (a divergent entry means the port is confused or hostile, not that
there is nothing to claim) -- never corrected by substituting our own
hash and proceeding.
Defect D: documented, not wired, per instruction -- added the "not yet
wired into node startup" paragraph to mod.rs's module doc (the PR body
carries the same paragraph) so the next reader arrives at the caveat in
the code, not only in a merged PR description.
Refs #3251
* fix(rewards-claim): B1 -- ClaimableButNotClaiming is a magnitude comparison, not a zero-test
submitted_this_cycle < claimable_this_cycle now fires the anti-silence state, carrying
the shortfall as ClaimableButNotClaiming { claimable, submitted }. The previous
submitted_this_cycle == 0 zero-test let one submission mask any number of same-cycle
skips (claimable=10, submitted=1 read Nominal).
Also folds in B3's precedence fix (ChainSourceUnavailable > Faulted >
ClaimableButNotClaiming > Idle > Nominal) and the per-distributor
payout_hash_mismatches_this_cycle counter so a per-distributor fault can no longer
pin the cycle-wide Faulted state, plus R2's rename of terminal_no_entry_slot to
no_entry_slot_this_cycle now that it is no longer terminal.
* fix(rewards-claim): B2/B3 -- value-ordered budget with rotation, per-distributor fault isolation
B2: run_cycle now splits into a pre-budget phase (asset/entry/hash/threshold checks,
producing the claimable set) and a budget phase, ordering the claimable set by accrued
value descending before applying the fee ceiling and cycle budget. Dust distributors
(low accrued value regardless of attacker-controlled fee) now sort last and are the
ones the budget drops, closing the claim-suppression attack where ten high-fee dust
distributors could consume the whole cycle budget ahead of a victim's real earnings.
A rotation_cursor tie-breaks only WITHIN equal-accrued-value tiers so a genuinely
tied honest tail that exceeds one cycle's budget every cycle still rotates through
and is eventually served, rather than dropping the same tail forever.
B3: the payout-hash mismatch check in evaluate_pre_budget now increments the
per-distributor payout_hash_mismatches_this_cycle counter instead of setting
fault_reported, so one hostile or buggy entry can no longer pin the cycle-wide
Faulted state and bury ClaimableButNotClaiming for every other healthy distributor.
R2: terminal_no_entry_slot -> no_entry_slot_this_cycle throughout.
* fix(rewards-claim): R5 -- document not-yet-wired loop; persist B2 rotation cursor
An operator reading their own rewards-claim.json and seeing enabled: true has no way
to know from that file alone that no startup path constructs a ClaimEngine yet
(#3268) -- mod.rs said so, but a config file reader does not arrive at a module doc.
Also gives RewardsClaimConfig a rotation_cursor: Option<Bytes32> field so B2's
tie-break cursor survives a save/load round-trip -- an in-memory-only cursor resets
on every restart, which would starve a legitimately tied honest tail forever on any
node that restarts daily.
* fix(rewards-claim): clippy collapsible-match + SPEC v0.1.3 wording refresh
Collapses the nested if into the outer match arm in run_cycle (clippy::collapsible_match).
Also refreshes NoEntrySlot / no_entry_slot_this_cycle doc comments now that
dig-rewards-coin v0.1.3's SPEC §12.5 amendment is merged and tagged: absence is
terminal for one claim attempt only, never for the distributor, must not be cached,
and must not accumulate into a permanent exclusion set -- confirming rather than
diverging from the re-read-every-cycle behaviour already implemented.
* fix(rewards-claim): add missing rotation_cursor field in cadence.rs test literal
Struct literal in the cadence test module was not updated when RewardsClaimConfig
gained rotation_cursor (R5 commit) -- CI's Clippy/Test jobs caught the missing field
(E0063) that a local cargo check could not (killed by memory pressure before this
workspace-wide build completed).
* fix(rewards-claim): F1 -- ChainSourceUnavailable is per-cycle, never a latch
compute_state() compared against self.state -- last cycle's OWN computed
output -- so once any cycle took an Unavailable port path, every later
cycle re-asserted ChainSourceUnavailable forever, even after the chain
came back and real claims were submitting. A node still syncing, or one
dropped connection, was enough to trip this permanently.
Add ClaimStatus::chain_unavailable_this_cycle, reset to false at the top
of every run_cycle and set true only on a cycle that actually took the
Unavailable path; compute_state now reads that flag instead of
self.state, so the reading is live again.
Test: a_transient_unavailable_cycle_does_not_latch_state_for_the_rest_of_the_process
(engine.rs) drives cycle 1 unavailable, cycle 2 healthy with a
submission, and asserts cycle 2 reads Nominal. Plus a compute_state-level
regression in types.rs.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rewards-claim): F3/F4/F5 -- fix stale counters, dedup candidates, correct version doc
F3: reset EVERY per-cycle counter (distributors_known/with_own_entry/
claimable/faulted, claims_submitted_this_cycle, no_entry_slot_this_cycle)
at the TOP of run_cycle, before any early return. The three
ChainUnavailable early-return paths skip the end-of-function assignment
block entirely, so a cycle that hit one used to leave the PRIOR cycle's
counts sitting on self.status while last_attempt_at stamped fresh for
THIS cycle -- a stale count under a fresh timestamp, exactly what SPEC
§2.4's staleness reasoning forbids. types.rs's doc sentence for
no_entry_slot_this_cycle now correctly says it is dated by
last_attempt_at (the field stamped unconditionally every cycle), not
last_cycle_at.
F4: dedup `candidates` by launcher id before phase 2. A real adapter
scanning §1.3 launch comments across every (store_id, root) this node
mirrors can plausibly return the same launcher id twice; without dedup
phase 2 would evaluate it twice and submit InitiatePayout twice against
one entry slot in one cycle -- the second spend is invalid but the fee
is paid anyway.
F5: dig-rewards-coin is v0.1.3, published on crates.io -- correct the
stale "v0.1.1" module-doc claim.
Tests: a_chain_unavailable_cycle_does_not_leave_prior_cycles_counters_stale
(F3), a_duplicated_launcher_id_submits_exactly_once (F4).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rewards_claim): fold payout-hash mismatches into the shortfall predicate (F2)
A payout-hash mismatch never enters the eligible set, so it was counted in
NEITHER distributors_claimable NOR claims_submitted_this_cycle -- the
shortfall lived in neither term of compute_state's magnitude comparison.
All-K-distributors mismatching therefore read Nominal (falsely healthy).
Fold payout_hash_mismatches_this_cycle into the comparison's denominator:
submitted < claimable + mismatches. The result is ClaimableButNotClaiming
(a shortfall), never the cycle-wide Faulted -- Defect B3 stays fixed.
Inverts the assertion at what was engine.rs:1305
(a_payout_mismatch_never_sets_the_cycle_wide_fault_or_masks_other_distributors):
it previously asserted ClaimLoopState::Nominal across three cycles of an
ongoing mismatch, which pinned the defect as intended behaviour (an
A2-class test). It now asserts ClaimableButNotClaiming { claimable: 1,
submitted: 1 }.
Adds all_distributors_mismatching_is_a_shortfall_not_nominal, covering the
brief's exact "what if every distributor refuses for the same reason" case.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rewards-claim): F1/F3 -- AtomicU32 in fake ports, not Mutex, keeps discovery Send
CI's Clippy job (the compiler for this crate, per brief) caught it: holding
a std::sync::MutexGuard across the .await in FlakyThenHealthyPort and
HealthyThenUnavailablePort's discover_distributors made the returned future
not Send, which #[async_trait]'s generated trait signature requires.
Neither fake needs a lock -- each holds one call counter, incremented once
per call, never read-modify-written across an await point. AtomicU32's
fetch_add removes the guard (and the Send bound violation) entirely.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rewards-claim): F7 -- persist the fee window and cadence gate across restart
The per-cycle aggregate fee budget and the 24h cadence clock both lived only
in memory: `spent_this_cycle_mojos` was a `run_cycle` local and nothing on
disk recorded a completed cycle. Every fresh process got a full
`max_cycle_fee_budget_mojos` and an empty cadence clock, so a node stuck in
a crash-restart loop could spend unbounded XCH on fees, one full budget per
restart.
Adds three `#[serde(default)]` fields to `RewardsClaimConfig`
(`fee_window_start_unix`, `fee_spent_in_window_mojos`,
`last_cycle_completed_at`) and a new opt-in `ClaimEngine::with_persisted_fee_
window(dir, cadence_seconds)` that:
- restores the window/cadence state from `dir` at construction,
- refuses to start a cycle until the cadence has elapsed since the last
completed one,
- rolls a fresh budget window only once the cadence has elapsed since it
opened, otherwise keeps enforcing the budget against the persisted spend,
- persists the spend BEFORE every chain submission (write-then-spend), never
batched to cycle end, and persists the completed-cycle timestamp when a
cycle finishes.
Engines that never call `with_persisted_fee_window` (every pre-F7 test) are
unaffected -- this is additive, opt-in state beside the existing rotation
cursor, not a change to B2's value-ordering or rotation mechanism.
`ClaimStatus`'s own counters stay in-memory on purpose (observability, meant
to reset on restart); only the spend bound and the cadence gate persist.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rewards-claim): F7 -- update cadence.rs test literal for new persisted fields
The three new persisted RewardsClaimConfig fields (fee_window_start_unix,
fee_spent_in_window_mojos, last_cycle_completed_at) broke this crate's only
remaining full struct literal outside config.rs/engine.rs's own test
modules -- E0063 missing fields, caught by CI's Clippy job. Switched to
..RewardsClaimConfig::default() so the next added field cannot break this
literal again, the same fix already applied once before for rotation_cursor.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rewards-claim): F8/F14 -- atomic state write, fail closed on a corrupt window
Salvaged from a lane killed by a weekly cap before it could commit. Uncompiled at
commit time; CI is the compile signal.
Covers the fourth gate pass findings on the F7 persisted spend bound:
- F8: RewardsClaimConfig::save_to now writes atomically (temp file + rename in the
same directory), reusing the pattern already used by mirror/reconcile_state.rs
for the same class of state. load_from distinguishes an ABSENT file (clean first
run, defaults are correct) from a PRESENT but unparsable one, which fails CLOSED:
the window is treated as fully spent and nothing is submitted. Never Default, and
never a silent clamp downward, which would hand back the budget the corruption
was hiding.
- F14: the budget comparison uses saturating arithmetic so a corrupt disk-seeded
fee_spent_in_window_mojos cannot panic under the release profile's
overflow-checks.
- F9/F10/F12/F13 in progress in the same files.
Refs #3251
* fix(rewards-claim): negate with ! rather than the unimported Not trait
Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
* fix(rewards-claim): F13 -- correct stale test literals to the folded shortfall
compute_state (types.rs) already reported the folded shortfall
denominator (distributors_claimable + payout_hash_mismatches_this_cycle)
as `claimable` -- that part of F13 landed in f478516a. The two engine.rs
tests asserting this state were written against the pre-fold, un-folded
numbers and never updated, so CI showed the implementation producing the
correct folded value (`claimable: 2`, `claimable: 1`) while the test
literals still expected the stale un-folded one (`claimable: 1`,
`claimable: 0`).
Update both literals -- and the comments describing them -- to the
folded values the F13 fix actually produces. No production code change;
compute_state's predicate and payload were already correct.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* feat(rewards-claim): add ClaimOutcome::Faulted variant
Add the seventh ClaimOutcome variant: the type could only say a peer was
legitimately not paid, never that a chain call failed. Carries the launcher
id, a bounded (200 char) copy of the chain port's error text, and whether a
pre-committed fee was reversed, so a reader can tell no money moved.
Engine wiring at the two fault arms (engine.rs:332, :377) follows in the
next commit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rewards-claim): both fault arms now push ClaimOutcome::Faulted
engine.rs:332 and :377 used to increment `faulted` and discard the
outcome, leaving a definitively-failed claim absent from the outcome
stream -- indistinguishable from a cycle that never touched that
distributor. Both PreBudgetResult::Fault and BudgetPhaseResult::Fault
now carry the chain port's (bounded) error text, and the
submit_initiate_payout failure path also carries the fee it reversed,
so a reader can tell no money moved. The counter stays; it is not a
substitute for the outcome.
7 call sites needed updating: 3 PreBudgetResult::Fault constructions
(reserve_asset_id, own_entry, payout_threshold), 2 BudgetPhaseResult::Fault
constructions (required_fee_mojos, submit_initiate_payout), and the 2
consuming match arms -- exactly the set that was silently discarding a
failure before this change.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* test(rewards-claim): a failed submission produces a Faulted outcome
Regression for the rework: reuses F12's fixture (a submission that
definitely never broadcast) to prove both facts from one cycle -- the
outcome exists and carries the reversed fee, and the persisted window
still reflects zero net spend. Also fixes a rustfmt diff on the
PreBudgetResult::Fault variant Clippy's Rustfmt job flagged.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rewards-claim): delete fee_window_poisoned, stop latching self-healing state
Finding 1 (dig-node#594 pass 6): a future-dated clock is self-healing by
construction (`t > now` goes false the moment real time passes it), but the
engine ORed it into `self.fee_window_poisoned` and set that field `true`
permanently -- an RTC glitch or VM resume froze the claim loop forever instead
of until the skew passed. This is the third instance of one mechanism (pass 3
latched ChainSourceUnavailable, pass 4 left a stale cadence-gate `state`), so
the fix removes the FIELD, not just the bug: with no `fee_window_poisoned` on
`ClaimEngine`, `self.fee_window_poisoned = true` is a compile error, not a
convention to remember.
Per-cycle conditions (corrupt + future-dated-clock) now live in a
`CycleConditions` value built fresh at the top of every `run_cycle` from `now`
plus a freshly reloaded `RewardsClaimConfig`, used, and dropped -- never
stored on the engine. `corrupt` is now re-read from disk every cycle too (it
previously latched at construction only), matching what
`ClaimLoopState::PersistedStateCorrupt`'s doc already claimed but the code
never did.
Rewrites the single-cycle f10 regression into a two-cycle test: cycle 1 with a
future-dated clock refuses; cycle 2, after the clock catches up and the
cadence elapses, MUST claim. The old one-cycle version was green whether the
latch bug was present or not.
Refs #594
* fix(rewards-claim): satisfy clippy doc-list indent and rustfmt
Clippy failed with 3x doc_lazy_continuation on the PersistedStateCorrupt
doc comment (types.rs:165-167): continuation lines of a `-` bullet must
be indented under the marker, not left flush. Indent them.
Rustfmt failed on the new fail_reserve_asset_for early-return in
FakeChainPort::reserve_asset_id (engine.rs:888): the Err(...) call
exceeded the line-length limit unwrapped. Let rustfmt wrap it.
Refs #594
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* test(rewards-claim): red proof for corrupt-then-repaired stale read
Cycle 1 refuses a corrupt fee-window file; the file is then repaired to
valid values with a fully-spent window and a recent completed-cycle
time. Cycle 2 must neither grant a fresh budget nor skip the cadence
gate. Fails against current `with_persisted_fee_window`, which loads
the three fee-window fields once at construction and never refreshes
them from the per-cycle `cfg` -- see engine.rs:149-157, #594.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* fix(rewards-claim): resync fee-window fields from disk every cycle
`with_persisted_fee_window` only loaded fee_window_start_unix,
fee_spent_in_window_mojos and last_cycle_completed_at once, at
construction. Once the now-deleted fee_window_poisoned latch stopped
masking it, a file corrupt at construction and repaired later left
those three fields stuck on poisoned()'s None/0/None placeholders --
a fresh budget and a skipped cadence gate, and persist_fee_window then
overwrote the repaired disk values with them.
CycleConditions now carries the three fields from the SAME freshly
reloaded cfg it already used for the corrupt/future-dated check, and
run_cycle copies them onto self before the cadence gate or window-roll
logic runs, but only on a read that is neither corrupt nor future-
dated. This also fixes Finding 2b: future_dated_clock now reads cfg's
own clocks instead of self's stale ones. Corrects the doc claim at the
old lines 236-238 to describe what the code now does for both halves.
Closes #594.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* refactor(rewards-claim): make disk the sole store for the fee window
Delete `fee_window_start_unix`, `fee_spent_in_window_mojos` and
`last_cycle_completed_at` from `ClaimEngine`. `run_cycle` already re-reads
`RewardsClaimConfig` fresh every cycle for the corrupt/future-dated check,
so caching a copy on the engine bought nothing and cost exactly the
stale-read defect class F16 just fixed. A local `FeeWindowState`, scoped to
one `run_cycle` call, now threads the in-flight values through
`evaluate_budget_phase`/`uncommit_fee`/`persist_fee_window` instead. With
no field left to cache into, a future `self.fee_window_start_unix = ...`
outside this file is an E0609 compile error, the same enforcement
`fee_window_poisoned`'s removal already has.
No behaviour change: every early return, the corrupt/future-dated fail-
closed path, the cadence gate, the window roll, write-then-spend
pre-commit/uncommit and the per-claim ceiling are unchanged -- only where
the three values live changed.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
* chore(release): v0.256.0
Bump dig-node-service to v0.256.0 for release.
This release includes:
- Reward distributor prover loop (#593)
- Peer reward claim loop (#594)
- Reward prover status RPC (#595)
* ci: scope commitlint to PR-introduced commits, fix title suffix check
A develop -> main release-cut PR was linting main..develop, the full
inherited commit range, instead of just the commits it introduces.
Every commit in that range was already linted at its own PR while it
was still mutable; re-linting it at cut time adds no information and
cannot be satisfied once merged (gitlinks and rev-pinned deps make
history immutable). Use commitDepth: 1 on a main-base PR; keep the
full-range lint unchanged for develop-base PRs, where authors can
still fix the commits.
Also fix the PR-title lint's blind spot: GitHub's squash merge lands
"$PR_TITLE (#$PR_NUMBER)" as the commit subject, about eight
characters longer than the title alone, so a title that passes
header-max-length can still produce an over-limit commit subject that
nothing checks. Lint the exact string that will land.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
* chore(release): v0.257.0 -- the reward distributor lifecycle starts running (#607)
* feat(mirror): persist mirror-bond coin ids (#575)
* chore: open lane for #574
* feat(mirror): persist mirror-bond coin ids so a restart cannot double-create
Bond identity was reconstructed from a live chain scan on every read
(`mirror/observe.rs`), with no persistence of its own. A restart, a cold
replica, or a lagging/flaky chain source all rendered a real, unspent,
confirmed bond as "no bonds" -- and because the in-flight suppression is
keyed on pending/submitted audit entries, a bond whose create had already
CONFIRMED was not suppressed either, so the same short scan that emptied
the read surface also cleared the one thing that would have stopped a
second coin being paid for collateral that already exists (dig-node#574).
Persist the (store, root, epoch) -> coin_id mapping in the EXISTING spend
audit record (spend-audit.jsonl) rather than a new store: a mirror-coin
create already writes store_id + AuditedBond{root, epoch} + amount there,
and the coin id itself becomes durable the moment resolve_landed_spends
confirms it. This adds the one missing piece -- the advertised URL a
create carries -- and a read-side query, confirmed_mirror_bond, that
returns the newest CONFIRMED record naming a triple.
Chain stays authoritative. mirror::local_bond::recheck_missing_bonds
never trusts the record: for a held bond the live scan did not cover, it
asks the record for a candidate coin id, then re-verifies that SPECIFIC
coin against chain via the same independent check (chain_bond_verdict)
that verifies an untrusted peer's claimed bond. Only a fresh `Bonded`
verdict is folded back in, as covered; `Unbonded`/`Unverified` fall
through to an ordinary create, exactly as if no record existed.
Version: 0.254.86 (patch -- per #522 the MSI ProductVersion minor field
is exhausted and the counter lives in patch).
Co-Authored-By: Claude <noreply@anthropic.com>
* test(mirror): prove the recovery wiring end to end through PassRunner::run
Adds two integration-level tests over the REAL pass pipeline, not just the
isolated recheck_missing_bonds unit tests: a bond missing from the live
scan with a chain-reverified durable record is recovered (no double
create, correct Bonded state reported), and the control -- the same
record but chain disproves it -- correctly falls through to an ordinary
create. Together these are the concrete regression test for the
cold-start/lagging-chain-source double-create scenario the ticket asked
to have measured.
Also refactors in_flight_creates to take the already-folded SpendLedger
instead of re-reading the log itself, so PassRunner::run reads the audit
file once per pass and shares it with the new recovery step, and fixes a
doc comment on in_flight_creates that the recovery step would otherwise
have made stale on landing ("a Confirmed create has a coin the chain
observation already sees" is no longer unconditionally true).
Co-Authored-By: Claude <noreply@anthropic.com>
* chore(fmt): wrap long test signatures to satisfy rustfmt
Co-Authored-By: Claude <noreply@anthropic.com>
* chore(clippy): use slice::from_ref instead of cloning for a single-element slice
Co-Authored-By: Claude <noreply@anthropic.com>
* chore(release): bump to v0.254.89
Base branch moved to develop after PR #576 merged there at v0.254.88
(main and develop are currently identical), leaving this branch's
carried-forward .88 as a zero-increment against the new base. Bumped
to the next free integer after fetching and verifying both origin/main
and origin/develop tip at .88.
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
* fix(peer): count accepted relayed circuits in the connected pool (#579)
serve_accepted_relay_conn served every accepted relayed circuit (full mTLS
auth, full L7 peer RPC) while registering it nowhere, so connected_peers
under-reported every relayed inbound peer -- the relay-leg twin of the
direct-inbound defect #402/#523 already fixed.
adopt_inbound_peer_in_pool now dispatches by TraversalKind: Relayed routes to
dig-gossip's already-published adopt_relayed_inbound_handle (v0.32.0, the rev
this repo already pins), every other tier keeps the unchanged
adopt_direct_inbound_handle path. serve_accepted_relay_conn adopts before
serving and releases after, mirroring the direct listener exactly.
Refs: https://github.com/DIG-Network/dig_ecosystem/issues/3124
* fix(cli): guard the exit-code namespace shared with diga against collisions (#582)
* chore: open lane for #3189
* fix(cli): guard the exit-code namespace shared with diga against collisions
dign and diga deliberately share one process exit-code numbering (dig-app's
outcome.rs says so in its own doc comment), so a number is free only if it
is unoccupied ecosystem-wide. dig-node#407 assigned exit 7 to
NODE_UNREACHABLE by checking only this repo's own table, where 7 genuinely
was free -- and collided with diga's NOT_CONNECTED. A reviewer caught it by
hand; nothing failed automatically.
Adds scripts/check-exit-code-collisions.sh: parses both enums' code()/name()
match arms straight from their own source -- this repo's ExitCode, and a
live fetch of dig-app's outcome.rs at its default branch -- and fails if a
number carries two different names, or if either side draws a number from
the reserved shell signal range (126, 127, 128+N). Ships with an 18-case
hermetic test harness (scripts/tests/check-exit-code-collisions.test.sh)
covering the actual #407 collision shape, arm-order independence, arm-count
mismatch, the reserved-range boundary from both sides, the live-fetch path
itself, and fail-closed behaviour on an empty/missing/unreachable table.
Wires a real (unstubbed) invocation into ci.yml's existing "Release-script
tests" job so a collision introduced by a future PR, on either side, is a
red required check on that PR -- not a note a reviewer has to catch. The
fetch retries twice (2s backoff) since this becomes a required, network-
dependent check; a fetch failure still fails closed after retrying, never
silently passing as "diga has no codes".
Updates SPEC.md 8.4 to point at the mechanical guard instead of leaving
"re-check both tables" as unenforced prose, and records that the
extension's WALLET_WS_ERR.NOT_CONNECTED = -33001 is a separate JSON-RPC
error-code space, not a rival of this one. Adds a doc-comment to the
existing transcribed collision test pointing future readers at the live
script as the authoritative check; the transcription remains as a narrower,
hermetic regression pin for the #407 shape specifically.
No renumbering: every currently-assigned code is unchanged.
Refs #3189
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
* fix(hygiene): port the lost-continuation guard to 4 crates, fix 48 corrupted strings (#3190) (#583)
* chore: open lane for #3190
* fix(hygiene): port the lost-continuation guard to 4 crates, fix 48 corrupted strings
Replicates dig-node-service::continuation_guard (dig-node#526/#501) into dig-node-core,
dig-wallet, dig-runtime and dig-chat-protocol, line-for-line apart from crate-specific
constants -- ported rather than reinvented, per dig_ecosystem#3190.
Wiring the guard in surfaced 48 pre-existing lost-continuation defects the ticket's own
"no measured corruption in these four crates" note did not anticipate: 36 in dig-node-core,
12 in dig-wallet, mostly test-assertion prose where a multi-line message lost its `\`
continuation and shipped the source's own indentation as a mid-sentence space run (one
as the worse `\n`-plus-indentation variant). All 48 are collapsed to the single space the
sentence always meant, with surrounding indentation and wording otherwise untouched.
Two lines are real column-alignment, not defects, and get a targeted EXCLUDED_LINE_RANGES
entry on dig-node-core instead of a rewrite: download.rs's `claimed(...)` fixture-table
trailing comments, and net.rs's `label : value` debug-print alignment.
Refs https://github.com/DIG-Network/dig_ecosystem/issues/3190
Refs https://github.com/DIG-Network/dig_ecosystem/issues/3130
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
* feat(mirror): detect an IP change daily and reconcile mirror coins to the current advertise URL
Automatic half (D1-D4) of the daily mirror-URL reconcile: derived personal-day offset, two-observation hysteresis, nine ordered gates with K sized as a self-funding prefix before any reclaim, `submitted` never `completed`, audit lines gain `reclaim_reason` + `trigger`.
Gates at b4c09866: loop-reviewer PASS (review 5129272285), loop-security PASS @ 175304e1 (tree byte-identical, `git diff 175304e1 b4c09866` empty), adversarial loop-decider PASS (comment 5567083644; SHOULD-FIX findings ticketed separately).
Refs DIG-Network/dig-node#570
Refs DIG-Network/dig_ecosystem#3203
* feat(serve): content hosting + serve path batch, v0.255.0 (dig_ecosystem#3212)
Nine commits from the #3212 serve-path lane, gated at 899cc68f (reviewer review 5130425808,
security comment 5568662836), plus the single semver bump to 0.255.0 for the develop -> main batch.
- store_id/root case normalised at the CapsuleKey boundary; cache delete targets the matched entry
- tier-0 occupancy reads the eviction-aware ledger
- profile-sync outbound budget in bytes; announcer asked first
- melt confirmation depth on the terminal spend, fail-closed
- EngineWarming (-32002) while the peer tier attaches, never -32004
- window completeness derived from the bytes read
- deps: dig-stun 0.2, chia-query 0.24.3, dig-nat 0.21.2, dig-logging 0.2.2
Refs DIG-Network/dig_ecosystem#3212
* chore: untrack gitnexus-generated agent files (#590)
* chore: untrack gitnexus-generated agent files
These files were generated by `gitnexus analyze` as a side effect of
indexing this repository. They are development-loop private tooling
output, not product code, and carry no secrets. They are removed from
tracking going forward via .gitignore; history is deliberately NOT
rewritten.
Refs #3177
* chore: drop private-repo reference from gitignore comment
The ignore comment named a private repository and an internal issue
number in a public file, which is the same disclosure class this
change set exists to remove; the reference is dropped and the
guidance kept.
* feat(rewards): always-on prover loop engine -- honest liveness, type-enforced self-exclusion, bounded spend (#593)
The always-on reward-prover engine: ~2,000 lines under
`crates/dig-node-core/src/rewards/`, built against the merged `dig-rewards-coin`
SPEC. Library only -- nothing spawns it, and the sole production
`RewardsChainPort` refuses every call, so it cannot spend. Wiring the composed
system is #3265, which carries its own gate.
The epic's premise -- "anytime the process isn't running, rewards are not being
distributed" -- is half wrong, and the false half is the dangerous one. `Sync`,
`NewEpoch` and `InitiatePayout` need no manager authority, so funder downtime does
not stop rewards: it FREEZES THE ENTRY SET while accrual and payouts continue.
Peers that stopped mirroring keep earning; peers that started cannot begin. That
shaped the whole design.
Liveness honesty (SPEC 2.4). The status record carries no `healthy`/`ok`/`up`
boolean and no precomputed staleness, because a wedged loop cannot report its own
wedging -- whatever it last wrote stays there, so a writer-set flag reads true
forever after the failure it exists to reveal. The reader derives staleness from
`last_cycle_completed_at` against `observed_at` and its own clock. A recursive
JSON-key test enforces the absence at every nesting depth; asserting on keys and
never substrings, since `ProverState::Running` legitimately serializes the VALUE
"running". The one legal staleness signal is chain-derived (SPEC 12.4: 48 hours
AND a non-zero reserve, from the singleton's own spend history) and lives on the
distributor read, where a wedged prover cannot fake it.
Self-exclusion is a compile error, not a habit. dig-node#261's lesson is that an
invariant enforced on some paths is not an invariant. `admit` is the single
admission point, checks both SPEC 5.2 coordinates (own peer_id OR a payout puzzle
hash this wallet controls), and mints an `AdmittedPeer` with private fields and no
public constructor -- so `EntryAction::Add` cannot be built by a path that skipped
admission.
A prover's own fault can never strike a peer. `GateError` is a distinct type from
`GateIneligibleReason` and `record_prover_fault` takes `&self`, so SPEC 3.6 clause
4 is enforced by the borrow checker rather than by comment. Without that, a
misconfigured operator -- one missing mirror-collateral epoch ordinal -- would
strike every peer at once and evict its entire 250-entry set in three hours, each
eviction a fee it pays plus a settlement out of its own reserve.
The money bounds are stated where a human reads them (`rewards/mod.rs`): 24
bundles/day, 192 entry actions/day, a fee ceiling of 24x the configured standard
fee, 192 removals/day worst case with 96/day sustained churn. Recorded honestly:
SPEC 6.3's rate bound and fee ceiling are ONE control, not two.
Three gate rounds, every leg fresh-context. Round 3 at this head: reviewer PASS,
adversarial decider RATIFY (leg closed), security CHANGES-REQUIRED on a finding
the decider ratified deliberately -- adjudicated in
https://github.com/DIG-Network/dig-node/pull/593#issuecomment-5601784815 and
carried to #3265 with the remedy corrected, because the proposed fix would have
persisted a poison flag to the very store whose writes were failing.
Found and fixed under gate: a census ordinal off by one in both directions (SPEC
4.6 requires n-1 exactly); an unreachable grace window leaving a named constant
with no reader; a missing `NewEpoch` spend; an absent-ordinal path attributing a
prover fault to peers; and a daily fee ceiling 24x too high because a per-bundle
fee was consumed as a daily ceiling.
Refs DIG-Network/dig_ecosystem#3250
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* feat: serve dig.getRewardProverStatus at Tier::Control (#5…
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes DIG-Network/dig_ecosystem#3250
Closes DIG-Network/dig_ecosystem#3251
Summary
This release bundles three PRs that deliver the reward distributor and peer claim mechanics to the node:
#593 — Reward Distributor Prover Loop
The always-on prover loop that discovers reward distributors via DHT, validates eligibility through the mirror-coin protocol, constructs ranged capsule challenges, and writes entry-set commitments to the local database for later attestation.
#594 — Peer Reward Claim Loop
The peer-side claim engine that monitors on-chain reward distributors covering the
storeId:roots this node mirrors and submits claims on a configurable cadence. Configured viarewards_claim.cadence_seconds(default: 86400 seconds / 1 day) with a mandatoryjitter_secondsparameter (default: 3600). Enforces a per-claim fee ceiling of 200,000 mojos and maintains a persisted per-window aggregate fee budget that survives restart and fails closed on corrupt or future-dated state files.Important: The claim engine is fully implemented but not yet instantiated; no RPC exposes its status. That surface is being derived separately in DIG-Network/dig_ecosystem#3268 against a real chain adapter, with a hard acceptance condition that
ClaimStatusmust not be exposed until that integration is complete.#595 — Reward Prover Status RPC
The RPC surface for observing prover health and staleness. Note: only
dig.getRewardProverStatushas a dispatch arm; the other three methods—listRewardDistributors,getRewardDistributor,listRewardDistributorCommitments—return-32601(method not found). They await aRewardsChainPortchain adapter, which is carried by DIG-Network/dig_ecosystem#3269. This tag delivers the status, metrics and staleness surface only, not clawback.Binding Contract
The binding contract is
dig-rewards-coinSPEC v0.1.3 (published on crates.io). Section §12.5 was amended by this epic to cover the commitment entry-set structure.