From Taproot to DIDs: How Bitcoin Protocol Upgrades Shaped did:btcr2

Apr 24, 2026

From Taproot to DIDs: How Bitcoin Protocol Upgrades Shaped did:btcr2

Introduction

Several parts of the did:btcr2 design use features that came with the Taproot soft fork. Bitcoin activated Taproot at block 709,632, which miners found on 14 November 2021. The Taproot soft fork contained three BIPs (Bitcoin Core 0.21.1 release notes):

BIP 350 (Bech32m) gives the address encoding for the new outputs. Each of these upgrades had a direct effect on the design of btcr2.

Schnorr Signatures (BIP 340)

What Changed

Before Taproot, Bitcoin used only ECDSA signatures. BIP 340 lists several properties of Schnorr signatures that are important for a DID method:

Linearity: Several parties can make partial signatures that combine into one valid signature for the sum of their public keys. MuSig2 (BIP 327) uses this property, and btcr2 can use MuSig2 for multi-party beacon aggregation. The spec says that an Aggregation Service can advertise a cohort to possible participants with Nostr or DIDComm (Create Aggregation Cohort).

Compact keys and provable security: BIP 340 Schnorr signatures use 32-byte x-only public keys, without the parity byte of SEC-compressed keys. BIP 340 says that Schnorr signatures are provably secure, and that the best known security results for ECDSA need stronger assumptions. The did:btcr2 identifier still encodes the full 33-byte compressed key (Create).

Batch verification: A verifier can check many Schnorr signatures together faster than one at a time. In principle, a resolver can use this property for a long update history. The did:btcr2 spec does not require batch verification, and its resolver checks each proof before it applies the patch (Apply update).

How btcr2 Uses Schnorr Signatures

btcr2 signs DID updates with a Schnorr secp256k1 Data Integrity cryptosuite (the bip340-jcs-2025 variant) that uses BIP 340 Schnorr signatures. A companion bip340-rdfc-2025 variant uses RDF Dataset Canonicalization. Each DID update proof uses the Schnorr signature scheme that Bitcoin uses for Taproot. Thus, btcr2 does not add a second signature scheme next to the one that Bitcoin uses.

The signature process follows the standard W3C Data Integrity pattern:

  1. Canonicalize the document and the proof configuration with the JSON Canonicalization Scheme (RFC 8785).
  2. Hash the proof configuration and the document separately with SHA-256. Then hash their concatenation (the proof configuration hash first, then the document hash) with SHA-256. The result is the signature input.
  3. Sign that hash with BIP 340 Schnorr and the secp256k1 private key of the controller.
  4. Add a W3C Data Integrity Proof. Its proofPurpose is capabilityInvocation, and its capability is a ZCAP-LD root URN (urn:zcap:root:...) that contains the URL-encoded DID (Data Integrity Config).

As of September 2026, the cryptosuite spec is a draft (version 0.1) with a set of test vectors. The did:btcr2 update algorithm uses it (Construct BTCR2 Signed Update). Other DID methods and verifiable credential systems that want BIP 340 signatures can use it too.

MuSig2 Multi-Signatures

Why MuSig2 Is Important for DIDs

The beacon aggregation model of btcr2 needs many DID controllers to sign one Bitcoin transaction together. MuSig2 (BIP 327) is a two-round Schnorr multi-signature scheme that makes this possible. The spec gives this sequence as a RECOMMENDED example (Aggregate Beacons):

  1. Cohort formation: The Aggregation Service advertises a cohort, and each controller enrolls with a Schnorr public key. The Aggregation Service computes an n-of-n P2TR Beacon Address from the keys. Each participant adds this address to its DID document as a Beacon service.
  2. Nonce exchange (round 1): For each update opportunity, each participant sends an update response and a public MuSig2 nonce to the Aggregation Service. The Aggregation Service aggregates the nonces.
  3. Partial signatures (round 2): Each participant checks the unsigned Beacon Signal and returns a partial signature. The Aggregation Service aggregates the partial signatures into one Schnorr signature.
  4. Broadcast: The Aggregation Service broadcasts the transaction. Its signature looks the same as a single-signer Schnorr signature.

