1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <nikita@megiontechnologies.com>) id 1WW4Ws-0007Iw-LA
for bitcoin-development@lists.sourceforge.net;
Fri, 04 Apr 2014 13:51:34 +0000
X-ACL-Warn:
Received: from mail-qa0-f51.google.com ([209.85.216.51])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WW4Wr-0004K7-CL
for bitcoin-development@lists.sourceforge.net;
Fri, 04 Apr 2014 13:51:34 +0000
Received: by mail-qa0-f51.google.com with SMTP id j7so3088235qaq.24
for <bitcoin-development@lists.sourceforge.net>;
Fri, 04 Apr 2014 06:51:27 -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=BjRP882Dj3bNLTfetqt5n000VGqtw5pnhpwPMU+lL50=;
b=GBtMv4QmforJ6PNglTDsQOfX8eqzrsCN5YtqOOzohlTfsy55cmudSCnSmVZ9ExbVDe
Shg8qeTXozH5uQj3kpf61K69DSfHa3N8E7mOSl90mu49RhY6JC7mRqrIEDEH9K94lJMA
CBU3cFu700V7/irGT0uYLxIpYK3i8qlRJyAh961oA6R2oVy/COLav3a9X4xyOoEAxIe8
EXGKkOwYTlxnRZezvDd1xBkrU10h37BcWNTLjX64avTa2zDgf/CV4YsD2Z6wJJ3ZEjxi
4uN6mtIV8JcklqLOaXRqg9f0/tDiyI6VGaGdZRTTqv4sBsClmTx15quCngg3mAhD+DXl
03xw==
X-Gm-Message-State: ALoCoQkXTMuR1vqXj9SfwkB4vk58hTrH3ktXhCKO7fle8v13NSb/3IXoqrkPfumenh85Lt/cdyvi
X-Received: by 10.140.107.229 with SMTP id h92mr13758239qgf.30.1396619487296;
Fri, 04 Apr 2014 06:51:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.96.124.10 with HTTP; Fri, 4 Apr 2014 06:51:07 -0700 (PDT)
X-Originating-IP: [2001:770:14a:0:a51c:ceb3:9a48:da83]
In-Reply-To: <3837746.jqWvB0Uxrs@crushinator>
References: <CAC7yFxSE8-TWPN-kuFiqdPKMDuprbiVJi7-z-ym+AUyA_f-xJw@mail.gmail.com>
<3837746.jqWvB0Uxrs@crushinator>
From: Nikita Schmidt <nikita@megiontechnologies.com>
Date: Fri, 4 Apr 2014 17:51:07 +0400
Message-ID: <CAC7yFxQXn=c7CEC326yMx4bF7Cv7Gc62shS7xU0XvSp5sQSGZw@mail.gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>
Content-Type: text/plain; charset=ISO-8859-1
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: 1WW4Wr-0004K7-CL
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 04 Apr 2014 13:51:37 -0000
On 4 April 2014 01:42, Matt Whitlock <bip@mattwhitlock.name> wrote:
> The fingerprint field, Hash16(K), is presently specified as a 16-bit fiel=
d. Rationale: There is no need to consume 4 bytes just to allow shares to b=
e grouped together. And if someone has more than 100 different secrets, the=
y probably have a good system for managing their shares and won't need the =
hash anyway.
Right, of course. Sorry, I didn't notice there was an update. Two
bytes are plenty.
I'm worried however about the dependency on SHA-512, which may be
stretching it for a tiny embedded application. The other uses of
HashL can be avoided. We are balancing here between consistency with
the rest of this proposal, where everything is done via HashL, and
consistency with the general practice of generating fingerprints with
SHA-256, like in Base58Check.
Similarly, re-assembly software suddenly finds itself having to
implement Hash16 just to check this particular fingerprint. So I'd
vote for a more traditional approach here, also considering that HashL
is designed specifically to generate numbers in a finite field.
>
>> Encoding for the testnet is not specified.
>
> Hmm, is that actually needed?
It's been a tradition to support it in general, however I guess it's
not really needed here. I'm happy without a dedicated testnet
encoding.
>
>> 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 agree on principle, however I think the more user-acceptable behavior i=
s for all base58-encoded Shamir shares to begin with a common prefix, such =
as "SS". Users are accustomed to relying on the prefix of the base58 encodi=
ng to understand what the object is: "1" for mainnet pubkey hash, "3" for m=
ainnet script hash, "5" for uncompressed private key, "P" for passphrase-pr=
otected private key, etc.
Yes, "5" for uncompressed private key and "K" or "L" for compressed
private key. One A/VB and three prefixes in base58. Am I the only
one to see this as a counter-example?
However, thinking about this, I can find logic in wanting to stabilise
text prefixes at a cost of six A/V bytes (as per the latest spec).
There are only 58 first characters versus 256 AVBs, so we should
rather be saving the former.
>> What about using the same P256 prime as for the elliptic curve? Just
>> for consistency's sake.
>
> The initial draft of this BIP used the cyclic order (n) of the generator =
point on the secp256k1 elliptic curve as the modulus. The change to the pre=
sent scheme was actually done for consistency's sake, so all sizes of secre=
t can use a consistently defined modulus.
Fair enough. Although I would have chosen the field order (p) simply
because that's how all arithmetic already works in bitcoin. One field
for everybody. It's also very close to 2^256, although still smaller
than your maximum prime. Now of course with different bit lengths we
have to pick one consistency over others.
>
>> 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=3D0 can denote a special case for future extensions.
>> There is no technical reason behind this, it's just for (subjective)
>> clarity and consistency.
>
> There is a technical reason for encoding j rather than x[j]: it allows fo=
r the first 256 shares to be encoded, rather than only the first 255 shares=
.
Wow, big deal. It's hard to imagine anyone needing exactly 256
shares, but who knows. And with j =3D x (starting from 1) we'd get
user-friendly share numbering and simpler formulas in the spec and
possibly in the implementation, with no off-by-one stuff. And M
instead of M-2...
>
> If you want a sentinel value reserved for future extensions, then you mig=
ht take notice that 0xFFFF is an invalid key fingerprint, along with severa=
l other values, and also that 0xFF is an unusable value of M-2, as that wou=
ld imply M=3D257, but the scheme can only encode up to 256 shares, so one w=
ould never have enough shares to meet the threshold. I considered having th=
e two optional fields be mandatory and allowing 0xFFFF and 0xFF as "redacte=
d" field values, but I like allowing the shares to be shorter if the option=
al fields are omitted. (Imagine engraving Shamir secret shares onto metal b=
ars by hand with an engraving tool. Fewer characters is better!)
Exactly. Thank you. Without these fields, a secret share still fits
into a 29x29 QR code. Add one more byte and it'll need a 33x33.
Imagine engraving that onto metal plates! Or the hassle of going
above 32 bits per line in a tiny embedded system.
|
