BIP-86 (Taproot Derivation)

What Is BIP-86?

BIP-86 is a Bitcoin Improvement Proposal authored by Ava Chow (achow101) that specifies how HD wallets should derive keys for Taproot (P2TR) outputs. Just as BIP-84 defined the derivation path for native SegWit (P2WPKH) addresses starting with bc1q, BIP-86 defines the path for Taproot addresses starting with bc1p. It uses purpose field 86 in the BIP-32 hierarchical deterministic key tree, yielding the full path: m/86'/0'/0'/change/index.

The proposal focuses specifically on single-key spending: the simplest and most common type of Bitcoin transaction. Rather than exposing complex script trees, BIP-86 creates outputs that commit to an unspendable script path, meaning the only way to spend is via the key path with a single Schnorr signature. This makes everyday transfers smaller, cheaper, and more private than any previous address format.

How It Works

BIP-86 builds on the same multi-account hierarchy that Bitcoin wallets have used since BIP-44, but targets Taproot's SegWit version 1 output type. The derivation path follows this structure:

m / 86' / coin_type' / account' / change / address_index

Examples:
m/86'/0'/0'/0/0   First receiving address (mainnet)
m/86'/0'/0'/0/1   Second receiving address
m/86'/0'/0'/1/0   First change address
m/86'/1'/0'/0/0   First receiving address (testnet)

The purpose field 86' (hardened) follows the BIP-43 convention where the number matches the BIP number. The remaining levels are identical to BIP-44: coin type distinguishes mainnet from testnet, account allows logical separation, change separates receiving from internal addresses, and index increments sequentially.

The Internal Key Tweak

The core cryptographic step that distinguishes BIP-86 from earlier standards is the Taproot key tweak. After deriving a key from the BIP-32 tree, BIP-86 does not use it directly as the output key. Instead, it applies a deterministic tweak defined by BIP-341:

1. Take the derived public key and convert it to an x-only 32-byte internal key (selecting the point with even y-coordinate)
2. Compute the tweak scalar using a tagged hash: t = HashTapTweak(internal_key)
3. Add the tweak to the internal key: output_key = internal_key + t * G

// Taproot output key computation (BIP-341)
internal_key = lift_x(derived_key)
t = int(HashTapTweak(bytes(internal_key)))
output_key = internal_key + t * G

// For spending, the private key is tweaked:
tweaked_privkey = (privkey + t) mod n

The HashTapTweak function uses a tagged SHA-256 hash with domain separation, preventing cross-protocol attacks. Because BIP-86 creates key-path-only outputs, no Merkle root is appended to the hash input: the tweak commits only to the internal key itself. This means the script path is effectively unspendable: no script tree exists to reveal.

The Nothing-Up-My-Sleeve Point

BIP-341 defines a special point H for use when creating outputs that should have only a script path and no key-path spend. This point is constructed by hashing the uncompressed encoding of the secp256k1 generator point G:

H = lift_x(SHA256(uncompressed_G))
H = lift_x(0x50929b74c1a04954b78b4b6035e97a5e...)

Because nobody knows the discrete logarithm of H (the private key h such that h * G = H), outputs using H as the internal key cannot be spent via the key path. BIP-86 takes the opposite approach: it uses the user's actual derived key as the internal key, making the key path spendable and the script path unspendable. This distinction is important because BIP-86 optimizes for the common case where a single owner simply wants to send and receive bitcoin.

Address Encoding

The tweaked output key is encoded as a P2TR scriptPubKey and serialized into a Bech32m address:

// scriptPubKey format
OP_1 <32-byte output_key>
(hex: 5120<output_key>)

// Example BIP-86 address (from test vectors)
bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr

Bech32m (not Bech32, which is used for v0 SegWit) encodes these addresses with the bc1p prefix on mainnet. Every BIP-86 address is exactly 62 characters long.

BIP-86 vs. Earlier Derivation Standards

Each derivation standard corresponds to a different Bitcoin address type and spending mechanism:

BIP-86 is the only standard that uses Schnorr signatures instead of ECDSA. A single-signature Taproot transaction is roughly 10 to 15 percent smaller than an equivalent native SegWit transaction, reducing fees for the sender and consuming less block space overall.

Why It Matters

BIP-86 is not just a technical detail for wallet developers: it represents the direction Bitcoin address standards are heading. Several factors make it significant for anyone building on or using Bitcoin:

