BIP-84 derivation

BIP-84 reuses the five level layout of BIP-44 and changes only the purpose value. It was assigned on 28 December 2017 and pairs each account with a zpub extended key whose version bytes are 0x04b24746. For you it decides whether a restored seed finds your bc1q balance or reports an empty wallet.

How it works

BIP-84 does two things, and the first is to pin one number inside a path. Keys hang off the skeleton BIP-44 introduced, written m / purpose' / coin_type' / account' / change / address_index, and the only level this specification claims as its own is the purpose, fixed at 84'. Coin type, account, change and address index keep the meanings BIP-44 and BIP-49 already gave them, and the author, Pavol Rusnak, explicitly reuses BIP-49's rationale rather than restating it.

The second thing is the output format. BIP-84 borrows the encapsulation from BIP-141: the scriptPubKey is 0x0014 followed by the 20 byte hash of the public key, the scriptSig is left empty, and the witness carries the signature and then the key. Nothing in that output records which purpose value produced it.

Extended keys on the branch get their own version bytes. Public keys use 0x04b24746, which prints as zpub, private keys use 0x04b2430c for zprv, and testnet uses 0x045f1cf6 and 0x045f18bc for vpub and vprv. Those values are not unique to bitcoin. SLIP-0132, the registry that collects them, lists Groestlcoin and Syscoin under the identical 0x04b24746, because the serialization format carries no field for the coin type, so a zpub tells you the script type and nothing about the chain it belongs to.

The specification calls itself "not backwards compatible by design" and says an incompatible wallet "will not discover accounts at all". That is deliberate. A separate purpose value keeps software written before SegWit out of an account it would handle badly, and a balance that reads zero is a better failure than a wallet that half restores in silence.

Where you see it

BIP-84 shows up in three places your wallet already displays: the account path m/84'/0'/0', an extended key beginning zpub, and receive addresses beginning bc1q. SLIP-0132 pairs that zpub row for bitcoin with the path m/84'/0', which is the pairing an app asserts when it hands you one. Sparrow, rated 4.7 in our review, supports single signature and multisig wallets across the common script types, so the account you open is the one you picked rather than a default you inherited.

The part of the document worth borrowing is its test vector block, which turns "does this wallet implement BIP-84 the way everyone else does" into a check that takes a minute. The BIP publishes results for the mnemonic "abandon" repeated eleven times and then "about":

• m/84'/0'/0'/0/0 gives bc1qcr8te4kr609gcawutmrza0j4xv80jy8z306fyu
• m/84'/0'/0'/0/1 gives bc1qnjg0jd8228aq7egyzacy8cys3knf9xvrerkf9g
• m/84'/0'/0'/1/0 gives bc1q8c6fshw2dlwun7ekn9qwf37cu2rn755upcp6el

Load that phrase into unfamiliar software on a machine that holds no coins, choose native SegWit, and compare the first receiving address and the first change address against those strings. Matching both means the implementation agrees with the standard on the change branch too, which is the half people forget to check. Never send anything to those addresses: the BIP prints the matching private keys and SLIP-0132 prints the same mnemonic, so anyone who reads either document can spend what lands there.

BIP-84 derivation vs P2WPKH

BIP-84 derivation says where a key came from, and P2WPKH says how the coins are locked. Only the second is consensus. A wallet could derive a key down a path with no 84' anywhere in it, lock the output with the same 0x0014 pattern, and the resulting bc1q address would be indistinguishable from yours on chain. So "a BIP-84 address" is shorthand rather than a claim any explorer can settle, and the purpose value is something you record in a backup note, because you cannot read it back off the blockchain later.