SLIP-39

Anna chooses a two-of-three backup. A wallet is an application or device for receiving and sending bitcoin. The wallet creates three different shares, and any two allow recovery; that minimum number is the threshold. Two photographs of the same share still count as only one share. A simple arrangement uses one group. SLIP-39 also supports more complex rules: for example, 2 of 3 groups, with 2 of 3 shares required in each. Two shares from group A and two from B suffice. Three from A and one from B do not, because only group A is complete. The distribution matters, not just the number of papers. [1] [6]

Each list carries different data along with the information needed to combine it correctly. SLIP-39 uses a fixed list of 1024 English words; backup words are not translated even when the wallet interface is. A 128-bit secret produces 20-word shares; a 256-bit secret produces 33-word shares. A bit is a basic unit of data, not another word to write down. A share also identifies its set, group and position, the required thresholds and the encryption settings. Recovery checks that these agree and that shares are distinct. Arbitrary lists of the same length cannot simply be mixed. [1]

Anna may also use a passphrase, an additional password of her own. Enough shares cannot replace it, and the correct combination cannot itself recognize a typing mistake: a different passphrase produces a different master secret and thus a different wallet. Compare the result with known addresses, rather than relying only on a valid-backup message. Without a passphrase, the input is empty. SLIP-39 permits printable ASCII characters 32–126: basic Latin characters without accents, including a space. That is a rule of this standard, not of every wallet. The passphrase is not the PIN that unlocks the device. [1]

A BIP 39 Seed Phrase is produced differently and uses another wordlist. Dividing its words between pieces of paper does not turn them into SLIP-39 shares. To preserve the same wallet, conversion would have to preserve the seed, the secret input to the BIP 32 tree of keys, and the correct Derivation Path leading to the keys in use. Re-encoding the original entropy—the random data before the words were created—is insufficient. BIP 39 derives a 512-bit seed from the words and passphrase; backing that seed up directly with SLIP-39 produces 59-word shares. Converting one wallet does not automatically carry over other wallets accessed with different passphrases. Check the specific supported procedure beforehand. [1] [3] [2]

A compatible backup with the extendable flag can change its sharing arrangement while preserving the same wallets. Trezor describes moving from a single-share backup to multiple shares this way. But changing the papers has not changed Anna’s secret: a sufficient old combination still works. Old and new shares must not be mixed. Technically, a flag value of 1 excludes the set identifier from the auxiliary encryption input called a salt. The same encrypted master secret (EMS) can then be shared again with a new identifier without knowing the passphrase. This does not repair the exposure of an old usable backup. [1] [4]

A private key is a secret numerical value that a wallet uses to create a digital signature authorizing a spend. Once Anna restores her wallet, it can sign in the usual way. Share holders need not approve each payment: SLIP-39 recovers one secret, whereas Multisig requires multiple signatures under the spending conditions. One fire can destroy three shares kept in the same apartment. Distribution should make both simultaneous loss and an attacker gathering enough shares harder; a more complex arrangement also makes recovery more demanding. Use a supported recovery check on a trusted device. The reference library python-shamir-mnemonic is for developers to check compatibility with public test examples, not to process your real backup. It explicitly warns that it does not adequately protect secrets. [1] [4] [5] [6]

For a BIP 32 wallet, the master secret is the input seed, not the already derived extended private root of the key tree. The seed is encrypted first; only the resulting EMS is split. Encryption uses four rounds of a Feistel construction, each containing PBKDF2-HMAC-SHA256 with 2500×2^e iterations, where the stored exponent e sets the computational cost. This is precisely defined password processing, not the addition of random words. Splitting works byte by byte in GF(256), a mathematical setting with 256 values. The polynomial stores the secret at f(255); when the threshold is at least 2, f(254) holds a verification value called a digest. [1] [2]

A share’s last three words form the RS1024 checksum. It guarantees detection of errors affecting at most three words, but is neither the backup creator’s signature nor proof of ownership. The standard advises against automatic correction: software could produce valid but different words. During combination, another 32-bit digest helps detect a wrong set. It also has a theoretical consequence: someone with one share fewer than the threshold can eliminate some candidate secrets in an exhaustive search. The mathematical claim that absolutely no information leaks below the threshold therefore needs qualification. This does not mean an easy break; it explains why the standard requires a sufficiently strong original secret. [1]