FROSTR evaluation for tenex-eventd
# FROSTR evaluation for tenex-eventd
## Objective
Evaluate whether Signet should move from a single-key bunker to threshold signing so one leaked machine or one leaked process does not immediately burn the Nostr identity.
## What FROST solves
Fact: RFC 9591 standardizes FROST, a threshold Schnorr signing protocol.
Fact: the Go library `github.com/bytemare/frost` advertises RFC 9591 support and explicitly supports `Secp256k1`.
Fact: FROSTR-adjacent tooling already exists in the Nostr ecosystem (`FROSTR-ORG/igloo-desktop`, `igloo-server`), which makes this direction ecosystem-aligned rather than custom crypto.
## Why this fits Signet
- `tenex-eventd` already acts like a signing control plane.
- NIP-46 gives us the remote-signing protocol boundary.
- FROST is the right primitive if we want to remove single-process custody of the signing key.
## Hard constraint on the current v3 key
Fact: the current v3 identity already exists today as a single local secret.
Inference: turning an already-created single secret into “2-of-3 shares” is not the same trust model as a threshold key generated through DKG from the start.
Important consequence:
- Even if the v3 secret is now split for operational use, the historical single-key exposure already happened.
- That means threshold retrofitting improves future custody but does not erase past exposure history.
## Same-npub share rotation caveat
Fact: RFC 9591 covers threshold signing, not a whole operational system for proactive share refresh / in-place share rotation.
Inference: keeping the same `npub` while rotating one compromised share requires an additional refresh / resharing story, not just baseline FROST signing.
So there are two separate questions:
1. Can we threshold-sign for this identity?
- Yes, in principle.
2. Can we rotate a single share in place without changing the public identity?
- Not from RFC 9591 alone; that needs refresh-capable protocol support and careful ops design.
## Integration options
### Option A: stabilize the current bunker first
- Keep v3 as a single-key NIP-46 bunker.
- Harden ACLs, audit logging, and client permissions.
- Lowest immediate implementation risk.
### Option B: move to a fresh threshold-generated identity
- Create a new Nostr identity through DKG / threshold setup from day one.
- Expose it through a NIP-46-compatible coordinator.
- Best clean-slate security posture.
- Tradeoff: new `npub`.
### Option C: same-npub threshold retrofit with share refresh
- Keep the current public identity.
- Add threshold custody plus future share refresh semantics.
- Highest complexity.
- Not something `go-nostr` or the current tenex daemon gives us out of the box.
## Go ecosystem read
Fact: `bytemare/frost` is a serious Go implementation with secp256k1 support.
Fact: current Nostr-native FROSTR product work appears concentrated in dedicated projects like Igloo, not in `go-nostr` itself.
Inference: we can likely build a Go threshold signer around existing FROST libraries, but we should not expect a drop-in “NIP-46 bunker backed by refreshable FROST custody” package today.
## Effort estimate
- NIP-46 bunker: low-to-moderate, already live locally.
- FROST-backed coordinator prototype: moderate-to-high.
- Production-ready threshold ops (DKG, recovery, resharing, revocation, auditability): high.
## Recommendation
Do not build custom threshold crypto.
Recommended sequence:
1. Keep the current v3 identity behind the new NIP-46 bunker immediately.
2. Decide whether same-`npub` custody is a hard requirement.
3. If no, plan a fresh threshold-generated v4 identity with DKG.
4. If yes, treat “share refresh without `npub` change” as a separate research/architecture track, not as a quick follow-on to the bunker work.
## Decision needed
The founder decision is not “whether FROST is good.” It is:
- Is a new threshold-generated identity acceptable once the bunker path is stable?
- Or is preserving the existing `npub` across future share rotation a hard non-negotiable?
That answer changes the architecture materially.
