From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WTwuu-0003qG-5O for bitcoin-development@lists.sourceforge.net; Sat, 29 Mar 2014 17:19:36 +0000 X-ACL-Warn: Received: from qmta01.westchester.pa.mail.comcast.net ([76.96.62.16]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WTwut-0005x1-3m for bitcoin-development@lists.sourceforge.net; Sat, 29 Mar 2014 17:19:36 +0000 Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta01.westchester.pa.mail.comcast.net with comcast id jUQS1n0021swQuc51VKVNR; Sat, 29 Mar 2014 17:19:29 +0000 Received: from crushinator.localnet ([IPv6:2601:6:4800:47f:219:d1ff:fe75:dc2f]) by omta15.westchester.pa.mail.comcast.net with comcast id jVKV1n0074VnV2P3bVKV1z; Sat, 29 Mar 2014 17:19:29 +0000 From: Matt Whitlock To: Alan Reiner 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: <4906130.DUyjhm1C93@crushinator> <5336FBE7.7030209@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [76.96.62.16 listed in list.dnswl.org] 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1WTwut-0005x1-3m Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Mar 2014 17:19:36 -0000 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.