SLIP-39 to specyfikacja SatoshiLabs interoperacyjnych udziałów słownych opartych na Shamir's Secret Sharing. Standaryzuje podział, metadane, kontrolę błędów i passphrase; udziały nie są zamienne z frazą BIP 39.
W kopii portfela BIP 32 głównym sekretem jest jego wejściowy seed, nie rozszerzony prywatny korzeń. Najpierw powstaje encrypted master secret (EMS), potem jego udziały. Obliczenia przebiegają bajt po bajcie w GF(256); specyfikacja umieszcza sekret w f(255), a przy progu co najmniej 2 skrót weryfikacyjny w f(254). [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes] [BIP 32 — Hierarchical Deterministic Wallets]
Najpierw trzeba spełnić próg członków każdej potrzebnej grupy, potem próg grup. Przykład: 2 z 3 grup, każda 2 z 3 członków. Dwa udziały z A i dwa z B wystarczą; trzy z A i jeden z B nie, mimo że też są cztery. Prosty schemat 2 z 3 korzysta z jednej grupy. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes]
Słownik ma 1024 angielskie słowa i nie jest tłumaczony razem z interfejsem. Sekret 128-bitowy daje udziały po 20 słów, 256-bitowy po 33. Udział zawiera też identyfikator, flagę extendable, wykładnik iteracji, indeksy i progi. Łączenie sprawdza zgodność metadanych i unikalność indeksów członków; dwie kopie jednego udziału nie są dwoma członkami. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes]
Ostatnie trzy słowa tworzą RS1024, gwarantujący wykrycie błędów dotyczących najwyżej trzech słów. Nie potwierdzają pochodzenia ani uprawnień posiadacza; specyfikacja odradza automatyczną korektę. Skrót rekonstrukcji pomaga wykryć błędny zestaw. Jego 32-bitowa kontrola oznacza, że idealnej tezy o zerowym wycieku poniżej progu nie należy bez zastrzeżeń odnosić do SLIP-39. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes]
Szyfrowanie stosuje cztery rundy Feistel z PBKDF2-HMAC-SHA256, po 2500×2^e iteracji. Specyfikacja dopuszcza drukowalne ASCII 32–126 i pusty ciąg bez passphrase. Poprawnej passphrase nie można bezpośrednio zweryfikować: inna daje inny główny sekret. Poprawne udziały nie potwierdzają więc właściwego portfela; sprawdź jego znane adresy. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes]
BIP 39 ma inny słownik, sumę kontrolną i przekształcenie frazy w seed. Rozdzielenie słów na kartki nie tworzy SLIP-39 ani jego ochrony progowej. Zachowanie portfela podczas migracji wymagałoby właściwego BIP 32 seed i kontekstu wyprowadzania; samo przekodowanie pierwotnej entropii na inne słowa tego nie gwarantuje. Sprawdź konkretną obsługiwaną procedurę. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes] [BIP 39 — Mnemonic code for generating deterministic keys]
Flaga extendable równa 1 pomija identyfikator w soli szyfrowania. Pozwala ponownie podzielić ten sam EMS z nowym identyfikatorem bez znajomości passphrase. Trezor opisuje rozszerzenie zgodnej kopii z jednego udziału na wiele. Nowy zestaw nie unieważnia starego: wystarczająca pierwotna kombinacja nadal odtworzy ten sam sekret. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes] [Trezor — Multi-share Backup]
SLIP-39 składa podczas odtwarzania jeden sekret; nie tworzy Multisig ani zatwierdzania każdej transakcji on-chain. Rozmieszczenie musi ograniczać wspólną utratę i zdobycie wystarczającej kombinacji przez napastnika. Przetestuj odtworzenie na zaufanym urządzeniu, zachowaj passphrase i kontekst portfela, sprawdź zgodność implementacją referencyjną i wektorami testowymi. Sama liczba udziałów nie wystarcza. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes] [Trezor — python-shamir-mnemonic reference implementation]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Shamir Secret Sharing, BIP 39, Trezor, Multisig, HD Wallet. Do tego hasła prowadzą również odsyłacze z BIP 39, Pavol “Stick” Rusnák, Shamir Secret Sharing.