Skip to content

docs(tbtc/signer): record 2026-06-12 architecture decisions in gates doc - #4043

Merged
mswilkison merged 3 commits into
extraction/frost-signer-mirror-2026-05-26from
docs/signer-decision-log-2026-06-12
Jun 12, 2026
Merged

docs(tbtc/signer): record 2026-06-12 architecture decisions in gates doc#4043
mswilkison merged 3 commits into
extraction/frost-signer-mirror-2026-05-26from
docs/signer-decision-log-2026-06-12

Conversation

@mswilkison

Copy link
Copy Markdown
Contributor

Records MacLane's decisions on the follow-up checklist's open questions: audit = hard gate for ECDSA retirement; sidecar over in-process cgo; script-tree vs timelock explicitly open; item 7 deferred with a binding evidence-retention condition; item 6 scheduled as the first Phase 7 item (with the architectural reason: transitional shares are bound to the full included set at StartSignRound, so first-t-responsive requires the interactive exchange that is Phase 7 itself).

🤖 Generated with Claude Code

- 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 <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Jun 12, 2026

Copy link
Copy Markdown

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: 0082108a-1539-4ed5-a272-9f068fedd7ec

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/signer-decision-log-2026-06-12

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

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

mswilkison and others added 2 commits June 12, 2026 12:27
…etion

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 <noreply@anthropic.com>
…ion 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 <noreply@anthropic.com>
@mswilkison

Copy link
Copy Markdown
Contributor Author

Codex + Gemini P1 (both identical) — valid, fixed in 6b74e5d39. The parenthetical asserted evidence retention "is implemented in the Go RFC-21 layer", but the base branch only detects the conflict and returns ErrSnapshotConflict, dropping the envelope — retention lives in the still-open PR #4044. Since item 7's deferral is conditioned on retention existing, that wording created exactly the false sense of diagnosability they describe.

Reworded so the decision log is honest about sequencing: 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. Merge ordering is now self-documenting — if this doc lands before #4044, it correctly describes the gap rather than papering over it.

The reviewers' other verifications (Phase 7 / t-of-included rationale, the nonce-path freeze, audit-gate phrasing, recovery-leaf openness) came back clean — no changes there.

mswilkison added a commit that referenced this pull request Jun 12, 2026
…oints (#4044)

Implements the binding retention condition from today's decision log (PR
#4043): proof-carrying blame (follow-up item 7) is deferred until
production, **provided** telemetry/logging retain enough signed bytes to
diagnose whether targeted equivocation is occurring — otherwise the
revisit condition lacks data.

## What this adds

`EquivocationEvidence` events carrying the **exact signed snapshot
envelopes** (wire bytes verbatim — the #4040 format makes these
available at every detection point) for the three detections that exist
today:

- `snapshot_conflict` — a sender re-submits a *different* signed
snapshot for the same attempt to the coordinator. Both envelopes are
retained; two operator-signed bodies from the same sender for the same
attempt are self-incriminating, which is exactly the substrate item 7's
wire format will formalize.
- `own_snapshot_mutated_in_bundle` — a bundle carries this member's
snapshot with a signature that differs from what it submitted (both
envelopes retained).
- `own_snapshot_missing_from_bundle` — censorship detection (self
envelope retained).

Each event is logged in full (these are rare, and the bytes are the
diagnosis) and forwarded to a process-wide observer hook following the
repo's existing single-observer telemetry pattern, so hosts can persist
evidence into their telemetry stack. Emission is purely additive on the
existing error paths — encode failures degrade to nil fields with a log
line, never perturbing the protocol path.

## Deliberately out of scope

Cross-member comparison (a receiver checking a bundle's snapshot for
sender X against X's direct broadcast) — that's item 7 proper. These are
the detection points that exist today, instrumented so the production
deferral is honest.

Tests pin byte-exact envelope retention for all three kinds, and that an
idempotent identical re-submission emits nothing. `go build ./...`, vet,
gofmt clean; full frost suite green.

🤖 Generated with [Claude Code](https://claude.com/claude-code)
@mswilkison
mswilkison merged commit ee80aef into extraction/frost-signer-mirror-2026-05-26 Jun 12, 2026
19 checks passed
@mswilkison
mswilkison deleted the docs/signer-decision-log-2026-06-12 branch June 12, 2026 17:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant