Thanks for your input Christopher. Since we already have the discussion
about your comments running under the issues in the SLIPs repo on Github
(, let's continue it there.

Andrew Kozlik

On 21.9.2018 21:29, Christopher Allen wrote:
> On Fri, Sep 21, 2018 at 11:18 AM Andrew Kozlik via bitcoin-dev
> <
> <>> wrote:
>     We are currently writing a new specification for splitting BIP-32
>     master
>     seeds 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.
> I and a number of companies & communities I am involved with are very
> interested in this. 
> A challenge is that Shamir Secret Sharing has subtleties. To quote
> Greg Maxwell:
> > 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”.
> Some questions for you:
> * What other teams or communities besides Trezor are committed to
> standardizing a Shamir Secret Sharing Scheme? I can say that the
> #RebootingWebOfTrust community (meeting again for the 7th time next
> week in Toronto are very interested.
> * Where do you want to hold discussions on this? Do people object to
> having this discussion on this mailing list? Or should it be issues in
> SLIPS repo or on some other mailing list? 
> * Presuming a successful split of secrets, I don’t know all the
> adversarial problems that are associated with recovery of a SSS. As
> this would be an interactive event, I presume an attacker can DOS a
> request to reassemble keys (so maybe some the of integrity of each
> share vs all is required). And of course there are the biggest
> problems:  impersonation of a reassembly request and a MitM of a
> reassembly request. Are there other attacks? Are you trying to
> mitigate any of these?
> Two comments:
> * The Lightning Network community has added to their BIP32 mnemonics
> the ability to have a birthday in the seed, to make it easier  to scan
> the blockchain for keys, as well as a byte with some way to know how
> to derive keys paths for it. I don’t seee a BOLT for this (it was
> mentioned
> in 
>  I would suggest that you also get some of their latest thoughts and
> incorporate them.
> * I worked with Chris Vickery while at Blockstrham on various possible
> ways to improve mnemonic word lists. I’m not suggesting that you
> necessarily go as far as we did to try to create a mnemonic that is
> iambic pentameter poetry (inspired by
> however, we did find sources for words that are concrete (for example
> table is more concrete than truth
> ) or have strong emotional valence attachment (truth is more emotional
> than table), both of which make can words more memorable. I also found
> lists of words that are hard to pronounce unless you are English
> native, and eliminated them from my own list. 
> Among the results of this was a new BIP-39 2048 word compatible word
> list filtered for memorability (concreteness & emotional valence) and
> suitability for iambic pentameter, which is located:
> …which was created from the repo at
> You can a number of other word lists that I’ve collected here
> If you want to replicate what we did with your own criteria, you may
> want to incorporate information from the CMU
> dictitionary, the top
> 5000
> words,
>  concrete word lists
> and emotional words  (valence)
> — Christopher Allen

bitcoin-dev mailing list

Reply via email to