Subject: Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

From: Matt Whitlock <[email-masked]>
Date: Sat, 29 Mar 2014 13:19:29 -0400

On Saturday, 29 March 2014, at 12:59 pm, Alan Reiner wrote:
> I won't lie, there's a lot of work that goes into making an interface
> that makes this feature "usable."  The user needs clear ways to identify
> which fragments are associated with which wallet, and which fragments
> are compatible with each other.

The same is true of the multiple private keys involved in a multi-signature addresses.

> They need a way to save some fragments
> to file, print them, or simply write them down.

I proposed a share encoding scheme for exactly this purpose.

> They need a way to
> re-enter fragment, reject duplicates, identify errors, etc.  Without it,
> the math fails silently, and you end up restoring a different wallet.

I intentionally omitted the parameter M (minimum subset size) from the shares because including it would give an adversary a vital piece of information. Likewise, including any kind of information that would allow a determination of whether the secret has been correctly reconstituted would give an adversary too much information. Failing silently when given incorrect shares or an insufficient number of shares is intentional.

> Also I put the secret in the highest-order coefficient of the
> polynomial,

Does it make any difference which coefficient holds the secret? It's convenient to put it in the lowest-order coefficient to simply the recovery code.

> and made sure that the other coefficients were
> deterministic.  This meant that if print out an M-of-N wallet, I can
> later print out an M-of-(N+1) wallet and the first N fragments will be
> the same.  I'm not sure how many users would trust this, but we felt it
> was important in case a user needs to export some fragments, even if
> they don't increase N.

My BIP likewise deterministically chooses the coefficients so that the shares of a secret are consistent across all runs of the algorithm having the same M. As I'm sure you're aware, N (the number of shares to output) plays no part in the calculation and merely controls how many times the outermost loop is executed. My BIP doesn't even mention this parameter.