SLIP-0039 Specs Feedback: Shamir's Secret-Sharing for Mnemonic Codes

Andrew Kozlik, one of the developers from TREZOR Team, asked on bitcoin-dev for feedback regarding their work that went on specification SLIP-0039

We are currently writing a new specification for splitting BIP-32 master seeds bip into multiple mnemonics using Shamir’s secret sharing scheme. We would be interested in getting your feedback with regard to the high-level design of the new spec. Please focus your attention on the section entitled “Master secret derivation functions”, which proposes several different solutions. Note that there is a Design Rationale section at the very end of the document, which should answer some of the questions you may have. The document is a work in progress and we are aware that some technical details have not been fully specified. These will be completed once the high level design has been settled.

Christopher Allen noted that there seems to be interest in the idea but pointed out that Shamir’s Secret Sharing has a bit of controversies quoting Greg Maxwell comments on the topic:

I think Shamir Secret Sharing (and a number of other things, RNGs for example), suffer from a property where they are just complex enough that people are excited to implement them often for little good reason, and then they are complex enough (or have few enough reasons to invest significant time) they implement them poorly.

He also raised concerns regarding possible issues that may arise with recovery of SSS should Trezor successfully split secrets. For instance he said an attacker can launch a DOS attack by requesting the keys re-assembly. A bigger issue would be the impersonation of a re-assembly request and also a MitM of a re-assembly request for which he asked if there were measures in place to mitigate them.

Christopher further suggested that Trezor should incorporate the Lightning Network Community’s idea of adding to their BIP32 mnemonics the ability to include a “birthday”1 in the seed for easy scanning of the blockchain for keys, and a byte that enables keys paths derivation for it. An idea which according to prusnak is a “very small optimization for a standard that might be used 10-20+ years in the future”.

Christopher also suggested the result of his work with Chris Vickery on ways to improve mnemonics word lists in which they found sources for concrete and emotional words that could make mnemonics easier to memorize. The work also found a new BIP-39 2048 compatible word list more suitable for memorability and iambic pentameter and recommends a number of word lists he collected. Andrew’s argument is that the proposed scheme is to create long-term backups for the master secret which will be usually only needed if the hardware wallet is destroyed or the user wishes to migrate to a new one. As such, the main objective is not memorability but rather the ease of discerning and writing down the words without errors.


  1. BIP39 seeds have no way to tell you when they were created - when a wallet checks for transactions it would need to start at the genesis block all the way up to the present day. This is in contrast to the traditional BitcoinCore wallet.dat, which maintains a date for when the address was created (birthdate). Usually, it will not check for transactions for that address before that date (if the birthday is missing, it will check from genesis block).


Support us and the authors of this article by donating to the following address:


Comments powered by Talkyard.