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 (BIP-327) 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 output for the beacon transaction
Round 1: Nonce Commitment
- Each participant generates two random nonces. This two-nonce technique is what lets MuSig2 finish in two communication rounds, where the original MuSig needed three
- 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 key-path 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 is detectable through partial signature verification, which lets honest parties identify the disruptive signer
- Unforgeability: Under the AOMDL assumption, an adversary controlling up to n-1 of n participants cannot forge a valid signature (BIP-327)
- Privacy: The MuSig2 key-path output is indistinguishable to a blockchain observer from an ordinary single-signer Taproot output, so the number of participants is not exposed on chain
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 (NIP-01) 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
- The coordinator collects each participant's nonce contribution, computes the aggregate nonce, and sends it back to all participants
- Once participants receive the aggregate nonce, 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 carried as Nostr events: plaintext kind-1 events for the cohort-formation phase (the advertisement plus opt-in, accept, and ready messages), and NIP-44 encrypted directed events for the update and signing phases, each with an application-level message type identifying the protocol step. Because NIP-44 encrypts per recipient, the update- and signing-phase directed messages are readable only by their intended recipient, while the entire cohort-formation phase (advertisement, opt-in, accept, and ready) is sent in plaintext.
Pluggable Communication
The reference implementation ships two production transports behind a common interface: a Nostr transport and an HTTP/REST transport. A DIDComm adapter is also defined but currently only as a stub (aggregation docs), with the goal of 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 failure: If the coordinator (the Aggregation Service) goes offline or is compromised, the round simply fails: the aggregate beacon does not broadcast, and participants retry under a new round or fall back to a Singleton beacon. There is no automatic handoff to a replacement coordinator, and because each MuSig2 nonce must be used only once, any retry starts a fresh nonce exchange rather than reusing prior nonce material.
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.