BIP85

Anna keeps her master backup safe and wants a separate wallet for small payments. A wallet is an application or device for receiving and sending bitcoin. BIP85 can create another recovery phrase, which is all she imports into the phone. A private key is a secret numerical value that a wallet uses to create a digital signature authorizing a spend. Technically, the starting point is a BIP 32 extended private root, the beginning of a key tree. It may come from BIP 39 recovery words: those words and any passphrase first produce a seed, the secret input used to calculate the root. These names describe different stages, not interchangeable objects. BIP85 calculates new secret material from the root; it cannot work backwards to recover the original words. [1] [2] [3] [5]

Anna must also record the choices made during derivation. A Derivation Path writes out those steps precisely. The example m/83696968'/39'/0'/12'/0' selects BIP85, the BIP 39 application, the English wordlist, 12 words and index 0. Application here means a defined way of processing the result, not a particular phone app. Index 1 creates another child, meaning another derived phrase; it is not the number of a payment address inside the phone. The Czech wordlist has code 8', regardless of this page’s language. Changing the wordlist or word count changes the path and result. It does not translate the same recovery words. [1]

The intermediate material is called entropy: here, data calculated from a secret foundation that should be unpredictable without knowing that foundation. For 12 words, the first 128 output bits are used; for 24 words, the first 256 bits. BIP 39 adds a checksum, which helps detect some transcription errors, and converts the data into words. Those words then produce the new wallet’s seed and keys. BIP85 itself does not determine the address type, address path or how old payments are discovered. Nor can a longer result rescue an easily guessed starting secret: derivation adds no new independent randomness to it. [1] [3]

A passphrase is an optional additional secret used with BIP 39 recovery words. It is neither the device PIN nor the password that opens an app. If Anna used one with the master phrase, she also needs it to recover the same input root for BIP85. A different parent passphrase creates different children. A second, separate passphrase can be applied to the derived words in the phone wallet. It changes the destination wallet’s seed, not the words already created. BIP85 does not back up that destination passphrase. Recovering the words without it therefore does not recover the original wallet. [3] [4]

With a correct construction and a sufficiently strong starting secret, calculating the master root or other derived wallets’ secrets from one derived phrase is computationally infeasible. A leak of the phone’s words therefore does not by itself reveal the master backup. The reverse does work: anyone with the master private root and the necessary choices can reproduce its children. Any additional destination passphrase remains a separate secret. Losing the master foundation endangers children without their own usable backups. BIP85 therefore concentrates some responsibility in one place. It does not repair a compromised master root, and exporting a child does not secure an infected phone. [1] [4]

Every derivation step is hardened, meaning it requires the private part of the parent key. An xpub, an extended public key used to derive public keys, is not enough. The resulting private key k contains 32 bytes. BIP85 then processes it with HMAC-SHA512, a cryptographic calculation that accepts a message and a key. Here k is the message and the fixed text bip-entropy-from-k is the key; the output contains 64 bytes. Secrecy comes from the private input k, not that publicly known text. The transformation separates the resulting material from the derived key. It is not a recommendation to also use that intermediate key to sign payments. [1] [2]

The XPRV application can create a new extended private key. In the example m/83696968'/32'/0', the first 32 bytes form the chain code, extra data for further derivation, and the second 32 bytes form the private key. This reverses the order used when normally creating a BIP 32 root. If the resulting key number is invalid, the program must report an error and the user select the next index; it must not silently accept the value as a usable key. HEX represents data with hexadecimal characters, WIF is a private-key format, and other applications create passwords. Each has its own rules. Similar-looking strings do not prove equal content or compatibility. [1] [2]

COLDCARD documentation describes deriving and exporting BIP 39, WIF, XPRV and HEX. Supporting BIP85 does not mean every device version supports every application. Record the format, wordlist, length and index, along with which master wallet you started from; protect any passphrases as separate secrets. Before relying on the procedure, check that it reproduces the same child words and the destination wallet’s corresponding addresses. Public test vectors, known inputs with expected outputs, help check the software, not your private backup. BIP85 can simplify management, but the extra complexity is worthwhile only if you understand your own recovery procedure. [4] [1]