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

Apr 24, 2026

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

Introduction

did:btcr2's design wasn't possible before November 14, 2021. That's when Bitcoin activated Taproot at block 709,632 — the first consensus change since SegWit in 2017. Taproot bundled three BIPs: BIP-340 (Schnorr signatures), BIP-341 (P2TR outputs and script trees), and BIP-342 (Tapscript), with BIP-350 (Bech32m) providing the address encoding. Each of these upgrades directly shaped btcr2's architecture in ways that go beyond surface-level adoption.

Schnorr Signatures (BIP340)

What Changed

Before Taproot, Bitcoin used ECDSA signatures exclusively. Schnorr signatures offer several properties that matter deeply for a DID method:

Linearity — Schnorr signatures are linearly composable. Multiple parties can produce partial signatures that combine into a single valid signature indistinguishable from a solo signature. This is the mathematical foundation of MuSig2 (BIP-327), which btcr2 can use for multi-party beacon aggregation — the spec outlines a canonical recommended example that pairs MuSig2 with nostr as the communications channel between cohort participants.

Simplicity — BIP-340 Schnorr signatures operate on 32-byte x-only public keys (dropping the parity byte from SEC-compressed keys). The signature scheme is cleaner and has a simpler security proof than ECDSA.

Batch verification — Multiple Schnorr signatures can be verified in a batch more efficiently than verifying each individually. For a DID resolver replaying a history of update operations, this translates to faster resolution.

How btcr2 Uses Them

btcr2 signs DID updates with a Schnorr secp256k1 Data Integrity cryptosuite — the bip340-jcs-2025 variant — built on BIP-340 Schnorr signatures. A companion bip340-rdfc-2025 variant exists for RDF Dataset Canonicalization. Every DID update proof uses the same signature scheme as Bitcoin itself, so there's no second cryptographic system bolted alongside Bitcoin's.

The signing process follows the standard W3C Data Integrity pattern:

  1. Canonicalize the document using JSON Canonicalization Scheme (RFC 8785)
  2. SHA-256 hash the transformed document and the proof configuration separately, then SHA-256 hash their concatenation to produce the signing input
  3. Sign that hash with BIP-340 Schnorr using the controller's secp256k1 private key
  4. Emit a W3C Data Integrity Proof whose proofPurpose is capabilityInvocation and whose capability is a ZCAP-LD root URN (urn:zcap:root:...) derived from the DID

The cryptosuite is published as a public draft specification with a test-vector suite, and is referenced normatively from the did:btcr2 update algorithm — so it's available to any DID method or verifiable credential system that wants BIP-340 signing, not just btcr2.

MuSig2 Multi-Signatures

Why It Matters for DIDs

btcr2's beacon aggregation model needs multiple DID controllers to collaborate on a single Bitcoin transaction. MuSig2 (BIP-327) — a two-round Schnorr multi-signature scheme — makes this possible:

  1. Cohort formation — Controllers who want to update their DIDs join a cohort for the next beacon transaction.
  2. Nonce exchange (round 1) — Each participant generates and shares a public nonce.
  3. Partial signing (round 2) — Each participant produces a partial signature. The coordinator aggregates them into a single Schnorr signature.
  4. Broadcast — The resulting transaction has a single signature that's indistinguishable from a solo Schnorr signature.

Without Schnorr's linearity property, this kind of aggregation would require more complex (and less private) multi-signature schemes. MuSig2 outputs a single aggregated Schnorr signature, which only became spendable on Bitcoin after Taproot activated Schnorr at the consensus layer — which is what lets the P2TR beacon transaction carry it in a single witness.

Pay-to-Taproot Beacon Addresses

Taproot (BIP-341) introduces a new output type — Pay-to-Taproot (P2TR) — that commits to a key-spend path and an optional script tree. btcr2 leverages P2TR for Aggregate Beacon addresses: the Aggregation Service constructs an n-of-n P2TR address where each participant contributes one key, and spending is done via the MuSig2-aggregated key-spend path.

If the cohort fails — a participant drops offline, or the Aggregation Service is compromised — the spec's guidance is not to fall back to a script path on the same address. Instead, DID documents SHOULD list at least one Singleton Beacon as a separate service, so the controller can still broadcast updates unilaterally when aggregation breaks down.

The privacy benefit is significant: a MuSig2 key-path P2TR spend is indistinguishable on-chain from any other Taproot key-path spend. Observers can't tell whether a transaction is a simple payment or a DID beacon carrying updates for many controllers.

Bech32m Encoding

Taproot introduced Bech32m (BIP-350) as the encoding for SegWit v1+ addresses, replacing the original Bech32 encoding used for v0 (which had a specific insertion-error weakness identified after deployment).

btcr2 adopted Bech32m for DID identifiers — not just because it was new, but because the properties are ideal:

  • Error detection guarantees that protect against typos in identifiers
  • Lowercase alphanumeric character set that's URL-safe and QR-code friendly
  • Shared tooling with the Bitcoin ecosystem — any library that encodes Taproot addresses can encode btcr2 DIDs

The human-readable prefix differentiates DID identifiers (k for key-based, x for external) from Bitcoin addresses (bc for mainnet, tb for testnet), while the underlying encoding machinery is identical.

The Timeline Connection

The design lineage is clear:

btcr2 couldn't have existed in its current form before both of these events. The original BTCR was designed for a pre-Taproot Bitcoin — ECDSA only, no Schnorr aggregation, no Bech32m. The v2 redesign was a deliberate response to new capabilities.

Conclusion

btcr2 is a DID Method that runs on Bitcoin and is shaped by its evolution. Schnorr signatures enable the cryptosuite. MuSig2 for multi-party aggregation. Taproot enables private, efficient beacon transactions. Bech32m provides the identifier encoding. Many of the major design decisions borrow a primitive from Bitcoin's own protocol evolution making it feel like it speaks Bitcoin's language.

Jintek LLC