The signature-free refund makes an UNCONFIRMED claim sitting through CSV maturity unsafe (eviction/reorg, not a lost mempool race)

[Zyrtnin]

Target-rotated round, the consensus-enforced covenant scripts. MEDIUM by CVSS, but it changes the deadline math every other timelock issue depends on. On main. Verified against the covenant source and the Radiant Core interpreter.

The property

GravityHtlcCovenantFt.rxd:54-57 (and the NFT/RXD siblings):

refund() {
    require(tx.age >= refundCsv);
    require(hash256(tx.outputs[0].lockingBytecode) == expectedMakerFtHash);
}

No signature check. After maturity the refund branch is spendable by anyone who supplies a fee input — the covenant only constrains where the value goes, not who moves it.

That is a deliberate and reasonable design (it makes the refund recoverable without the maker's key). But it has a consequence the surrounding code does not account for.

The attack, and it is simply the rational play

The maker already holds p and has already taken the counter leg. At the instant CSV matures, the maker broadcasts a minimum-fee refund. Every node that sees it first rejects the taker's later claim — even a much higher-fee one — as txn-mempool-conflict.

Radiant has no RBF. There is nothing to outbid with. The taker cannot pay its way past a conflicting transaction that arrived first.

So the taker's real deadline is not CSV maturity. It is:

maturity − propagation − one confirmation

and nothing in the code enforces that margin. blocks_to_deadline plumbing already exists in htlc_spend.py:211-237 and is not used for this.

Why this matters beyond itself

Three other issues filed this round concern t_rxd being unvalidated — #507 (nothing couples it to the value-scaled burial), #508 (the sizer has no caller and the script gate is a tautology), #484 (the coordinator gate measures punctuality, not slow-chain risk). All of them reason about the deadline as maturity. If the effective deadline is earlier by propagation plus a confirmation — and on a chain whose measured inter-block time ranges 9s to 330s, one confirmation is a wide and highly variable quantity — then every one of those margins is computed against the wrong target.

This cannot be fixed in script: there is no opcode that bounds age from above.

Fix

Enforce a hard claim-by height in the leg, at maturity − propagation_margin − confirmation_margin, and refuse to build a claim past it (the same shape as the ETH leg's CLAIM_INCLUSION_BUDGET_S, which exists for the identical reason on the other chain). Size the confirmation margin from a slow-tail inter-block measurement, not the mean — and pair the refusal with an honest-path test, because a margin sized carelessly here refuses valid claims, which on this chain forfeits the asset.

[Zyrtnin]

PARTLY CORRECTED after verifying against Radiant Core. The finding is real but the deadline framing was too strong, and getting it right matters because four other issues are about to size margins against it.

What I verified

src/validation.cpp:724-728 — a transaction whose sequence locks are not satisfied is rejected from the mempool:

if (!CheckSequenceLocks(pool, tx, STANDARD_LOCKTIME_VERIFY_FLAGS, &lp)) {
    return state.DoS(0, false, REJECT_NONSTANDARD, "non-BIP68-final");
}

So the maker cannot pre-broadcast the refund. It is invalid, and rejected, until CSV maturity.

What that means for the race

If the taker's claim is already in the mempool when maturity arrives, the maker's refund is a conflicting spend of an occupied outpoint and is rejected. The taker wins that race. The original framing — "the taker's real deadline is maturity − propagation − confirmation" — assumed the maker could sit ready and win at the instant of maturity. It cannot.

What survives, and it is still a real margin

The taker's claim must be in the mempool and stay there through maturity, or already be confirmed. Three things break that, and they are the actual finding:

1. Mempool eviction. Radiant's mempool expiry is ~8 hours. A claim that neither confirms nor is re-broadcast within that window is dropped, the outpoint frees, and after maturity the maker takes it. With no RBF the taker cannot bump it to escape.
2. Propagation and partitioning. The claim must reach the mining nodes' mempools. A claim broadcast very close to maturity may not have propagated everywhere before the refund becomes valid, and nodes that never saw the claim will happily accept the refund.
3. Reorg. A reorg that un-mines a confirmed claim re-exposes the outpoint. If maturity has passed by then, the refund is immediately valid and the claim must win a second race it may not win.

So the correct requirement is not "confirmed before maturity". It is: the claim should be confirmed comfortably before maturity, because an unconfirmed claim sitting through maturity is exposed to eviction and reorg — not because it loses the mempool race outright.

Why the distinction matters

Sizing a margin as "maturity − propagation − confirmation" as a hard refusal would refuse claims that would in fact succeed, on a chain where refusing to claim forfeits the asset. That is the #484 failure mode exactly: a plausible margin that refuses valid work.

The margin is still worth enforcing — but as a broadcast-early target with an advisory boundary, not a hard cliff, and with re-broadcast to defeat the 8-hour expiry. That is the shape the fix should take, and it is what #507/#508/#509 should be sized against.

Keeping this open with the corrected framing.

[Zyrtnin]

Verified against the vendored consensus source. The title is right and the body's attack narrative is not — and the difference changes what the fix should be.

The mempool race does not go the way the body describes

At the instant CSV matures, the maker broadcasts a minimum-fee refund. Every node that sees it first rejects the taker's later claim.

The maker cannot get there first. tests/vendor/radiant_core/validation.cpp:722-729:

// Only accept BIP68 sequence locked transactions that can be mined in
// the next block; we don't want our mempool filled up with transactions
// that can't be mined yet.
if (!CheckSequenceLocks(pool, tx, STANDARD_LOCKTIME_VERIFY_FLAGS, &lp)) {
    return state.DoS(0, false, REJECT_NONSTANDARD, "non-BIP68-final");
}

A refund that is not yet BIP68-final is rejected from the mempool. So a taker claim broadcast before maturity is already resident, and the maker's refund at maturity is the one rejected — as txn-mempool-conflict. RadiantCovenantLeg.rebroadcast_claim_if_evicted's docstring states this correctly and cites the same lines.

The title — "an UNCONFIRMED claim sitting through CSV maturity … (eviction/reorg, not a lost mempool race)" — is precise. The body then argues the lost race anyway. Worth correcting in place, because the body is what a reader acts on.

What survives, and it is real

The exposure is eviction (mempool expiry, ~8 h) and reorg. If the claim leaves the mempool and is re-broadcast after maturity, the maker's refund can now enter and win. That is genuine, and rebroadcast_claim_if_evicted is a single-shot mitigation, not a guarantee.

Note the direction this implies, which is the opposite of the intuitive one: broadcasting early increases eviction exposure, because the claim sits longer. The window is not simply "broadcast before maturity".

Why I have not implemented the proposed fix

Enforce a hard claim-by height in the leg … and refuse to build a claim past it

A claim built after maturity still succeeds unless the maker actually broadcast a refund. Refusing to build it converts "probably fine, possibly lost" into certainly lost, on a chain where that forfeits the asset. The issue's own closing sentence names this hazard, and the ETH analogue it points at is not the same case: CLAIM_INCLUSION_BUDGET_S refuses because a late ETH claim reverts while publishing p for nothing — strictly negative. A late Radiant claim is not strictly negative.

So the shapes I would consider instead, in preference order:

1. Report, do not refuse. The verdict machinery already exists — assess_claim_finality returns SAFE / WAIT / SQUEEZED and the coordinator surfaces it. Deadline pressure belongs there.
2. Refuse only on evidence, i.e. when a conflicting refund is actually observable, rather than on a modelled margin.
3. A hard height bound only if 1 and 2 prove insufficient, and then sized from a slow-tail measurement with a paired honest-path test, exactly as the issue says.

Happy to build any of these — flagging first because the difference between them is the difference between losing some swaps and forfeiting assets that would have completed.

Related: the signature-free property is the subject of #521, and the same interpreter reading applies there.