• Privacy by default: all P2TR outputs look identical on chain, whether they protect a single key, a threshold signature, or a complex script. Chain analysis cannot distinguish BIP-86 outputs from more complex Taproot outputs.
• Lower fees: Schnorr key-path spends produce the smallest single-sig witness data, reducing transaction weight and the fees users pay.
• Forward compatibility: Taproot's script tree structure supports future upgrades via new leaf versions without requiring additional soft forks.
• Ecosystem convergence: Bitcoin Core uses BIP-86 as the default derivation since version 23.0. As wallets, exchanges, and Layer 2 protocols adopt Taproot natively, BIP-86 becomes the common language for address generation.

For Layer 2 systems like Spark, Taproot adoption on Layer 1 is foundational. Taproot's key aggregation capabilities (via protocols like MuSig2) enable cooperative transactions that look like ordinary single-sig spends on chain, improving both privacy and efficiency for off-chain protocols.

Use Cases

Standard Wallet Operations

The primary use case for BIP-86 is everyday Bitcoin transactions: receiving, holding, and sending. Wallets that generate bc1p addresses via the m/86' path give users the privacy and efficiency benefits of Taproot without any additional complexity. The user experience is identical to earlier address types, but every transaction costs less and reveals less information.

Wallet Recovery and Interoperability

Because BIP-86 follows the standardized BIP-44 hierarchy, any wallet that implements the specification can recover funds from a seed phrase alone. If a user creates a BIP-86 wallet in Sparrow and later imports the same seed into Bitcoin Core, both wallets derive the same addresses. This interoperability depends on wallets scanning the m/86' path during recovery, which is now standard practice across major implementations.

Foundation for Advanced Protocols

While BIP-86 itself handles only single-key spending, it establishes the Taproot derivation conventions that more complex protocols build on. PSBTs for Taproot use BIP-371 fields that reference BIP-86 derivation paths. Miniscript policies compiled into Taproot script trees coexist with BIP-86 key-path outputs in the same wallet. Multisig setups using FROST threshold signatures can aggregate keys into a single internal key that follows the same tweak process.

Wallet Support

BIP-86 support has reached broad adoption across the Bitcoin wallet ecosystem:

• Desktop: Bitcoin Core (default since v23.0), Sparrow Wallet, and Electrum (since v4.1.0) all support BIP-86 derivation
• Hardware: Ledger (Nano S Plus, Nano X, Stax), Trezor (Model T, Safe 3), Coldcard (Mk4, Q), and BitBox02 all generate and sign for P2TR outputs
• Mobile: BlueWallet (since v6.2.0), Muun, and several other wallets generate Taproot addresses by default for new users

Some exchanges still do not support withdrawals to bc1p addresses, though adoption continues to grow. Users should verify exchange compatibility before setting BIP-86 as their default receiving address type.

Risks and Considerations

Compatibility Gaps

BIP-86 is intentionally not backward compatible with earlier derivation standards. A wallet that only scans m/44', m/49', and m/84' paths will not discover BIP-86 accounts. This is by design: it alerts users that their wallet does not support Taproot rather than silently hiding funds. However, it means users must verify that their recovery tools support BIP-86 before relying on it exclusively.

Key Reuse and Privacy

Like all Bitcoin address types, reusing BIP-86 addresses degrades privacy. Taproot's privacy benefits depend on the address gap limit being respected and fresh addresses being generated for each transaction. Wallets should implement the standard derivation path gap limit scanning to balance privacy with recoverability.

Quantum Computing Considerations

Key-path spending exposes the public key on chain when the output is spent. A sufficiently powerful quantum computer running Shor's algorithm could theoretically derive the private key from the public key. This threat applies to all exposed public keys (including P2PKH outputs that have been spent from), but Taproot makes key-path spending the default. BIP-360 has been proposed as a quantum-resistant alternative that removes the key-path spend entirely, though practical quantum threats remain distant.

Extended Key Format

Unlike BIP-49 (ypub/yprv) and BIP-84 (zpub/zprv), BIP-86 does not define a unique extended key prefix. It reuses the standard xpub/xprv format, which means an extended public key alone does not indicate whether it belongs to a BIP-44 or BIP-86 account. Wallet software must track the derivation path metadata separately, typically via output descriptors.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.