A repushed bundle re-arms its reservation from now, so a retrying caller can hold coins indefinitely

[MichaelTaylor3d]

Task

reserve_spend re-arms a coin reservation's expiry from now on every push of the same bundle, with
no cap on total hold. A caller that re-pushes the same signed bundle more often than every 600 s holds
those coins indefinitely, which is the lockout failure the reservation design explicitly names as
the worse of the two — measured on dig-account as available=4000000 selectable=0, renewable
indefinitely.

Context

crates/dig-wallet/src/sage/db.rs:2765-2773:

INSERT INTO pending_transactions (...) VALUES (...)
ON CONFLICT(transaction_id) DO UPDATE SET
   expires_at = excluded.expires_at,
   attempts = pending_transactions.attempts + 1

expires_at is supplied by crates/dig-wallet/src/sage/rpc.rs's reserve_pushed_bundle as
now + RESERVATION_TTL_MS, so each repush pushes the deadline a further 600 s into the future.
attempts is incremented and never read as a cap.

Nothing in this tree exercises it today, which is why this is not a live defect and not gating:
push_signed_bundle has exactly one production caller, crates/dig-node-service/src/control.rs:2877
(control.wallet.broadcast), and there is no automated resend behind it — the mirror-coin, tipping and
collateral spend paths use their own broadcaster and never reach this guard. So the bound currently
holds because of the caller set, not because of the design, and an external caller (dig-app, an
automation, a retrying UI) is outside that accident.

Why it matters more after #497. That PR (closing
#460) moves the COMMON peer-local refusals —
DOUBLE_SPEND, MEMPOOL_CONFLICT, ALREADY_INCLUDING_TRANSACTION — from the free branch onto the
hold branch, which is correct for #460 and is also what enlarges the exposure here. Worst honest case:
one input of a multi-input bundle is spent by someone else, so every node answers DOUBLE_SPEND
forever; before #497 the bundle's other, still-good inputs freed immediately, and after it they are
held and re-armed by every retry.

Found by the adversarial gate on #497 (https://github.com/DIG-Network/dig-node/pull/497#issuecomment-5504576879,
finding F3), which rated it MEDIUM and non-gating and recommended filing rather than widening #460.

Scope

Assess first, then fix the smallest thing that works. Two candidate shapes, both stated by the gate:

• cap the total hold at submitted_at + RESERVATION_TTL_MS rather than extending from now; or
• decline to extend when every observed refusal for that bundle was peer-local.

Read RESERVATION_TTL_MS's own doc before changing anything: the TTL must not be shortened, and
this ticket is not licence to do so. The right outcome bounds total hold without making a genuine
in-flight bundle's inputs reselectable earlier than 600 s after its LAST honest transmission — those
two goals are in tension and the resolution is the deliverable.

Note the deliberate asymmetry that must survive: coin_reservations uses
ON CONFLICT(coin_id) DO NOTHING (db.rs:2788) so a coin backs only ONE in-flight bundle and the
FIRST claim wins. A fix must not turn that into a path where a second bundle can displace or shorten
another's claim.

Evidence

Every claim above is a direct read of dig-node@41dbca5; gitnexus's index for this repo is ~300
commits stale and returns a false-safe impactedCount: 0, so it was not used. Not fired against a live
repushing caller.

Acceptance

A caller that re-pushes the same bundle indefinitely cannot hold its inputs beyond a bounded total,
proven by a test that repushes past the point where a single TTL would have expired and asserts the
coins return to selection — not merely that one push reserves.

Cross-reference: #460 ·
#348 ·
#497

[MichaelTaylor3d]

The interaction that makes this worth more than one 600 s hold

Raised by the adversarial gate on #497 after that PR
narrowed the intrinsic allowlist. Recording it here because #502 is the only place it is visible.

The re-arm at db.rs:2771 is UNCONDITIONAL ON THE REASON. expires_at is recomputed as
now + RESERVATION_TTL_MS on every push of a given transaction_id, whatever the previous refusals
said. That is fine for one retry. The tail risk is a systematic emitter composed with it: a broken
wallet-construction path that produces the same bundle-intrinsic-but-deleted refusal on every attempt —
BLOCK_COST_EXCEEDS_MAX is the concrete example, and it is now deliberately NOT on the allowlist
because it is height- and cost-budget-dependent — paired with a caller that keeps retrying. Each attempt
holds, and each attempt pushes the deadline a further 600 s out. The coins never come back while the
retries continue, and the bundle was never going to land.

The population that should not re-arm is nameable. A bundle whose EVERY observed refusal was
bundle-intrinsic-but-deleted is exactly the set where extending the hold buys nothing: the refusals are
about the bundle's own contents, so no destination is plausibly holding it, and the only reason it is
held at all is that this crate declines to trust one node's view of a height-dependent verdict. Contrast
a bundle refused with DOUBLE_SPEND or a bare verdict, where extending is correct because something may
genuinely be in flight.

