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 1WVhKO-0000di-AJ for bitcoin-development@lists.sourceforge.net; Thu, 03 Apr 2014 13:05:08 +0000 X-ACL-Warn: Received: from mail-qc0-f177.google.com ([209.85.216.177]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WVhKM-000579-Un for bitcoin-development@lists.sourceforge.net; Thu, 03 Apr 2014 13:05:08 +0000 Received: by mail-qc0-f177.google.com with SMTP id w7so1777737qcr.36 for ; Thu, 03 Apr 2014 06:05:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=ADhiWIz8M6CglOiVPMBmC5qpRL5/SfVni4eSPU9hjN0=; b=JweJQAGSZU1LZKwUQDwXz+dpMAM488RSmk3XYzp0QCJwNqcUz5clr63TqhuYQ8kdMM M7FEuf3S+TMGBakWX55Cg5UMvoS/cMXV0mJ4GwKsdSoK0cT45dq/JUzh246bf8Zmrs2U BmRdSP429Y8oBIvgPd8bNCUgiGHNMtGNtWAJ4SKLAMoiKDcrW5n5RVZmjf5b3U/lndjh WlCfRRF92r7mE+c/grVpWDnd1A/+CRcLLLqH8hoXH/0U8rMzxaGo52RwRtl5dDkto/A7 aR6VXiSW+j9iSYwhRfWO4bAbdwSEUtdxXVTiKlissxRJj5WWFNvNC+Ru31q5kpKGtyGz +KvA== X-Gm-Message-State: ALoCoQnJtC7egW8IukEgmUs/lZdxpBBdDNZvrIsGShoZBDv1TCLGgWdVNKN7LG/tjUqRxCeSCUPU X-Received: by 10.140.80.209 with SMTP id c75mr6572216qgd.79.1396528886902; Thu, 03 Apr 2014 05:41:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.124.10 with HTTP; Thu, 3 Apr 2014 05:41:06 -0700 (PDT) X-Originating-IP: [2001:770:14a:0:60cb:febe:c82d:73bc] From: Nikita Schmidt Date: Thu, 3 Apr 2014 16:41:06 +0400 Message-ID: To: bitcoin-development@lists.sourceforge.net 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. X-Headers-End: 1WVhKM-000579-Un 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 13:05:08 -0000 Matt Whitlock wrote: > Okay, you've convinced me. However, it looks like the consensus here is > that my BIP is unneeded, so I'm not sure it would be worth the effort > for me to improve it with your suggestions. I need your BIP. We are going to implement SSS and we'd rather stick with something publicly discussed, even if it has not formally become a BIP, than invent our own stuff. I'll go ahead and comment on the current proposal here. BIP or no BIP, I propose to finalise this spec anyway for those who want to implement SSS now or in future. 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. For example, as a compromise between usability and security, the metadata can be supplied out-of-band, like in plain text accompanying the Base-58 encoded share. Encoding for the testnet is not specified. 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'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. What about using the same P256 prime as for the elliptic curve? Just for consistency's sake. Also, I'm somewhat inclined towards using the actual x instead of j in the encoding. I find it more direct and straightforward to encode the pair (x, y). And x=0 can denote a special case for future extensions. There is no technical reason behind this, it's just for (subjective) clarity and consistency.