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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WcW58-00037m-Al for bitcoin-development@lists.sourceforge.net; Tue, 22 Apr 2014 08:29:34 +0000 X-ACL-Warn: Received: from qmta07.westchester.pa.mail.comcast.net ([76.96.62.64]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WcW56-0006lK-L6 for bitcoin-development@lists.sourceforge.net; Tue, 22 Apr 2014 08:29:34 +0000 Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta07.westchester.pa.mail.comcast.net with comcast id swUi1n0011ei1Bg57wVTFr; Tue, 22 Apr 2014 08:29:27 +0000 Received: from crushinator.localnet ([IPv6:2601:6:4800:47f:219:d1ff:fe75:dc2f]) by omta24.westchester.pa.mail.comcast.net with comcast id swVS1n00T4VnV2P3kwVTd0; Tue, 22 Apr 2014 08:29:27 +0000 From: Matt Whitlock To: jan.moller@gmail.com Date: Tue, 22 Apr 2014 04:29:26 -0400 Message-ID: <2336265.urqHVhRi8n@crushinator> User-Agent: KMail/4.13 (Linux/3.12.13-gentoo; KDE/4.13.0; x86_64; ; ) In-Reply-To: References: <1927948.OEZHQcsQ9n@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.64 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: 1WcW56-0006lK-L6 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 08:29:34 -0000 On Tuesday, 22 April 2014, at 10:27 am, Jan M=F8ller wrote: > > > - Please allow M=3D1. From a usability point of view it makes se= nse 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 is > > functionally equivalent to dispensing with the secret sharing schem= e > > 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 cou= ld be > reasons for just having one piece of paper to manage. If M can be 1 t= hen > the software/hardware doesn't have to support multiple formats, > import/export paths + UI (one for SIPA keys in one share, one for HD= seeds > in one share, one for SIPA keys + HD seeds in multiple shares). >=20 > Less complexity & more freedom of choice. Alright. It's a fair argument. Do you agree with encoding M using a bia= s of -1 so that M up to and including 256 can be encoded in one byte?