From: Matt Whitlock <bip@mattwhitlock.name>
To: Alan Reiner <etotheipi@gmail.com>
Date: Sat, 29 Mar 2014 13:19:29 -0400
Message-ID: <15872432.k8h0hUxqlf@crushinator>
User-Agent: KMail/4.12.3 (Linux/3.12.13-gentoo; KDE/4.12.3; x86_64; ; )
In-Reply-To: <5336FBE7.7030209@gmail.com>
References: <CACsn0ckScTWG4YxNCscxvtdsmcUkxtR2Gi-rdBs2HCkirPz5rA@mail.gmail.com>
	<4906130.DUyjhm1C93@crushinator> <5336FBE7.7030209@gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret
	Sharing of Bitcoin private keys
Precedence: list

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.