BIP-86 derivation

BIP-86 covers wallets holding Taproot outputs for a single signer, reusing the BIP-44 account layout with 86' at the purpose level. BIP-49 and BIP-84 also define a second address step, but only BIP-86 changes the key itself: the 32-byte value in your address is the key you derived, tweaked by a hash of itself. Restore your words into software that scans only BIP-84 and your bc1p balance reads zero.

How it works

BIP-86 derivation happens in two steps, and only the first is the familiar walk down a key tree.

Step one is the path. The template is m / purpose' / coin_type' / account' / change / address_index, with 86' in the purpose slot and every level below it used unchanged, so a first bitcoin account sits at m/86'/0'/0' and its first receiving key at m/86'/0'/0'/0/0.

Step two is where BIP-86 parts company with its predecessors. BIP-49 and BIP-84 define a second step too, but theirs wraps the derived key in a script and the witness still reveals the key the path produced. BIP-86 replaces the key. It quotes BIP-341 on the rule it has to satisfy: "If the spending conditions do not require a script path, the output key should commit to an unspendable script path instead of having no script path." So the derived key is read as an internal key through lift_x, and what reaches the chain is that internal key plus int(HashTapTweak(bytes(internal_key)))G. The result is a single 32-byte push behind OP_1, written 0x5120 followed by the tweaked key, and spending it needs only a signature in the witness with an empty scriptSig.

The published test vectors show the gap. At m/86'/0'/0'/0/0 the internal key derived from the seed is cc8a4bc64d897bddc5fbc2f670f7a8ba0b386779106cf1223c6fc5d7cd6fc115, while the key the network sees is a60869f0dbcf1dc659c9cecbaf8050135ea9e8cdc487053f1dc6880949dc684c, encoded as bc1p5cyxnuxmeuwuvkwfem96lqzszd02n6xdcjrs20cac6yqjjwudpxqkedrcr. An implementation that skips step two publishes the first value instead, so it hands you plausible looking addresses that a conforming wallet restoring the same seed will never find.

Ava Chow wrote the document, which was assigned on 22 June 2021 and now carries the status Deployed.

Where you see it

BIP-86 derivation sits behind most single signature wallets that hand you a bc1p address without asking which format you want. Bitcoin Core made descriptor wallets the default in version 23.0, and the release notes for that version say a newly created descriptor wallet contains an automatically generated tr() descriptor "which allows for creating single key Taproot receiving addresses".

Hardware caught up at very different speeds. Our KeepKey review dates that device's Taproot output support to firmware 7.10.0 in February 2025, so a cheap signer can hold a seed whose 86' branch it will not show you, while other software reading the same words spends those coins normally.

The specification is unusually candid about why a fixed path is still needed. Its motivation section grants that "there are now solutions which obviate the need for fixed derivation paths for specific script types", meaning descriptors, then names why they do not settle it: many software wallets and hardware signers still back up a seed alone, with no record of the path or script type beside it. A descriptor carries that information; a word list does not, so the number 86 carries it instead.

BIP-86 derivation vs P2TR

BIP-86 derivation is one recipe for filling a P2TR output, not the definition of one. P2TR is witness version 1 and accepts any 32-byte output key at all, including a key aggregated from several signers under MuSig2 and a key committing to a tree of genuinely usable scripts. BIP-86 covers the narrowest case in that space: one signer, one seed, and a script path deliberately left unspendable so nothing hides behind the key. Every address BIP-86 produces is a P2TR output, and most of what P2TR can express is outside its scope entirely, so a wallet that advertises Taproot support may still refuse a multisig or timelocked branch wearing the same address format.