Thank you for your input Ignacio. Looking at your proposal, I see that
its main feature is that it makes one of the shares privileged in the
sense that it must always take part in the reconstruction of the master
secret, while the remaining shares follow the K-of-M scheme. This is an
interesting idea.

To answer your questions:

> Your proposed work provides a way to split the pre-secret into SSS
> shares, a format of encoding the shares, and finally several methods
> to derive the master secret from the pre-secret. Would you envision
> standarizing these different topics under the same proposal?
We intend standardize the encoding format, splitting of the pre-master
secret into shares and the derivation of the master secret from the
pre-master secret in a single document. However, note that only one of
the four proposed master secret derivation functions will be selected
for the final version.

> Also, have you thought of a way to deal with the existing legacy
> privatekeys already encoded into BIP-0039, or stored in other formats,
> and how to migrate them securely into a schema of encoded SSS shares?
Three of the four proposed master secret derivation functions are
symmetric, which means that they allow users to migrate any existing
master secret (including a BIP-0039 mnemonic) to the new scheme.

Thanks,
Andrew Kozlik


On 24.9.2018 21:49, Ignacio Berrozpe wrote:
> Hi Andrew
>
> Please allow me to comment on your work, as I happened to publish an
> article 5 months ago proposing SSS to split bitcoins private keys into
> shares that could be encoded directly using BIP-0039 mnemonic words.
> While cryptographically much simpler than your proposal, the proposal
> had the characteristic that it could be applied directly to existing
> private keys backups, by splitting the keys into SSS shares that could
> benefit from the existing BIP-0039 mnemonic to encode directly the
> shares. I thought it would be a simple path for hardware wallets
> providers such as Trezor into providing a better/more secure
> alternative the existing BIP-0039 privatekey backups of 24 words.
>
> The article can be found here, and I've enclosed a simplified version
>
> https://privatekeys.org/2018/04/24/k-of-m-private-key-generation-and-backup-in-bitcoin-wallets/
>
> Mind two questions? Your proposed work provides a way to split the
> pre-secret into SSS shares, a format of encoding the shares, and
> finally several methods to derive the master secret from the
> pre-secret. Would you envision standarizing these different topics
> under the same proposal? Also, have you thought of a way to deal with
> the existing legacy privatekeys already encoded into BIP-0039, or
> stored in other formats, and how to migrate them securely into a
> schema of encoded SSS shares?
>
> Best regards
> Ignacio Berrozpe
>
>
>
>
>
>
>
> On Fri, Sep 21, 2018 at 8:18 PM Andrew Kozlik via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org
> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>
>     Hello everyone,
>
>     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:
>     https://github.com/satoshilabs/slips/blob/master/slip-0039.md
>     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.
>
>     Thanks,
>
>     Andrew Kozlik
>     TREZOR Team
>
>
>     _______________________________________________
>     bitcoin-dev mailing list
>     bitcoin-dev@lists.linuxfoundation.org
>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>