So a candidate shape for the fix, alongside the two already in the description: make the re-arm
reason-conditional rather than capping it purely by clock. That preserves the property #497 exists to
protect — a peer-local or unexplained refusal still holds, and still re-arms while a caller is actively
re-pushing — while declining to extend for the case where the hold is pure caution about a
view-dependent verdict.

Whichever shape is chosen, the constraint from the description stands unchanged: RESERVATION_TTL_MS
must not be shortened, and coin_reservations' ON CONFLICT(coin_id) DO NOTHING first-claim-wins
semantics must survive.

[MichaelTaylor3d]

Shape locked, and one correction to the brief

Lane: loop/502-reservation-total-hold -> draft PR #505
(Closes #502 verified to parse as one node). Version 0.251.0; base origin/main @ 476055fb.

The already-shipped check (§2.0)

Nothing in main bounds total hold. #497 (33ab0826) is the most recent touch of this path and it
moved refusals ONTO the hold branch, which enlarges the exposure rather than reducing it. The two
candidate shapes in the description and the third in the comment are all still open. Building.

Both parts, composed -- neither alone is sufficient

A. Total cap anchored on the first push. expires_at clamped to
submitted_at + MAX_RESERVATION_HOLD_MS, with the cap defined as 6 * RESERVATION_TTL_MS (1 hour)
in ONE place so lengthening the TTL scales the cap and the two cannot drift. submitted_at is
already absent from the upsert's DO UPDATE SET, so the stored value is a stable first-push anchor
-- that is now pinned by a test, because the whole cap rests on it.

B. The re-arm becomes conditional on the refusal reason. A second, separate allowlist in
chain.rs beside BUNDLE_INTRINSIC_REFUSALS, holding exactly the four CLVM-execution / cost names
that the existing doc-comment already groups together as excluded-for-being-height-dependent:
GENERATOR_RUNTIME_ERROR, BLOCK_COST_EXCEEDS_MAX, INVALID_BLOCK_COST, INVALID_SPEND_BUNDLE.
Those hold WITHOUT extending. Everything else -- an Err, an acceptance, a bare verdict, an
unrecognised reason -- still extends, which is the conservative default.

The timelocks, the fee-policy names, UNKNOWN_UNSPENT and TOO_MANY_ANNOUNCEMENTS are deliberately
NOT in the new list even though they are also view-dependent: a DIFFERENT node can admit what the
refusing one rejected, so a later push may genuinely land and extending is correct for them.

Why both. A cap alone still lets a systematic emitter hold for the full hour every time. A
reason-conditional re-arm alone still leaves the honest worst case unbounded -- one input of a
multi-input bundle spent by someone else, so every node answers DOUBLE_SPEND forever, which is in
the extending class by design.

"Every observed refusal was of the non-extending class" needs no history table. It falls out of
one extra rule: a re-push may never move expires_at EARLIER than it already is. If every attempt is
non-extending the deadline never leaves the first submitted_at + TTL; if any attempt extended, its
grant survives every later non-extending one.

Correction: SpendStatus::may_have_reached_the_network() is NOT usable on this path

It was recommended for this distinction and it does not apply, in two independent ways:

1. It lives at crates/dig-node-service/src/spend_audit.rs:314, and dig-node-service DEPENDS on
   dig-wallet (dig-wallet = { path = "../dig-wallet" }, Cargo.toml:175). Calling it from
   dig-wallet is an upward dependency.
2. It answers a different question about a different type -- the mirror/tipping ledger's own
   SpendStatus enum, not a mempool refusal string. Its exhaustive-match property is real and worth
   copying in spirit, but there is no enum here to be exhaustive over.

The applicable classifier on this path is chain.rs's string allowlist with a HOLD default, which is
what part B extends. Recording this so the gates do not re-derive it and so nobody re-files it.

Failure directions

Old code errs toward LOCKOUT, unbounded -- the failure this crate's own doc names as the worse of
the two. New code still errs toward HOLDING, and only stops after a bounded total; the first
600 s after any push is unchanged, so nothing #497 protects is narrowed.

[MichaelTaylor3d]

Lane open — #502 total-hold bound

Branch loop/502-reservation-total-hold, worktree C:/tmp/worktrees/dn-502, draft PR #505.

Done so far

• MAX_RESERVATION_HOLD_MS = 6 * RESERVATION_TTL_MS (1 hour) defined beside the TTL in
  crates/dig-wallet/src/sage/rpc.rs, both pub(crate). The TTL is UNCHANGED.
• Four failing db-layer tests written first, in crates/dig-wallet/src/sage/db.rs:
  a_bundle_repushed_forever_still_releases_its_coins_at_the_total_cap (the acceptance test:
  9-minute steps past the cap, iteration count asserted >= 8),
  a_repush_inside_the_cap_still_rearms_from_now,
  a_repush_never_rewrites_the_first_push_anchor,
  the_clamp_uses_the_scalar_two_argument_min_and_max.

Next action: watch the red run, then land the clamp in reserve_spend's upsert
(CASE WHEN NOT may_extend THEN stored ELSE MAX(stored, MIN(excluded, submitted_at + cap)) END),
then the refusal_forecloses_a_later_push classifier in chain.rs and its wiring through
push_signed_bundle -> reserve_pushed_bundle.

SPEC.md states no coin-reservation expiry contract for control.wallet.broadcast (checked
lines 1684, 5065-5080, 8694-8710); the only mention of the 10-minute lifetime is a derivation for
dig-sex's FUNDING_RESERVATION_WINDOW_MS, which this change does not alter. So no SPEC edit.

[MichaelTaylor3d]

Implemented — head 2728e57f, PR #505 (still DRAFT, gates not yet run)

Branch loop/502-reservation-total-hold. Both parts of the locked shape are in:

• MAX_RESERVATION_HOLD_MS = 6 * RESERVATION_TTL_MS (1 h), one definition, beside the TTL in
  crates/dig-wallet/src/sage/rpc.rs. The TTL is unchanged.
• The clamp is in reserve_spend's SQL (atomic against the stored submitted_at anchor), with the
  never-shorten rule that makes the two parts compose without a per-attempt history.
• chain::refusal_forecloses_a_later_push — the four CLVM/cost names, exact + case-insensitive +
  trimmed — decided in push_signed_bundle and carried as
  PendingTransactionRow::may_extend_expiry.

Verification. cargo test -p dig-wallet --lib: 778 passed, 0 failed, 1 ignored, 0 filtered
(up from 770; +9 tests). Reverting ONLY the SQL clamp with the tests left in place gives
4 failed, 1 passed — the one that stays green is a_repush_inside_the_cap_still_rearms_from_now,
the #348/#497 property the fix must not break. CI Rustfmt / Clippy / version-increment / commitlint
are green; Test + coverage is still running.

SPEC.md needed no change — it states no reservation-expiry contract for control.wallet.broadcast.

Next action: hand back to the review gate. Nothing merged, PR left draft.

[MichaelTaylor3d]

Child filed from the gate round

The adversarial gate's R2 and the correctness gate's finding 5 both landed on the same limitation of
the cap: prune_reservations DELETEs the row, so submitted_at anchors only while the row exists and
a re-push after the cap fires gets a fresh hour. The bound is on CONTINUOUS hold, not aggregate hold.

That is a genuine trade-off rather than a defect -- bounding aggregate hold means permanently declining
to protect a bundle that may still land, which is the direction #348 and #497 closed -- so it is out of
scope here and filed as its own decision:

• The reservation cap bounds continuous hold, not aggregate hold: a pruned row re-anchors on the next re-push #511

PR #505 pins the sawtooth with a test and states it in the MAX_RESERVATION_HOLD_MS doc, so this
ticket still closes on known, measured behaviour rather than on an unstated one.

[MichaelTaylor3d]

Fix round on PR #505 — part B removed, clamp kept

Branch loop/502-reservation-total-hold, head fce23589 (pushed).

Done

• Removed the reason-conditional re-arm in full: VIEW_DEPENDENT_BUNDLE_CONTENT_REFUSALS,
  refusal_forecloses_a_later_push, attempt_may_extend_the_hold + its call site, the
  PendingTransactionRow::may_extend_expiry field and its bind, and the CASE WHEN ? = 0 arm.
  BUNDLE_INTRINSIC_REFUSALS / refusal_is_bundle_intrinsic untouched.
• Clamp simplified to MAX(stored, MIN(excluded, submitted_at + cap)). Bind order re-verified
  after the deletions: 7 placeholders (6 VALUES + 1 cap), 7 binds, matching order.
• Repurposed the old non-extending-shortening test as
  a_repush_under_a_clock_that_stepped_backwards_never_shortens_a_live_hold, which is the
  proof the outer MAX is load-bearing.
• Added a_repushed_bundle_gets_a_fresh_anchor_after_the_cap_prunes_its_row (the sawtooth) and
  a_repush_inside_the_last_ttl_before_the_cap_buys_less_than_a_full_ttl (the boundary, both sides).
• SPEC.md §18.9a gained the total-hold bound as a normative clause.
• MAX_RESERVATION_HOLD_MS doc now states three limitations honestly and the SQLite REAL-promotion
  fail-open direction.

Measured — cargo test -p dig-wallet --lib, unpiped: running 778 tests →
776 passed / 1 failed / 1 ignored. The one failure is the known
sync_supervisor::stall_evidence_survives_the_end_of_a_session 120 s timeout flake; re-run alone it
is 1 passed; 0 failed; 777 filtered out. 778 = baseline 779 − 3 removed + 2 added.

Finding from my own fixture: the clamp lives in the ON CONFLICT arm, so it binds on RE-push
only — the first INSERT takes its deadline verbatim. Harmless in production (now + TTL always),
but a test that seeds an over-cap first insert measures nothing. Noted in the test.

Version discrepancy to flag: the brief said 0.251.0; Cargo.toml on disk reads 0.256.0
(origin/main is 0.247.0). Not renumbered.

Next action: finish the clamp revert-proof (in flight), restore db.rs from the backup, rewrite
the PR body via --body-file, report back. Do not merge, do not undraft.