# SLIP 39 https://github.com/satoshilabs/slips/blob/master/slip-0039.md - Is created by [[SatoshiLabs]] which is closely associated with [[Trezor]] - => The shortcomings of [[SLIP 39]] are [[Trezor]]'s own fault - Source: [[Shamir Secret Sharing#Trezor wallet implements Shamir Secret Sharing but it's based on SLIP 39]] - [[Rust]] implementation by Internet of People: https://github.com/Internet-of-People/slip39-rust - [[Rust]] implementation by Rust-Bitcoin: https://github.com/rust-bitcoin/rust-wallet/blob/master/src/sss.rs ![[Trezor#Detailed Guide to Shamir Backup]] ## "[[BIP39]] and [[SLIP 39]] generated wallets do not match" https://github.com/BlockchainCommons/lethekit/issues/38 #### Critical issue, do not use!!!! The LetheKit seedtool application generates new wallets using dice entropy to create BIP39 and SLIP39 recovery mnemonics. The BIP39 and SLIP39 mnemonics represent valid wallets, but they are not the same wallet. This is a serious problem. If both BIP39 and SLIP39 backups are created at the same time and funds are placed in the BIP39 wallet the SLIP39 backup will fail to recover the same wallet and the funds would be lost. ### Explanation by andrewkozlik@Github https://github.com/iancoleman/slip39/issues/1#issuecomment-563213494 - If you were to combine the SLIP-0039 shares and use the resulting master secret as the entropy for a BIP-0039 mnemonic, as you describe above, you would be getting a completely different wallet. The reason for this is that SLIP-0039 is not built on top of BIP-0039, but it's a separate scheme. Most notably, they each use a different function to generate the binary seed (aka master secret) from the input and passphrase. So I don't see this as being of interest to users. - Creating a tool for converting a BIP-0039 mnemonic to SLIP-0039 shares makes some sense for people who would like to migrate their existing seed to the new scheme and don't want to go through the process of transferring all their funds to a newly generated seed, migrating U2F credentials etc. - ==However, it is not as practical as it appears, because regardless of the length of the BIP-0039 mnemonic, each of the resulting SLIP-0039 shares will need to be 59 words long. This is due to the fact that in BIP-0039 the mnemonic and passphrase are processed by PBKDF2-SHA-512 to produce a 512 bit binary seed, and this is the master secret that would need to get split using SLIP-0039.== - ==Furthermore, if someone is using several different passphrases with one BIP-0039 mnemonic to have several wallets, they can only convert one of these to SLIP-0039 shares.== The opposite process of combining SLIP-0039 shares and outputting the corresponding BIP-0039 mnemonic is cryptographically infeasible, because PBKDF2-SHA-512 is a one-way function. ### Comment by [[Christopher Allen]] - My deal breaker here is that losing the ability to round trip from BIP39 <->seed<->shards means that wallets are locked in to supporting SLIP39 the way Satoshi Labs does it. - With our current sharding method (which will need to be changed to not confuse with SLIP39), you are not locked in to the Trezor — if a particular wallet does not support shards, you can convert the shards back into the seed, then back to BIP39 to the alternative wallet. - If the community consensus is that SLIP39 is broadly committed to and supported enough to compromize round trip, I'll reluctantly support it but I'll need to tell everyone in #SmartCustody that it risks vendor-lock-in until other major vendors support it. In the meantime, we'll focus on the binary QR and sharding approaches [https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-0005-ur.md](https://github.com/BlockchainCommons/Research/blob/master/papers/bcr-0005-ur.md)