From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WcWmg-00070Y-GU for bitcoin-development@lists.sourceforge.net; Tue, 22 Apr 2014 09:14:34 +0000 X-ACL-Warn: Received: from qmta03.westchester.pa.mail.comcast.net ([76.96.62.32]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WcWlM-0002X3-0F for bitcoin-development@lists.sourceforge.net; Tue, 22 Apr 2014 09:14:34 +0000 Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id sxD21n0010cZkys53xD2Nj; Tue, 22 Apr 2014 09:13:02 +0000 Received: from crushinator.localnet ([IPv6:2601:6:4800:47f:219:d1ff:fe75:dc2f]) by omta10.westchester.pa.mail.comcast.net with comcast id sxD11n00S4VnV2P3WxD2Al; Tue, 22 Apr 2014 09:13:02 +0000 From: Matt Whitlock To: jan.moller@gmail.com Date: Tue, 22 Apr 2014 05:13:01 -0400 Message-ID: <9644584.QTKx69qfup@crushinator> User-Agent: KMail/4.13 (Linux/3.12.13-gentoo; KDE/4.13.0; x86_64; ; ) In-Reply-To: References: <2336265.urqHVhRi8n@crushinator> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" 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.32 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: 1WcWlM-0002X3-0F Cc: bitcoin-development 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: Tue, 22 Apr 2014 09:14:34 -0000 On Tuesday, 22 April 2014, at 10:39 am, Jan M=F8ller wrote: > On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock wrote: > > On Tuesday, 22 April 2014, at 10:27 am, Jan M=F8ller wrote: > > > > > - Please allow M=3D1. From a usability point of view it make= s sense to allow > > > > > the user to select 1 share if that is what he wants. > > > > > > > > How does that make sense? Decomposing a key/seed into 1 share i= s > > > > functionally equivalent to dispensing with the secret sharing s= cheme > > > > entirely. > > > > > > > I agree that it may look silly to have just one-of-one share from= a > > > technical point of view, but from an end-user point of view there= could be > > > reasons for just having one piece of paper to manage. If M can be= 1 then > > > the software/hardware doesn't have to support multiple formats, > > > import/export paths + UI (one for SIPA keys in one share, one fo= r HD seeds > > > in one share, one for SIPA keys + HD seeds in multiple shares). > > > > > > Less complexity & more freedom of choice. > > > > Alright. It's a fair argument. Do you agree with encoding M using a= bias > > of -1 so that M up to and including 256 can be encoded in one byte?= >=20 > Necessary Shares =3D M+1, not a problem >=20 > I would probably encode N-of-M in 1 byte as I don't see good use case= s with > more than 17 shares. Anyway, I am fine with it as it is. Encoding bias of M changed to -1, and test vectors updated: https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki