A stated refusal from the second push destination frees inputs the first may have admitted

[MichaelTaylor3d]

Task

is_definitive_rejection frees a bundle's inputs on any stated refusal, but chia-query's push_tx transmits to up to three destinations — so a stated refusal from destination B can free the inputs of a bundle destination A already admitted.

The path, concretely

chia-query router.rs:793 push_tx calls peer_then_coinset(peer, peer_retry, coinset), and router.rs:139-167 will try all three:

Peer A admits the bundle to its mempool, but the ack times out (peer/mod.rs:1074, "request timed out") → peer A is ejected and the bundle is re-transmitted to peer B → peer B has already seen it gossiped and answers with a stated reason → is_definitive_rejection is true → reserve_pushed_bundle is skipped → the inputs of a bundle sitting in the public mempool return to the selectable set → a second send inside the 10-minute window reselects them.

That is the double-select window dig-node#348 exists to close, reached by a different route.

This is NOT a regression, and it must not be read as one

Before dig-node#453, rejection was Some(..) on every non-admitted answer, so this path freed the coins along with all the others. #453 strictly narrowed it. What changed is that this is now the only remaining free path, which is what makes it worth naming.

The question to settle

Should the guard key on the CLASS of stated reason rather than merely on its presence?

A reason like BAD_AGGREGATE_SIGNATURE is a property of the bundle — it will be refused everywhere, so freeing the inputs is correct. A reason like DOUBLE_SPEND or a mempool-full condition is a property of that peer's view, and may mean another peer is holding the very bundle whose inputs are about to be freed.

Two cautions for whoever takes it:

• The reason string is supplied by an untrusted peer (§13 / NC-12). A classifier keyed on attacker-controlled text is itself a decision: a peer that wants its refusal to stick can write whatever text makes that happen. Consider what a hostile string can achieve in each direction before keying on content.
• Do not shorten the TTL to compensate. RESERVATION_TTL_MS = 600_000 and the code's own doc states the reasoning: that trades a double-select for a lockout, and a lockout is the worse failure — measured on dig-account as available=4000000 selectable=0, renewable indefinitely.

Evidence

Found by the security re-gate of #453 while verifying that the #348 hold actually fires. It correctly declined to gate on this, since #453 improves the situation rather than causing it. Traced by direct read; not fired against a live multi-peer push.

Acceptance

A stated refusal that is a property of one peer's view, arriving after another destination may have admitted the bundle, does not return the inputs to selection — proven by a test that distinguishes the two reason classes, not merely that some reason is present.

[MichaelTaylor3d]

Verification sweep verdict: NOT SATISFIED — leaving open (2026-09-01)

Verified against code on origin/main (aa9ec72). Symbols re-located by name.

The guard is still purely presence-based

crates/dig-wallet/src/sage/rpc.rs:2191 — the entire guard is:

!outcome.accepted && outcome.rejection.is_some()

No parsing, no classification, no allowlist. Call site unchanged at rpc.rs:2145;
reserve_pushed_bundle at rpc.rs:2202.

No reason-class concept exists anywhere in the tree. A repo-wide grep for
BAD_AGGREGATE_SIGNATURE|DOUBLE_SPEND|MEMPOOL_FULL|reason_class|rejection_class returns only
doc-comments, test fixture strings, and unrelated modules.

Reason production funnels through one place — ChainTransport::stated_rejection,
crates/dig-wallet/src/sage/chain.rs:519 — which trims and filters empty and prefixes the verdict,
but does not classify.

The correct-fix guardrail held: rpc.rs:544 — const RESERVATION_TTL_MS: i64 = 10 * 60 * 1000;
= 600_000, unchanged. Nobody shortened the TTL to compensate, which the body specifically warns
against.

The tests exist but pin the WRONG AXIS — this is the part worth reading

There is a paired test that looks like the acceptance bar and is not:

• rpc.rs:10941 a_bundle_denied_without_a_reason_is_held_rather_than_freed — rejection: None → held
• rpc.rs:11047 a_refused_bundle_reserves_nothing — rejection: Some("mempool said no") → freed

Their own doc says the two "differ in the rejection field alone" — i.e. presence vs absence, not
class vs class. And "mempool said no" is a generic string, not a real class. So no test feeds two
different reason CLASSES and asserts opposite outcomes, and the acceptance bar — "proven by a test
that distinguishes the two reason classes, not merely that some reason is present" — is precisely the
one thing not asserted.

chain.rs:764 a_bare_verdict_is_not_a_stated_rejection does use BAD_AGGREGATE_SIGNATURE, but only
asserts the string survives into rejection; it says nothing about reservation.

A third deliverable the body does not mention

SPEC.md:5490-5498 states the rule normatively as presence-based — "definitive only when the
mempool stated its reason (accepted:false WITH a rejection)". Closing this ticket therefore
requires amending that paragraph in the same unit of work, or the code will contradict its own spec.

What is missing, and what to build on

Missing: a classifier over the peer-supplied reason (bundle-property → free; peer-view-property such
as DOUBLE_SPEND / mempool-full → hold), defaulting to HOLD on an unrecognised string — which is
also the answer to the body's untrusted-text caution, since a hostile peer then cannot write a string
that frees anything; the SPEC.md:5490 paragraph; and the two-class test pair.

To build on: stated_rejection (chain.rs:519) is the single funnel where every reason string is
produced, so a classifier has exactly one place to live. And the existing two-fixture harness
(FakePusher::answering, backend_with(..), the two-coin selection fixture) already produces
opposite reservation outcomes — it needs its reason strings varied, not a new harness.