Introduction
When multiple DID controllers want to anchor their updates in a single Bitcoin transaction, they need two things: a multi-party signature scheme and a communication channel. did:btcr2 uses MuSig2 for the first and Nostr for the second — combining a Bitcoin-native cryptographic protocol with a decentralized relay network to coordinate beacon aggregation without any centralized infrastructure.
Why Multi-Party Signing?
A btcr2 beacon transaction commits to a batch of DID updates. If multiple controllers contribute to the batch, they all need to authorize the transaction. A simple approach would be to have a trusted coordinator hold the signing key — but that introduces a single point of failure and a custody risk.
MuSig2 solves this: all participants jointly produce a single Schnorr signature without any party ever holding the complete private key. The resulting signature is indistinguishable from a solo Schnorr signature on the blockchain — observers can't tell whether one party or a thousand signed the transaction.
MuSig2 Protocol Overview
MuSig2 is a two-round multi-signature scheme for Schnorr signatures:
Setup Phase
- Each participant generates a secp256k1 key pair
- All participants share their public keys
- An aggregate public key is computed — this becomes the Pay-to-Taproot address for the beacon transaction
Round 1: Nonce Commitment
- Each participant generates two random nonces (the "two-round" in MuSig2's name comes from this — earlier MuSig variants required three rounds)
- Public nonce pairs are shared with all participants
- Each participant combines all nonce pairs to compute the aggregate nonce
Round 2: Partial Signing
- The beacon transaction (containing the update batch commitment) is constructed
- Each participant computes a partial signature using their private key and the aggregate nonce
- Partial signatures are shared with the coordinator
- The coordinator aggregates all partial signatures into the final Schnorr signature
Broadcast
The completed transaction — with its single aggregated signature — is broadcast to the Bitcoin network. It's a standard Pay-to-Taproot spend.
Security Properties
- No trusted dealer — No party ever constructs or holds the full signing key
- Accountability — If a participant produces an invalid partial signature, it's detectable
- Unforgeability — An adversary controlling up to n-1 of n participants can't forge a valid signature
- Privacy — The on-chain signature reveals nothing about the number of participants or the signing protocol
The Coordination Problem
MuSig2 requires participants to exchange messages in two rounds. This raises a practical question: how do participants find each other and communicate?
Centralized options (a web server, a message queue) work but create dependencies that undermine the decentralization btcr2 aims for. Fully peer-to-peer options (direct connections) have NAT traversal and discovery problems.
Enter Nostr
Nostr's relay architecture is a natural fit:
- Decentralized — Messages are published to multiple relays. No single relay is a point of failure.
- Key-based identity — Nostr uses the same secp256k1 keys as btcr2 and Bitcoin. Participants already have the key material they need.
- Asynchronous — Participants don't need to be online simultaneously. They publish messages to relays and retrieve them when ready.
- Censorship-resistant — If one relay refuses to carry coordination messages, others will.
The Nostr Adapter
btcr2's reference implementation defines a pluggable communication interface. The Nostr adapter implements this interface:
Cohort Formation
- A coordinator publishes a beacon round announcement to designated Nostr relays
- Participants who want to include an update in this round respond with their public key and update commitment
- The coordinator collects responses until the cohort is full or a deadline passes
Nonce Exchange
- The coordinator signals the start of Round 1
- Each participant publishes their nonce pair as a Nostr event
- Participants subscribe to the coordination channel and collect all nonce pairs
- Once all nonces are received, Round 2 begins
Partial Signature Collection
- The coordinator publishes the transaction to be signed
- Each participant computes and publishes their partial signature
- The coordinator collects all partial signatures, aggregates, and broadcasts the Bitcoin transaction
Message Format
Coordination messages are standard Nostr events with specific kinds (event types) for each protocol step. The content is encrypted to the cohort — only participants with the right keys can read the coordination messages.
Pluggable Communication
While Nostr is the implemented adapter, btcr2's architecture defines a generic communication interface. A DIDComm adapter is also defined in the specification, enabling coordination over the DID-native messaging protocol. Organizations that prefer to coordinate over their own infrastructure can implement a custom adapter without changing the MuSig2 protocol logic.
Failure Handling
Distributed protocols need to handle participants going offline:
- Timeout escalation — If a participant doesn't respond within the round timeout, the coordinator can either extend the deadline or proceed without them (restarting with a smaller cohort).
- Fallback to Singleton — Any participant who can't complete the aggregation round can fall back to a Singleton beacon for their update. Aggregation is an optimization, not a requirement.
- Coordinator rotation — If the coordinator goes offline, a new coordinator can pick up the cohort (participants' public nonces are already published to Nostr relays).
Conclusion
MuSig2 over Nostr gives btcr2 decentralized, privacy-preserving beacon aggregation without introducing trusted infrastructure. The cryptographic protocol ensures no party can forge the collective signature. The Nostr transport ensures coordination happens without centralized servers. And the pluggable architecture means the communication layer can be swapped without touching the signing logic. It's aggregation that matches the decentralization principles of both Bitcoin and the DID ecosystem.