From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WW76c-0007dk-Su for bitcoin-development@lists.sourceforge.net; Fri, 04 Apr 2014 16:36:38 +0000 X-ACL-Warn: Received: from qmta13.westchester.pa.mail.comcast.net ([76.96.59.243]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WW76Z-0000zP-FK for bitcoin-development@lists.sourceforge.net; Fri, 04 Apr 2014 16:36:38 +0000 Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta13.westchester.pa.mail.comcast.net with comcast id ls241n0021HzFnQ5DscWvn; Fri, 04 Apr 2014 16:36:30 +0000 Received: from crushinator.localnet ([IPv6:2601:6:4800:47f:219:d1ff:fe75:dc2f]) by omta14.westchester.pa.mail.comcast.net with comcast id lscV1n00W4VnV2P3ascVGX; Fri, 04 Apr 2014 16:36:29 +0000 From: Matt Whitlock To: Gregory Maxwell Date: Fri, 04 Apr 2014 12:36:29 -0400 Message-ID: <1888881.3JyvKYNUFa@crushinator> User-Agent: KMail/4.12.4 (Linux/3.12.13-gentoo; KDE/4.12.4; x86_64; ; ) In-Reply-To: References: <12583269.b0SUbSGuCb@crushinator> 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.59.243 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: 1WW76Z-0000zP-FK 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: Fri, 04 Apr 2014 16:36:39 -0000 On Friday, 4 April 2014, at 9:25 am, Gregory Maxwell wrote: > On Fri, Apr 4, 2014 at 9:05 AM, Matt Whitlock wrote: > > On Friday, 4 April 2014, at 7:14 am, Gregory Maxwell wrote: > >> I still repeat my concern that any private key secret sharing scheme > >> really ought to be compatible with threshold ECDSA, otherwise we're > >> just going to have another redundant specification. > > > > I have that concern too, but then how can we support secrets of sizes other than 256 bits? A likely use case for this BIP (even more likely than using it to decompose Bitcoin private keys) is using it to decompose BIP32 master seeds, which can be 512 bits in size. We can't use secp256k1_n as the modulus there. > > Well, if you're not doing anything homorphic with the result the > computation should probably be over a small field (for computational > efficiency and implementation simplicity reasons) and the data split > up, this also makes it easier to deal with many different data sizes, > since the various sizes will more efficiently divide into the small > field. The field only needs to be large enough to handle the number > of distinct shares you wish to issue, so even an 8 bit field would > probably be adequate (and yields some very simple table based > implementations). Are you proposing to switch from prime fields to a binary field? Because if you're going to "break up" a secret into little pieces, you can't assume that every piece of the secret will be strictly less than some 8-bit prime modulus. And if you're going to do a base conversion, then you have to do arbitrary-precision integer math anyway, so I don't see that the small field really saves you any code. > If that route is taken, rather than encoding BIP32 master keys, it > would probably be prudent to encode the encryption optional version > https://bitcointalk.org/index.php?topic=258678.0 ... and if we're > talking about a new armored private key format then perhaps we should > be talking about Mark Friedenbach's error correcting capable scheme: > https://gist.github.com/maaku/8996338#file-bip-ecc32-mediawiki > (though it would be nicer if we could find a decoding scheme that > supported list decoding without increasing the complexity of a basic > implementation, since an advanced recovery tool could make good use of > a list decode) Weren't you just clamoring for implementation *simplicity* in your previous paragraph? :)