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-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WVpPE-0004zd-T7 for bitcoin-development@lists.sourceforge.net; Thu, 03 Apr 2014 21:42:40 +0000 X-ACL-Warn: Received: from qmta04.westchester.pa.mail.comcast.net ([76.96.62.40]) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WVpPD-0004M9-6v for bitcoin-development@lists.sourceforge.net; Thu, 03 Apr 2014 21:42:40 +0000 Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta04.westchester.pa.mail.comcast.net with comcast id lUcb1n0050SCNGk54ZiZ51; Thu, 03 Apr 2014 21:42:33 +0000 Received: from crushinator.localnet ([IPv6:2601:6:4800:47f:219:d1ff:fe75:dc2f]) by omta09.westchester.pa.mail.comcast.net with comcast id lZiY1n00x4VnV2P3VZiZlZ; Thu, 03 Apr 2014 21:42:33 +0000 From: Matt Whitlock To: bitcoin-development@lists.sourceforge.net Date: Thu, 03 Apr 2014 17:42:32 -0400 Message-ID: <3837746.jqWvB0Uxrs@crushinator> User-Agent: KMail/4.12.4 (Linux/3.12.13-gentoo; KDE/4.12.4; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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.40 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: 1WVpPD-0004M9-6v 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: Thu, 03 Apr 2014 21:42:41 -0000 On Thursday, 3 April 2014, at 4:41 pm, Nikita Schmidt wrote: > I agree with the recently mentioned suggestion to make non-essential > metadata, namely key fingerprint and degree (M), optional. Their > 4-byte and 1-byte fields can be added individually at an > implementation's discretion. During decoding, the total length will > determine which fields are included. The fingerprint field, Hash16(K), is presently specified as a 16-bit fi= eld. Rationale: There is no need to consume 4 bytes just to allow share= s to be grouped together. And if someone has more than 100 different se= crets, they probably have a good system for managing their shares and w= on't need the hash anyway. > Encoding for the testnet is not specified. Hmm, is that actually needed? > Speaking of encoding, is it not wasteful to allocate three different > application/version bytes just for the sake of always starting with > 'SS'? It would be OK if it were accepted as a BIP, but merely as a > de-facto standard it should aim at minimising future chances of > collision. I agree on principle, however I think the more user-acceptable behavior= is for all base58-encoded Shamir shares to begin with a common prefix,= such as "SS". Users are accustomed to relying on the prefix of the bas= e58 encoding to understand what the object is: "1" for mainnet pubkey h= ash, "3" for mainnet script hash, "5" for uncompressed private key, "P"= for passphrase-protected private key, etc. > I'd add a clause allowing the use of random coefficients instead of > deterministic, as long as the implementation guarantees to never make= > another set of shares for the same private key or master seed. I'm not sure that's necessary, as this is an Informational BIP. Impleme= ntations are free to ignore it. Shares with randomly selected coefficie= nts would work just fine in a share joiner that conforms to the BIP, so= I would expect implementors to feel free to ignore the deterministic f= ormula and use randomly selected coefficients. > What about using the same P256 prime as for the elliptic curve? Just= > for consistency's sake. The initial draft of this BIP used the cyclic order (n) of the generato= r point on the secp256k1 elliptic curve as the modulus. The change to t= he present scheme was actually done for consistency's sake, so all size= s of secret can use a consistently defined modulus. > Also, I'm somewhat inclined towards using the actual x instead of j i= n > the encoding. I find it more direct and straightforward to encode th= e > pair (x, y). And x=3D0 can denote a special case for future extensio= ns. > There is no technical reason behind this, it's just for (subjective)= > clarity and consistency. There is a technical reason for encoding j rather than x[j]: it allows = for the first 256 shares to be encoded, rather than only the first 255 = shares. If you want a sentinel value reserved for future extensions, then you m= ight take notice that 0xFFFF is an invalid key fingerprint, along with = several other values, and also that 0xFF is an unusable value of M=E2=88= =922, as that would imply M=3D257, but the scheme can only encode up to= 256 shares, so one would never have enough shares to meet the threshol= d. I considered having the two optional fields be mandatory and allowin= g 0xFFFF and 0xFF as "redacted" field values, but I like allowing the s= hares to be shorter if the optional fields are omitted. (Imagine engrav= ing Shamir secret shares onto metal bars by hand with an engraving tool= . Fewer characters is better!)