diff --git a/340.md b/340.md new file mode 100644 index 0000000000..c463d875e1 --- /dev/null +++ b/340.md @@ -0,0 +1,128 @@ +# NIP-340: Frost Quorum Integration + +## Abstract + +This NIP proposes a standardized method for integrating FROST (Flexible Round-Optimized Schnorr Threshold) signatures within the Nostr ecosystem, specifically focusing on how "Frost Quorum" can be leveraged for enhanced security, distributed key management, and flexible signing policies for Nostr events. + +## Motivation + +The current Nostr protocol relies heavily on single-key signatures, which can present single points of failure, challenges for robust key management in organizational contexts, and limitations for advanced multi-party control over Nostr identities and event publishing. FROST signatures offer a compelling solution by enabling a threshold of signers to collectively authorize actions, without any single participant holding the full private key. + +By integrating FROST, we can achieve: + +* **Enhanced Security**: Distribute the risk of key compromise. A malicious actor would need to compromise a threshold number of participants, not just one. +* **Distributed Control**: Allow multiple entities or individuals to jointly manage a Nostr identity or control the publishing of specific event types. +* **Flexible Quorum Policies**: Define `t-of-n` (threshold `t` out of `n` total participants) signing policies, allowing for resilience against some signers being offline or malicious. +* **Improved Recoverability**: Facilitate key recovery processes by distributing key shares among trusted parties. + +This NIP aims to define the necessary event kinds, tags, and communication flows to enable Nostr clients and relays to understand and facilitate FROST-secured event publishing. + +## Specification + +### 1. FROST Key Generation Event (Kind `XXXX` - To be assigned) + +This event type is used to announce the parameters of a FROST key share distribution and the resulting FROST public key that will represent the Nostr identity. + +**Tags:** + +* `d`: A unique identifier for the FROST key set (e.g., a hash of the initial parameters, or a UUID). +* `k`: The `t` (threshold) value of the FROST scheme (e.g., `k=2` for a 2-of-3 scheme). +* `n`: The `n` (total participants) value of the FROST scheme (e.g., `n=3` for a 2-of-3 scheme). +* `pubkey_package`: The hex-encoded FROST `PublicKeyPackage` (or equivalent structure containing the group public key and verification shares) resulting from the key generation. +* `participant_id_`: For each participant, their Nostr public key (or a derived identifier) and a commitment to their FROST verification share. + +**Content:** + +* JSON object containing any additional metadata about the key set (e.g., creation date, purpose, human-readable description). + +### 2. FROST Signing Session Request Event (Kind `XXXX` - To be assigned) + +This event is sent by a coordinator to initiate a signing session for a specific Nostr event. + +**Tags:** + +* `d`: The unique identifier of the FROST key set (from Kind `XXXX` - Key Generation Event). +* `event_hash`: The SHA256 hash of the Nostr event to be signed (the `message` in FROST terms). +* `coordinator_pubkey`: The Nostr public key of the coordinator initiating the session. +* `p`: Nostr public keys of the intended participants (signers) for this session. +* `session_id`: A unique identifier for this specific signing session. + +**Content:** + +* JSON object containing the FROST `SigningPackage` parameters (e.g., commitment list from the coordinator after receiving round 1 commitments from participants). + +### 3. FROST Signature Share Event (Kind `XXXX` - To be assigned) + +This event is sent by a participant (signer) in response to a `SigningSessionRequest` to submit their partial signature share. + +**Tags:** + +* `d`: The unique identifier of the FROST key set. +* `session_id`: The `session_id` from the `SigningSessionRequest` this share belongs to. +* `p`: The Nostr public key of the coordinator (from `coordinator_pubkey` in the request). +* `signer_id`: The FROST identifier of the participant submitting the share. + +**Content:** + +* The encrypted (e.g., using NIP-44) and hex-encoded FROST `SignatureShare` from the participant. The encryption key would be derived from a shared secret with the coordinator. + +### 4. FROST Aggregated Signature Event (Kind `XXXX` - To be assigned) + +This event is published by the coordinator once enough signature shares have been collected to form the final aggregated FROST signature. + +**Tags:** + +* `d`: The unique identifier of the FROST key set. +* `session_id`: The `session_id` from the `SigningSessionRequest` this aggregated signature belongs to. +* `original_event_id`: The `EventId` of the Nostr event that was successfully signed by the FROST quorum. +* `aggregated_signature`: The hex-encoded final FROST `Signature`. + +**Content:** + +* Empty, or a JSON object with additional context about the aggregation process. + +## Discussion + +### Use Case: Decentralized Signing of Release Code Versioning + +One compelling application of FROST quorum integration with NIP-34 is the decentralized signing of software release code and versioning. This enhances trust and resilience in the software supply chain. + +**Motivation:** +Currently, software releases are often signed by a single entity's key, creating a single point of failure. If that key is compromised, the integrity of past and future releases is jeopardized. Decentralized signing using FROST provides a robust mechanism to mitigate this risk. A release would only be considered legitimate if a predefined threshold of trusted maintainers/developers collectively signs it. + +**Workflow:** + +1. **FROST Key Setup**: A `t-of-n` FROST key set is established among the core maintainers of a software project, representing the project's official release signing authority. The FROST group public key is announced via a Kind `XXXX` (Key Generation) event. +2. **Release Event Creation**: When a new software version (e.g., `v1.0.0`) is ready for release, a NIP-34 repository state event (Kind `30618`) or a custom release event is created, referencing the specific commit hash and version. +3. **Signing Session Initiation**: A designated coordinator (or an automated CI/CD pipeline) initiates a FROST signing session (Kind `XXXX` - Signing Session Request) for the hash of this release event. +4. **Distributed Signing**: Each participating maintainer, upon receiving the signing request, verifies the release event's details. If satisfied, they use their individual FROST key share and nonces to generate a partial signature share and submit it to the coordinator via a Kind `XXXX` (Signature Share) event. This communication could be encrypted for privacy. +5. **Signature Aggregation**: Once the coordinator collects `t` valid signature shares, it aggregates them into a single, compact FROST signature. +6. **Verification and Publication**: The aggregated FROST signature is then attached to or embedded within the original NIP-34 release event (or a new Kind `XXXX` - Aggregated Signature event that links to the release event). This event is then published to Nostr relays. +7. **Client Verification**: Any Nostr client or user interested in verifying the authenticity of the software release can retrieve the NIP-34 release event, extract the FROST aggregated signature, and verify it against the known FROST group public key announced in the Key Generation Event. This provides strong assurance that the release has been authorized by the required quorum of maintainers. + +**Benefits:** + +* **Supply Chain Security**: Drastically reduces the risk of malicious or unauthorized releases. +* **Decentralized Trust**: Shifts trust from a single key holder to a distributed group. +* **Auditable Release Process**: All signing requests and aggregated signatures are transparently recorded on Nostr. +* **Maintainer Resilience**: A release can still be signed even if some maintainers are unavailable, as long as the threshold `t` is met. + +* **Relay Roles**: Relays would primarily act as a message bus for these FROST-related events. They do not need to understand the cryptographic details of FROST but simply forward events based on their `kind` and `p` tags. +* **Client Responsibilities**: Nostr clients would be responsible for: + * Generating and managing FROST key shares. + * Coordinating signing sessions (for multi-party Nostr identities). + * Encrypting/decrypting `SignatureShare` content (e.g., using NIP-44). + * Aggregating shares and verifying final FROST signatures. +* **Integration with NIP-01/NIP-05**: The FROST group public key could be used as the primary public key for a Nostr identity (e.g., in a NIP-05 `_profile` event). Events published with the aggregated FROST signature would then be verifiable against this group public key. +* **ROAST Integration**: This NIP is designed to be compatible with ROAST (Robust Asynchronous Schnorr Threshold) if asynchronous communication and malicious signer detection are desired. +* **Event Kinds**: The `XXXX` placeholders for event kinds need to be formally assigned by the NIP process. It is recommended to use new `Kind` values within the NIP range to clearly distinguish FROST-related events. + +## Future Considerations + +* **On-chain Integration**: Potential for linking FROST-secured Nostr identities to on-chain multi-sig wallets. +* **Key Rotation**: Mechanisms for rotating FROST key shares without changing the public Nostr identity. +* **Light Clients**: Strategies for light clients to verify FROST signatures without needing full knowledge of all participants. + +## Copyright + +This document is hereby placed in the public domain.