BIP 327 compares MuSig2 with an n-of-n policy that uses OP_CHECKSIGADD in Tapscript, where each signer gives an individual key and signature. The MuSig2 output is more compact, has a lower verification cost, and gives more privacy. Bitcoin consensus accepts BIP 340 signatures only in Taproot spends (BIP 341, BIP 342). Thus, one MuSig2 signature in the witness can spend the P2TR beacon output.

Pay-to-Taproot Beacon Addresses

Taproot (BIP 341) adds a new output type, Pay-to-Taproot (P2TR). A P2TR output commits to a key path and an optional script tree. btcr2 uses P2TR for Aggregate Beacon addresses. The Aggregation Service computes an n-of-n P2TR address, where each participant gives one key. The participants spend from the address through the key path with a MuSig2 aggregate signature.

The spec does not define a script-path fallback on the same address. If a participant stops, or if the Aggregation Service is compromised, the Aggregate Beacon does not broadcast Beacon Signals. For this case, the spec RECOMMENDS that each DID include at least one Singleton Beacon as a fallback. Thus, the controller can still broadcast updates alone if aggregation fails.

The spec gives MuSig2 only as a RECOMMENDED example, so an implementation can add other spend paths. The reference implementation adds a script tree to the aggregate beacon output (ADR 042). The tree has a k-of-n fallback leaf and a relative-timelock recovery leaf (recovery policy). The MuSig2 key path stays the normal spend path.

The key-path spend gives privacy. BIP 327 says that MuSig2 Taproot outputs are "indistinguishable for a blockchain observer from regular, single-signer Taproot outputs". Thus, an observer cannot tell from a key-path input if one party or many parties signed. A script-path spend shows the leaf that it uses. Each Beacon Signal also has a 32-byte OP_RETURN output (Signal Bytes). Observers can see that output, but they cannot read the updates or the DIDs from the 32 bytes alone.

Bech32m Encoding

Taproot outputs use Bech32m (BIP 350), the encoding for SegWit v1 and later addresses. SegWit v0 addresses still use the original Bech32 encoding. Bech32 has an unexpected insertion weakness. If the last character is p, you can insert or delete q characters before it, and the checksum stays valid. Bech32m removes this weakness.

btcr2 uses Bech32m for DID identifiers because of these properties:

  • Error detection: The checksum always detects up to 4 substituted characters (BIP 350). This helps protect against typos in identifiers.
  • A lowercase alphanumeric character set: The characters are safe in URLs. The did:btcr2 spec requires the lowercase form (Identifier Encoding). Thus, a QR code cannot use the compact uppercase form that BIP 173 allows for Bitcoin addresses.
  • Shared tools with the Bitcoin ecosystem: A library with a general Bech32m encoder can encode btcr2 DIDs. For example, the reference implementation uses the @scure/base library.

The human-readable prefix separates DID identifiers (k for key-based, x for external) from Bitcoin addresses (bc for mainnet, tb for testnet, per BIP 173). The encoding algorithm is the same for both.

The Timeline

The design history is:

The current btcr2 design depends on the first two events: it uses Taproot features, and it targets DID Core v1.1. The original BTCR design came before Taproot. It used ECDSA only, it had no Schnorr aggregation, and its TxRef identifiers used Bech32, not Bech32m. The second version was a deliberate response to the new capabilities.

Conclusion

btcr2 is a DID method that runs on Bitcoin, and the protocol changes of Bitcoin shaped it. Schnorr signatures are the base of the cryptosuite. MuSig2 gives multi-party aggregation. Taproot makes a multi-party key-path spend look like a single-signer spend. Bech32m gives the identifier encoding. Many of the main design decisions use a primitive from the protocol changes of Bitcoin, so btcr2 fits well with Bitcoin tools and conventions.

Jintek LLC