Shamir backup

The mathematics comes from Adi Shamir's 1979 paper on sharing a secret, and the bitcoin implementation is SLIP-39, published by SatoshiLabs. A two-of-three configuration produces three lists of 20 words, any two of which restore the wallet, while any one on its own reveals nothing. It answers theft and loss with the same backup, which a single phrase cannot.

How it works

Threshold sharing is not encryption and not chopping a phrase into pieces. The secret is treated as a point on a polynomial of degree one less than the threshold, and each share is another point on that curve. Two points define a straight line, three define a parabola, and so on, so gathering the threshold number of shares reconstructs the curve and reads off the original value. Below the threshold there is no partial information at all: with one share of a two-of-three, every possible secret remains exactly as likely as before, which is a stronger guarantee than "computationally hard".

SLIP-39 wraps that idea in a format designed for handwriting. Its wordlist holds 1,024 words rather than BIP-39's 2,048, each between four and eight letters and uniquely identified by its first four. A share is 20 words for a 128-bit master secret and 33 words for a 256-bit one, with each word carrying 10 bits, plus identifier, threshold, and checksum data so a wallet knows which group a share belongs to. The scheme supports two levels: up to 16 groups, each holding up to 16 shares, with a threshold on the groups as well as within them.

Two limits decide whether it suits you. Reconstruction happens on one device at one moment, so that device and that moment are a single point of compromise no matter how carefully the shares were distributed. And SLIP-39 is not interchangeable with BIP-39: an existing 12 or 24 word phrase cannot be converted into shares, and shares cannot be typed into a wallet that only understands mnemonics.

Where you see it

Trezor shipped Shamir backup on the Model T in firmware 2.1.3 in August 2019, added multi-group "super Shamir" in 2.1.6 that October, and its current Safe devices carry the feature forward. Support elsewhere is thin, which is the strongest practical argument against it: your backup restores on one vendor's hardware or through the open-source python-shamir-mnemonic reference implementation, and nowhere else. Anyone planning a decade-long backup should weigh that against BIP-39, which every wallet reads.

The setups where it earns its place are geographic and social. Shares in three cities survive a house fire without any single location being sufficient for a burglar. A three-of-five spread among family members and a lawyer gives an estate a workable route without handing anyone unilateral control while you are alive. Both cases need the recovery drill rehearsed at least once, because a threshold scheme fails quietly: you only discover a corrupted share when you are trying to use it.

If you like the shape of the idea but want broader tool support, codex32 is the other option worth knowing. Specified as BIP-93, it defines a share format whose checksum can be verified by hand on paper, with no computer involved.

Shamir backup vs multisig

Shamir splits one secret; multisig uses several genuinely independent keys. That single difference drives everything else. Shamir shares must be brought together on one machine to spend, so an attacker who catches that moment gets everything, whereas multisig signatures are produced on separate devices and the keys never meet. Multisig is visible on the chain, costs more in transaction fees, and needs its wallet descriptor backed up alongside the seeds. Shamir is invisible to everyone, costs nothing extra to spend, and adds no on-chain complexity. For inheritance and fire protection, Shamir is simpler. For guarding against a compromised device or a single dishonest participant, multisig is the one that actually helps.