MIME-Version: 1.0
In-Reply-To: <CABh=4qMpge4q-CmKNNnxj5C_jGEFhwAVrUHSNbqy3njeUiSHvQ@mail.gmail.com>
References: <CAC7yFxSE8-TWPN-kuFiqdPKMDuprbiVJi7-z-ym+AUyA_f-xJw@mail.gmail.com>
	<CABh=4qNaJht-MnnjEguZ=UOuXN3uQ-s4-dkDUVErbHj6W44J_g@mail.gmail.com>
	<1927948.OEZHQcsQ9n@crushinator> <2025496.b5Y3n7qx8B@crushinator>
	<1582E990-4E14-4EF7-9C9C-AA505B815104@bitsofproof.com>
	<53568B87.8040009@monetize.io>
	<11528A13-5D66-4D2B-BEE0-1C26F9987BC8@bitsofproof.com>
	<CABh=4qPsR1YbhJDeAPjr37Zjqawo9ZFAH43scFnEg7p9a7EkeQ@mail.gmail.com>
	<F292CC2F-BAA7-45ED-801E-1475D94632AF@bitsofproof.com>
	<CAAS2fgR5ciUeFonOXBD1d9b_inOuxQKJ-LaoGmoyjoeQ_KxQxQ@mail.gmail.com>
	<621AAD7D-FDC0-4C3C-B810-8C1F0B088586@bitsofproof.com>
	<CAAS2fgTyndBG=airHoAcW4W2WgFZ61THXP4JGuUQCSWV99tCtg@mail.gmail.com>
	<CAC7yFxQR6oVdASacCefPiuWocvrDHTTnVU4xyVdZTwvMr4ZPNw@mail.gmail.com>
	<CABh=4qMpge4q-CmKNNnxj5C_jGEFhwAVrUHSNbqy3njeUiSHvQ@mail.gmail.com>
From: Nikita Schmidt <nikita@megiontechnologies.com>
Date: Thu, 14 Aug 2014 22:23:16 +0300
Message-ID: <CAC7yFxT+cXFJ4rG46q=HjCppV-J9SMJcPcEpSqyvHMEYJd_bbw@mail.gmail.com>
To: =?UTF-8?Q?Jan_M=C3=B8ller?= <jan.moller@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret
 Sharing of Bitcoin private keys
Precedence: list

On 12 May 2014 15:09, Jan M=C3=B8ller <jan.moller@gmail.com> 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?)