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 <bip@mattwhitlock.name>) id 1WW6cp-00088k-Vv
	for bitcoin-development@lists.sourceforge.net;
	Fri, 04 Apr 2014 16:05:52 +0000
X-ACL-Warn: 
Received: from qmta05.westchester.pa.mail.comcast.net ([76.96.62.48])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1WW6co-00008F-7o for bitcoin-development@lists.sourceforge.net;
	Fri, 04 Apr 2014 16:05:51 +0000
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59])
	by qmta05.westchester.pa.mail.comcast.net with comcast
	id lrED1n0021GhbT855s5lM8; Fri, 04 Apr 2014 16:05:45 +0000
Received: from crushinator.localnet ([IPv6:2601:6:4800:47f:219:d1ff:fe75:dc2f])
	by omta07.westchester.pa.mail.comcast.net with comcast
	id ls5k1n00S4VnV2P3Ts5kJR; Fri, 04 Apr 2014 16:05:44 +0000
From: Matt Whitlock <bip@mattwhitlock.name>
To: Gregory Maxwell <gmaxwell@gmail.com>
Date: Fri, 04 Apr 2014 12:05:44 -0400
Message-ID: <12583269.b0SUbSGuCb@crushinator>
User-Agent: KMail/4.12.4 (Linux/3.12.13-gentoo; KDE/4.12.4; x86_64; ; )
In-Reply-To: <CAAS2fgQd6_DAPnYtXUKN8sL=MfrySBaRZWHfPtoKUw=p2=9OYA@mail.gmail.com>
References: <CAC7yFxSE8-TWPN-kuFiqdPKMDuprbiVJi7-z-ym+AUyA_f-xJw@mail.gmail.com>
	<CAC7yFxQXn=c7CEC326yMx4bF7Cv7Gc62shS7xU0XvSp5sQSGZw@mail.gmail.com>
	<CAAS2fgQd6_DAPnYtXUKN8sL=MfrySBaRZWHfPtoKUw=p2=9OYA@mail.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.48 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: 1WW6co-00008F-7o
Cc: bitcoin-development <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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 04 Apr 2014 16:05:52 -0000

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.