docs(rfc-21): Annex B — computed serial-attempt latency budget vs on-chain timeouts

[mswilkison]

Stacked on #4030 (base: unify/roast-coordinator-seed-go-2026-06-11), which is itself stacked on #3866 — so the annex numbering (A: seed derivation, B: latency budget) lands in order. Implements item 4 of the review feedback (serial attempts vs real ROAST concurrency: "it should be a computed bound in the docs").

What

Adds RFC-21 Annex B (informative): serial-attempt latency budget vs on-chain timeouts — the computed bound with current code and chain values, and an honest statement of which constraint actually binds:

• Parameters: 41 blocks (≈8.2 min) per attempt (signingAttemptMaximumBlocks), signingAttemptsLimit = 5, engine ROAST coordinator timeout 30 s (sub-dominant), n=100/t=51/f=49, redemptionTimeout 5 days, moving-funds timeouts 7 days.
• Serial-delay arithmetic: as deployed, ≤ ~41 min before the loop gives up (~175× inside the redemption timeout); the review's f·τ worst case at a hypothetical f+1 = 50-attempt limit is ~6.8 h (~17× inside). Serial latency comfortably fits the deadlines whenever attempts can succeed at all.
• The honest caveat: the binding liveness constraint is all-honest-subset sampling, not serial latency. Because the transitional finalize requires every included member to contribute, per-attempt success is ∏(49−i)/(100−i) — 0.49 / 0.24 / 0.11 / 0.025 for f = 1/2/3/5 — so for f ≥ 3 the 5-attempt loop fails with better-than-even odds long before any timeout is approached. The existing signingAttemptsLimit rationale in pkg/tbtc/node.go explicitly assumes f ≤ 2; beyond that the backstops are operator-inactivity claims, redemption-timeout slashing, and wallet retirement — all outside the signing loop. (This profile is inherited from the tECDSA-era loop, not introduced by FROST.)
• Codified recommendation: before the ECDSA-retirement phases, adopt t-of-included finalize (first t responsive members — groundwork already in the signer's true-late-t-of-n-finalize-considerations.md) at minimum for redemption signings; treat bounded n−t+1 concurrency as the follow-on; until then alert when observed attempt-failure rates imply f ≥ 3 behaviour.

Docs-only; no code change.

🤖 Generated with Claude Code

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: c46e62ef-74af-47d0-95f8-ff314541be01

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch docs/roast-serial-attempt-latency-budget-2026-06-11

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}