public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Nikita Schmidt <nikita@megiontechnologies•com>
To: "Jan Møller" <jan.moller@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
Date: Thu, 14 Aug 2014 22:23:16 +0300	[thread overview]
Message-ID: <CAC7yFxT+cXFJ4rG46q=HjCppV-J9SMJcPcEpSqyvHMEYJd_bbw@mail.gmail.com> (raw)
In-Reply-To: <CABh=4qMpge4q-CmKNNnxj5C_jGEFhwAVrUHSNbqy3njeUiSHvQ@mail.gmail.com>

On 12 May 2014 15:09, Jan Møller <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. From
> 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?)



  reply	other threads:[~2014-08-14 19:54 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-03 12:41 Nikita Schmidt
2014-04-03 21:42 ` Matt Whitlock
2014-04-04 13:51   ` Nikita Schmidt
2014-04-04 14:14     ` Gregory Maxwell
2014-04-04 16:05       ` Matt Whitlock
2014-04-04 16:25         ` Gregory Maxwell
2014-04-04 16:36           ` Matt Whitlock
2014-04-04 17:08             ` Gregory Maxwell
2014-04-04 17:16               ` Matt Whitlock
2014-04-04 17:51                 ` Gregory Maxwell
2014-04-04 18:53                   ` Matt Whitlock
2014-04-04 16:03     ` Matt Whitlock
2014-04-08  0:33       ` Nikita Schmidt
2014-04-08  0:38         ` Gregory Maxwell
2014-04-08  1:46           ` Matt Whitlock
2014-04-08  2:07             ` Gregory Maxwell
2014-04-08 11:52               ` Matt Whitlock
2014-04-10 22:31                 ` Nikita Schmidt
2014-04-22  8:06                   ` Jan Møller
2014-04-22  8:11                     ` Matt Whitlock
2014-04-22  8:27                       ` Jan Møller
2014-04-22  8:29                         ` Matt Whitlock
2014-04-22  8:39                           ` Jan Møller
2014-04-22  8:43                             ` Matt Whitlock
2014-04-22  8:51                               ` Jan Møller
2014-04-22  9:13                             ` Matt Whitlock
2014-04-22 11:50                               ` Justin A
2014-04-22  8:35                       ` Matt Whitlock
2014-04-22  8:39                         ` Tamas Blummer
2014-04-22  8:40                           ` Matt Whitlock
2014-04-22  8:43                             ` Tamas Blummer
2014-04-22  8:47                               ` Matt Whitlock
2014-04-22  8:50                                 ` Tamas Blummer
2014-04-22 15:32                           ` Mark Friedenbach
2014-04-22 15:49                             ` Tamas Blummer
2014-04-22 17:03                               ` Mark Friedenbach
2014-04-22 17:07                               ` Jan Møller
2014-04-22 18:29                                 ` Tamas Blummer
2014-04-22 18:46                                   ` Gregory Maxwell
2014-04-23  5:33                                     ` Tamas Blummer
2014-04-23  6:16                                       ` Gregory Maxwell
2014-05-05 19:36                                         ` Nikita Schmidt
2014-05-12 12:09                                           ` Jan Møller
2014-08-14 19:23                                             ` Nikita Schmidt [this message]
2014-04-22 13:37                       ` Nikita Schmidt
2014-04-22  8:15                     ` Gregory Maxwell
2014-04-22  8:49                       ` Jan Møller
     [not found] <CACsn0ckScTWG4YxNCscxvtdsmcUkxtR2Gi-rdBs2HCkirPz5rA@mail.gmail.com>
2014-03-29 15:44 ` Matt Whitlock
2014-03-29 16:59   ` Alan Reiner
2014-03-29 17:19     ` Matt Whitlock
2014-03-29 17:52       ` Alan Reiner
2014-03-29 18:00         ` Matt Whitlock
2014-03-29 18:08           ` Alan Reiner
2014-03-29 18:10             ` Matt Whitlock
     [not found]               ` <CAAt2M18j7bGDsKouVw+e4j+FMiJ4vK6-sx+nrkwHyiKLqiH7Jg@mail.gmail.com>
2014-03-29 19:34                 ` Natanael
2014-04-04  2:38               ` Jeff Garzik
2014-03-29 18:16         ` Tamas Blummer
2014-03-29 18:41           ` Alan Reiner
2014-03-29 17:28     ` Roy Badami
2014-03-29 17:42       ` Matt Whitlock
2014-03-29 17:51         ` Roy Badami
2014-03-29 17:28   ` devrandom
     [not found]   ` <1396113933.8809.91.camel@mimiz>
2014-03-29 17:38     ` Matt Whitlock
2014-03-29 17:46       ` Gregory Maxwell
2014-03-29 19:49         ` Tamas Blummer
2014-03-29 17:48       ` devrandom
2014-03-29 17:51         ` Matt Whitlock
2014-03-29 17:56           ` devrandom
  -- strict thread matches above, loose matches on Subject: below --
2014-03-29  8:05 Matt Whitlock
2014-03-29  8:34 ` Tamas Blummer
2014-03-29  8:44 ` Tamas Blummer
2014-03-29  8:51   ` Matt Whitlock
2014-03-29  8:54     ` Matt Whitlock
2014-03-29 16:54   ` Matt Whitlock
2014-03-29 17:37     ` Tamas Blummer
2014-03-29  9:08 ` Chris Beams
2014-03-29  9:31   ` Matt Whitlock
2014-03-29 11:16   ` Matt Whitlock
2014-03-29 11:54     ` Chris Beams
2014-03-29 13:27       ` Jeff Garzik
2014-03-29 13:36         ` Mike Hearn
2014-03-29 13:38           ` Tamas Blummer
2014-03-29 14:10           ` Matt Whitlock
2014-03-29 14:19             ` Jeff Garzik
2014-03-29 14:55               ` Matt Whitlock
2014-03-29 15:04                 ` Mike Hearn
2014-03-29 14:28             ` Watson Ladd
2014-03-29 14:36               ` Gregory Maxwell
2014-03-29 15:01                 ` Matt Whitlock
2014-03-29  9:21 ` Chris Beams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAC7yFxT+cXFJ4rG46q=HjCppV-J9SMJcPcEpSqyvHMEYJd_bbw@mail.gmail.com' \
    --to=nikita@megiontechnologies$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=jan.moller@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox