From 153b14bd4d3b4d203f7f544ef7333e736f3608a4 Mon Sep 17 00:00:00 2001 From: maclane Date: Fri, 12 Jun 2026 12:17:46 -0400 Subject: [PATCH 1/3] docs(tbtc/signer): record 2026-06-12 architecture decisions in gates doc - external audit covering frost-core 3.x + frost-secp256k1-tr is a HARD GATE for the ECDSA-retirement phases (resolves the Gate 1 fork recorded earlier today) - sidecar signer process chosen over in-process cgo as the target architecture; dlopen bridge stays transitional; unblocks #4007 scoping - script-tree commitment vs timelocked recovery leaf: explicitly open, no assumption may be baked in yet - proof-carrying blame deferred until production WITH a binding retention condition: keep enough signed bytes at detection points to diagnose targeted equivocation - t-of-included finalize scheduled as the first Phase 7 item: the transitional flow binds shares to the full included set's commitment list at StartSignRound (finalize enforces contributions == included set), so first-t-responsive requires the interactive two-round exchange that is Phase 7 itself Co-Authored-By: Claude Fable 5 --- .../roast-phase-5-security-rollout-gates.md | 52 ++++++++++++++----- 1 file changed, 40 insertions(+), 12 deletions(-) diff --git a/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md b/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md index 689afc5818..01eec3d7a9 100644 --- a/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md +++ b/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md @@ -75,18 +75,46 @@ production signatures (`frost-secp256k1-tr`) and the v0.6.0 → 3.0.0 evolution of `frost-core` have **no external audit coverage**. The NCC assessment establishes pedigree for the core protocol implementation but cannot be cited as covering the pinned version -range. Gate 1 sign-off must therefore do one of: - -1. Commission (or await) an external audit covering `frost-core` 3.x - and the `frost-secp256k1-tr` ciphersuite - the follow-up - checklist's "external audit as merge gate for ECDSA-retirement - phases" decision; or -2. Record an explicit, written risk acceptance for the unaudited - range, scoped to the canary stages of Gate 3 and revisited before - full rollout. - -This section records the facts; choosing between (1) and (2) is a -team decision. +range. + +**DECIDED (2026-06-12, MacLane): an external audit covering +`frost-core` 3.x and the `frost-secp256k1-tr` ciphersuite is a HARD +GATE for the ECDSA-retirement phases.** Gate 1 sign-off for those +phases requires the completed audit; canary stages before ECDSA +retirement may proceed under the existing gate criteria, but +retirement-phase rollout does not start without the audit report in +hand. + +## Decision Log (2026-06-12) + +Decisions taken on the post-merge follow-up checklist's open +architecture questions: + +1. **External audit = hard gate for ECDSA retirement** (see above). +2. **Sidecar signer process** chosen over in-process cgo as the + target architecture (stepping stone to TEE deployment). The + in-process dlopen bridge remains the transitional integration; new + isolation-sensitive work should assume the sidecar boundary. This + unblocks scoping of the decision-gated TEE checker stack (#4007). +3. **Script-tree commitment vs timelocked recovery leaf for FROST + wallets: explicitly OPEN.** Needs more evaluation time; multiple + open questions remain. No work should bake in either assumption. +4. **Proof-carrying blame (follow-up item 7): deferred until + production**, with a binding retention condition: telemetry and + logging must retain enough signed bytes to diagnose whether + targeted equivocation is occurring, so the revisit decision has + data. (Retention of conflicting signed evidence envelopes at the + detection points is implemented in the Go RFC-21 layer; full + cross-member equivocation comparison arrives with item 7 itself.) +5. **t-of-included finalize (follow-up item 6): scheduled as the + first engineering item of Phase 7**, not earlier. The transitional + flow computes each member's signature share at StartSignRound + against binding factors derived from the full included set's + commitment list (finalize enforces contributions == included set), + so first-t-responsive finalize requires computing shares after the + responsive subset is known - the interactive two-round exchange + that IS Phase 7's core. Pulling it earlier would implement the + interactive path without its Go-side consumer. ## Provisional Rollback Thresholds (Draft) From 54b041e9383c29ebe1223094cba197fec0a977b9 Mon Sep 17 00:00:00 2001 From: maclane Date: Fri, 12 Jun 2026 12:27:07 -0400 Subject: [PATCH 2/3] docs(tbtc/signer): commit the transitional deterministic path for deletion Decision 6 (2026-06-12, MacLane): the transitional deterministic-nonce path is dev/staging-only behind the production gate, and its nonce safety rests on RoundNonceBinding transcript completeness - the F1 finding showed one missing field is a key-extraction-class bug that an experienced review missed. No production benefit justifies carrying that invariant indefinitely. - deletion trigger: interactive production path validated end to end; then the transitional StartSignRound/FinalizeSignRound deterministic flow and the nonce-binding machinery are removed - until then the transitional flow is FROZEN: no new transcript inputs (each must extend RoundNonceBinding; omission recreates F1) - nonce.rs carries the freeze marker at the point of hazard - item 6 interaction recorded: the Phase 7 interactive session flow is designed t-of-included-native from the start; no retrofit of the transitional finalize contract Co-Authored-By: Claude Fable 5 --- .../roast-phase-5-security-rollout-gates.md | 20 +++++++++++++++++++ pkg/tbtc/signer/src/engine/nonce.rs | 9 +++++++++ 2 files changed, 29 insertions(+) diff --git a/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md b/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md index 01eec3d7a9..b639b0f53d 100644 --- a/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md +++ b/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md @@ -115,6 +115,26 @@ architecture questions: responsive subset is known - the interactive two-round exchange that IS Phase 7's core. Pulling it earlier would implement the interactive path without its Go-side consumer. +6. **Transitional deterministic-nonce path: committed for DELETION.** + The path is already production-gated (production signing is + interactive-FROST-only with OS randomness), so it serves + dev/staging only - while its nonce safety rests on the + RoundNonceBinding transcript being *complete*, and the F1 finding + (round-nonce-v3) demonstrated that one missing field is a + key-extraction-class bug that an experienced review missed. + Carrying a binding-completeness invariant indefinitely is a + permanent footgun with no production benefit. + **Deletion trigger: the interactive production path validated end + to end** - at that point the transitional + StartSignRound/FinalizeSignRound deterministic flow and the + round-nonce binding machinery are removed. Until then the path is + FROZEN: no new transcript inputs may be added to the transitional + signing flow, because each addition must extend RoundNonceBinding + and any omission recreates the F1 bug class. + Interaction with item 6: the deletion commitment means the Phase 7 + interactive session flow is designed t-of-included-native from the + start; no first-t-responsive retrofit of the transitional finalize + contract is needed or wanted. ## Provisional Rollback Thresholds (Draft) diff --git a/pkg/tbtc/signer/src/engine/nonce.rs b/pkg/tbtc/signer/src/engine/nonce.rs index 045fc3f45d..b121acbeec 100644 --- a/pkg/tbtc/signer/src/engine/nonce.rs +++ b/pkg/tbtc/signer/src/engine/nonce.rs @@ -1,4 +1,13 @@ // Deterministic round-nonce binding (round-nonce-v3 transcript seed). +// +// DELETION COMMITTED (decision 2026-06-12; see the Decision Log in +// docs/roast-phase-5-security-rollout-gates.md): this deterministic +// transitional path is dev/staging-only (production-gated) and will be +// deleted once the interactive production path is validated end to end. +// Until then the transitional signing flow is FROZEN - do not add new +// transcript inputs to it: each one must also extend RoundNonceBinding +// below, and an omission is a key-extraction-class bug (see the v3 +// history in the struct docs). use super::*; From 6b74e5d39794a1b207d7c9fe87f919605fbf32b2 Mon Sep 17 00:00:00 2001 From: maclane Date: Fri, 12 Jun 2026 12:54:23 -0400 Subject: [PATCH 3/3] docs(tbtc/signer): correct the evidence-retention status in the decision log Codex and Gemini both flagged (P1): the item-7 deferral parenthetical asserted evidence retention "is implemented in the Go RFC-21 layer", but the base branch only detects a conflict and drops the envelope - the retention logic lives in the unmerged PR #4044. Because item 7's deferral is conditioned on retention being present, that false claim created a false sense of diagnosability. Reworded: the deferral is now explicitly contingent on retention landing; retention is attributed to PR #4044 (scaffold branch); and the base layer's drop-the-envelope behavior until that merges is stated plainly, so the deferral does not read as already in force. Co-Authored-By: Claude Fable 5 --- .../docs/roast-phase-5-security-rollout-gates.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md b/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md index b639b0f53d..51c671be04 100644 --- a/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md +++ b/pkg/tbtc/signer/docs/roast-phase-5-security-rollout-gates.md @@ -103,9 +103,15 @@ architecture questions: production**, with a binding retention condition: telemetry and logging must retain enough signed bytes to diagnose whether targeted equivocation is occurring, so the revisit decision has - data. (Retention of conflicting signed evidence envelopes at the - detection points is implemented in the Go RFC-21 layer; full - cross-member equivocation comparison arrives with item 7 itself.) + data. **This deferral is contingent on that retention landing.** + Retention of the conflicting signed evidence envelopes at the + detection points is added by keep-core PR #4044 against the + scaffold branch (`EquivocationEvidence` instrumentation); until + that merges, the base Go RFC-21 layer detects a conflict and + returns `ErrSnapshotConflict` but drops the conflicting envelope, + so the retention condition is NOT yet met and the deferral does + not hold. Full cross-member equivocation comparison arrives with + item 7 itself. 5. **t-of-included finalize (follow-up item 6): scheduled as the first engineering item of Phase 7**, not earlier. The transitional flow computes each member's signature share at StartSignRound