From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XI16b-0006bp-RF for bitcoin-development@lists.sourceforge.net; Thu, 14 Aug 2014 19:54:37 +0000 X-ACL-Warn: Received: from mail-qg0-f43.google.com ([209.85.192.43]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XI16Z-0004Ai-TL for bitcoin-development@lists.sourceforge.net; Thu, 14 Aug 2014 19:54:37 +0000 Received: by mail-qg0-f43.google.com with SMTP id a108so1456561qge.2 for ; Thu, 14 Aug 2014 12:54:30 -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:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=iYSEBenMBryHgHinzo7EMEaDe+nKvoAEEy23QJa1kow=; b=jLxGGnzy6Q145dccLDW5r7CJUZhcEVr0m7kSLyUa1v9ZvPFluCZA0SWCIdZyUZLUB1 /UhENauvYr08NCA7w+18RYynC7l4OT058GJKi73nbaB9v/RqMGGaXjrzwfUxK4feQn3s wsi6FmH/hsC0zg1/ByDcpeOUw220FIVZp+PRiMVjA2p8VWC2c6lpXwBaiYIUMQmF4rdj 8lK9bCjwmHcBncH9pGPXdWfHnAy3FU83BqM1fr5lETakYoqiFwVvtCgj4vqnGHv6sTgn z0x57ePKU5CFYvpHZzoJh2RzQ7IUuynJBdkM5rlyItEHPuqbFOCcFmB39J/LmYmw/k3r qUAg== X-Gm-Message-State: ALoCoQm5QFKWu1aTJYgQNHhjm3rJUlhui0jukWaEPqgLxHEHyOOt3CFycxPiVzihzgn5QIMAP0/n X-Received: by 10.140.108.200 with SMTP id j66mr19618681qgf.43.1408044216288; Thu, 14 Aug 2014 12:23:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.222.99 with HTTP; Thu, 14 Aug 2014 12:23:16 -0700 (PDT) X-Originating-IP: [93.109.172.210] In-Reply-To: References: <1927948.OEZHQcsQ9n@crushinator> <2025496.b5Y3n7qx8B@crushinator> <1582E990-4E14-4EF7-9C9C-AA505B815104@bitsofproof.com> <53568B87.8040009@monetize.io> <11528A13-5D66-4D2B-BEE0-1C26F9987BC8@bitsofproof.com> <621AAD7D-FDC0-4C3C-B810-8C1F0B088586@bitsofproof.com> From: Nikita Schmidt Date: Thu, 14 Aug 2014 22:23:16 +0300 Message-ID: To: =?UTF-8?Q?Jan_M=C3=B8ller?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: 1XI16Z-0004Ai-TL Cc: Bitcoin Dev 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, 14 Aug 2014 19:54:37 -0000 On 12 May 2014 15:09, Jan M=C3=B8ller wrote: > > I think having 3 encoding formats (long/short/compact) is over engineered= , > and basically only makes implementing the standard a pain in the rear. Fr= om > a user experience point of view only the long format makes sense, and it = is > only a few bytes longer than the short version. > True. Since nobody has objected, the draft has been reworked and is much leaner now: https://github.com/cetuscetus/btctool/blob/bip/bip-xxxx.mediawiki . The reasons for not making M and checksum fields optional are added to the Rationale section. The main difference is that the shared secret can be in encoded form, e.g. SIPA or BIP38 instead of a plain private key. This makes SSS a general purpose container for any kind of secret data. The benefits are: - no need to change the spec to carry another type of content; - testnet and altcoins do not need any treatment in this spec; - content-specific metadata, such as compressed/uncompressed, encrypted/non-encrypted, key inception time point etc., are encoded together with the secret, rather than provided for separately and individually in this spec. As we are now dealing with secrets of arbitrary length, GF(256) as the underlying field becomes much more advantageous than GF(large prime). An inconvenience of variable length is that we have no control of the Base58 prefix. This was solved by moving the magic prefix outside of the Base58 encoded content: SSS-abcdefgh. 'SSS-' acts as the application identifier both to humans and machines, and abcdefgh is the Base58 encoding of the share without any application/magic bytes. (This may seem mildly controversial, but is there a better way?)