public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Nikita Schmidt <nikita@megiontechnologies•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys
Date: Thu, 3 Apr 2014 16:41:06 +0400	[thread overview]
Message-ID: <CAC7yFxSE8-TWPN-kuFiqdPKMDuprbiVJi7-z-ym+AUyA_f-xJw@mail.gmail.com> (raw)

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.



             reply	other threads:[~2014-04-03 13:05 UTC|newest]

Thread overview: 90+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-03 12:41 Nikita Schmidt [this message]
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
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=CAC7yFxSE8-TWPN-kuFiqdPKMDuprbiVJi7-z-ym+AUyA_f-xJw@mail.gmail.com \
    --to=nikita@megiontechnologies$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /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