Introducing did:btcr2 — A Second-Generation Bitcoin DID Method

Introduction

The original did:btcr method, born out of the Rebooting the Web of Trust community in 2017, proved that Bitcoin could serve as a Verifiable Data Registry for decentralized identifiers. It worked — but it had limitations that became clear as the DID ecosystem matured and Bitcoin itself evolved. did:btcr2 is a ground-up redesign that addresses those limitations while taking full advantage of Bitcoin protocol upgrades like Taproot and Schnorr signatures.

Why a Second Generation?

The original BTCR method tied a DID directly to a Bitcoin UTXO. This had several consequences:

Every DID creation required an on-chain transaction — Even creating an identifier cost Bitcoin transaction fees. For mass adoption, this is a non-starter.
Identifiers were unstable — Because the DID was coupled to a specific UTXO, every update changed the anchor point. Long-lived identifiers required resolvers to follow a chain of UTXO updates.
DID documents were publicly exposed — The original method stored or referenced DID document data on-chain, making every identity publicly discoverable and correlatable.
No aggregation — Each DID operation required its own Bitcoin transaction. There was no mechanism to batch updates from multiple controllers into a single transaction.

These aren't minor inconveniences — they're structural barriers to building practical identity systems.

What did:btcr2 Changes

Zero-Cost Off-Chain Creation

A btcr2 identifier is derived from either a secp256k1 public key or a genesis document hash. Creation happens entirely offline — no Bitcoin transaction required. You generate a key pair, encode the public key using Bech32m (the same encoding Bitcoin uses for Taproot addresses), and you have a globally unique, cryptographically verifiable DID.

The identifier format uses a human-readable prefix: k for key-based DIDs and x for external/document-based DIDs. The encoded payload includes the Bitcoin network, spec version, and 32-33 bytes of genesis material.

Long-Term Stable Identifiers

Unlike the original BTCR, btcr2 identifiers are permanent. They're derived from genesis bytes that never change. Updates are announced through beacon services — they don't alter the identifier itself. This means a DID created today will have the same identifier decades from now, regardless of how many times the DID document is updated.

Private DID Documents

btcr2 introduces "sidecar delivery" — the DID document and its update history are communicated privately between parties rather than published to any external storage. This is a key distinction from federated identity models where a central provider mediates every interaction. For key-based DIDs, the initial document is deterministically generated from the DID itself — the controller only needs to share their DID string. For document-based DIDs, the controller provides the genesis document. In either case, if updates have been made, the controller provides those as a list of plain JSON objects. On-chain data is limited to opaque hashes. Resolution can happen in a "closed loop" where only parties who possess the sidecar data can resolve the DID. This enables pairwise, non-correlatable identities by default.

Beacon-Based Aggregation

Instead of one transaction per DID operation, btcr2 uses a three-tier beacon system:

Singleton Beacon — One update per transaction, directly from the controller. The simplest path, embedding an update hash in an OP_RETURN output.
CAS Beacon (Content Addressable Storage) — Aggregates multiple updates into a single on-chain commitment, with the announcement map stored in content-addressable storage.
SMT Beacon (Sparse Merkle Tree) — Maximum privacy aggregation where even the beacon operator doesn't learn the controller's DID or update content.

This architecture means the cost of a DID update can be shared across hundreds or thousands of participants.

Bitcoin-Native Cryptography

btcr2 uses BIP 340 Schnorr signatures — the same signature scheme activated with Bitcoin's Taproot upgrade. The project developed a custom W3C Data Integrity cryptosuite (bip340-jcs-2025) for signing and verifying DID documents using Bitcoin-native cryptography. Updates are expressed as JSON Patch (RFC 6902) operations with cryptographic binding, and multi-party beacon coordination uses MuSig2 (BIP 327) for n-of-n Schnorr multi-signatures.

Immutable History and Security

Every btcr2 DID has a single canonical history anchored to Bitcoin. The resolution process replays operations chronologically, validating each against the key hierarchy. Late-publishing attacks — where an adversary tries to insert operations after the fact — are explicitly detected and rejected. This gives btcr2 DIDs the same immutability guarantees as Bitcoin transactions themselves.

Current Status

The btcr2 specification is under active development with contributions from Digital Contract Design, Jintek LLC, Legendary Requirements, and BlipJoy LLC in the RWOT community. A comprehensive TypeScript reference implementation is available as an open-source monorepo covering the core method, cryptosuite, key management, Bitcoin connectivity, and CLI tooling. The core path — create, resolve, and update via Singleton beacon — is fully functional, with CAS and SMT beacons in progress.

Conclusion

did:btcr2 addresses the practical limitations that held back the original BTCR — expensive creation, unstable identifiers, public documents, and no aggregation. The result is a Bitcoin-anchored DID method that's significantly more viable for real-world use. Whether Bitcoin is the right anchor for a given identity system depends on the use case, but for those who want its properties, btcr2 makes them accessible without the original method's costs. The design is grounded in Bitcoin's own protocol evolution, and the implementation is being built in the open.