summaryrefslogtreecommitdiff
path: root/1a/6e3e7229b0e0c0850811cf750fda6e7e87e907
blob: 9b9f5d2cf36ac5f5ae79067e3c23e60afa32361d (plain)
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
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <jan.moller@gmail.com>) id 1Wjp3Q-0007ff-AF
	for bitcoin-development@lists.sourceforge.net;
	Mon, 12 May 2014 12:10:00 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.44 as permitted sender)
	client-ip=209.85.192.44; envelope-from=jan.moller@gmail.com;
	helo=mail-qg0-f44.google.com; 
Received: from mail-qg0-f44.google.com ([209.85.192.44])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Wjp3P-00087j-3W
	for bitcoin-development@lists.sourceforge.net;
	Mon, 12 May 2014 12:10:00 +0000
Received: by mail-qg0-f44.google.com with SMTP id i50so7435977qgf.17
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 12 May 2014 05:09:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.140.105.163 with SMTP id c32mr35911463qgf.36.1399896593506; 
	Mon, 12 May 2014 05:09:53 -0700 (PDT)
Received: by 10.140.47.35 with HTTP; Mon, 12 May 2014 05:09:53 -0700 (PDT)
In-Reply-To: <CAC7yFxQR6oVdASacCefPiuWocvrDHTTnVU4xyVdZTwvMr4ZPNw@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>
Date: Mon, 12 May 2014 14:09:53 +0200
Message-ID: <CABh=4qMpge4q-CmKNNnxj5C_jGEFhwAVrUHSNbqy3njeUiSHvQ@mail.gmail.com>
From: =?UTF-8?Q?Jan_M=C3=B8ller?= <jan.moller@gmail.com>
To: Nikita Schmidt <nikita@megiontechnologies.com>, 
	Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1139bcd42da74504f932d3a1
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(jan.moller[at]gmail.com)
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [209.85.192.44 listed in list.dnswl.org]
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Wjp3P-00087j-3W
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
Reply-To: jan.moller@gmail.com
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: Mon, 12 May 2014 12:10:02 -0000

--001a1139bcd42da74504f932d3a1
Content-Type: text/plain; charset=UTF-8

A Java implementation of what is called BIPSS in lack of an official number
can be found here:
https://github.com/mycelium-com/wallet/blob/master/public/bitlib/src/main/java/com/mrd/bitlib/crypto/BipSs.java
(passing all test vectors)

Which is based on a GF2^8 implementation here:
https://github.com/mycelium-com/wallet/blob/master/public/bitlib/src/main/java/com/mrd/bitlib/crypto/Gf256.java

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.




On Mon, May 5, 2014 at 9:36 PM, Nikita Schmidt <
nikita@megiontechnologies.com> wrote:

> A fork of Matt's proposal converted to GF(2^8) is here:
> https://github.com/cetuscetus/btctool/blob/bip/bip-xxxx.mediawiki
>
> Other changes include:
> - only six application/version bytes are allocated, which is the
> minimum to ensure that the encoded form starts with S in all cases;
> - encoded prefixes are SK/SL for a shared private key
> (mainnet/testnet) and SS/ST for a shared BIP32 seed;
> - the only hash function in use is SHA-256, which is the all-purpose
> hash function in the Bitcoin protocol;
> - double SHA is used for similarity with Bitcoin, although Jan and I
> believe single SHA is enough in this application;
> - bias-less encoding of M and x, because there can't be more than 255
> shares over GF(2^8).
>
>
> On 23 April 2014 09:16, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> > On Tue, Apr 22, 2014 at 10:33 PM, Tamas Blummer <tamas@bitsofproof.com>
> wrote:
> >> So you agree, that SSS should not contain specific flag for testnet?
> >>
> >> Or for that matter not even BIP32 needs them since it is not an address
> to
> >> send to.
> >
> > I think the convention we have so far is that addresses and address
> > relate thing we share normally contain an opaque 'version' identifier
> > which we use to identify the purpose for the data (E.g. network
> > meaning, etc.) and I think its a generally reasonable custom.
> >
> >
> ------------------------------------------------------------------------------
> > Start Your Social Network Today - Download eXo Platform
> > Build your Enterprise Intranet with eXo Platform Software
> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
> > http://p.sf.net/sfu/ExoPlatform
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Is your legacy SCM system holding you back? Join Perforce May 7 to find
> out:
> &#149; 3 signs your SCM is hindering your productivity
> &#149; Requirements for releasing software faster
> &#149; Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

--001a1139bcd42da74504f932d3a1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A Java implementation of what is called BIPSS in lack of a=
n official number can be found here:<div><a href=3D"https://github.com/myce=
lium-com/wallet/blob/master/public/bitlib/src/main/java/com/mrd/bitlib/cryp=
to/BipSs.java">https://github.com/mycelium-com/wallet/blob/master/public/bi=
tlib/src/main/java/com/mrd/bitlib/crypto/BipSs.java</a></div>
<div>(passing all test vectors)<br></div><div><br></div><div>Which is based=
 on a GF2^8 implementation here:</div><div><a href=3D"https://github.com/my=
celium-com/wallet/blob/master/public/bitlib/src/main/java/com/mrd/bitlib/cr=
ypto/Gf256.java">https://github.com/mycelium-com/wallet/blob/master/public/=
bitlib/src/main/java/com/mrd/bitlib/crypto/Gf256.java</a><br>
</div><div><br></div><div>I think having 3 encoding formats (long/short/com=
pact) is over engineered, and basically only makes implementing the standar=
d a pain in the rear. From a user experience point of view only the long fo=
rmat makes sense, and it is only a few bytes longer than the short version.=
</div>
<div><br></div><div><br></div></div><div class=3D"gmail_extra"><br><br><div=
 class=3D"gmail_quote">On Mon, May 5, 2014 at 9:36 PM, Nikita Schmidt <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:nikita@megiontechnologies.com" target=3D=
"_blank">nikita@megiontechnologies.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">A fork of Matt&#39;s proposal converted to G=
F(2^8) is here:<br>
<a href=3D"https://github.com/cetuscetus/btctool/blob/bip/bip-xxxx.mediawik=
i" target=3D"_blank">https://github.com/cetuscetus/btctool/blob/bip/bip-xxx=
x.mediawiki</a><br>
<br>
Other changes include:<br>
- only six application/version bytes are allocated, which is the<br>
minimum to ensure that the encoded form starts with S in all cases;<br>
- encoded prefixes are SK/SL for a shared private key<br>
(mainnet/testnet) and SS/ST for a shared BIP32 seed;<br>
- the only hash function in use is SHA-256, which is the all-purpose<br>
hash function in the Bitcoin protocol;<br>
- double SHA is used for similarity with Bitcoin, although Jan and I<br>
believe single SHA is enough in this application;<br>
- bias-less encoding of M and x, because there can&#39;t be more than 255<b=
r>
shares over GF(2^8).<br>
<div><div class=3D"h5"><br>
<br>
On 23 April 2014 09:16, Gregory Maxwell &lt;<a href=3D"mailto:gmaxwell@gmai=
l.com">gmaxwell@gmail.com</a>&gt; wrote:<br>
&gt; On Tue, Apr 22, 2014 at 10:33 PM, Tamas Blummer &lt;<a href=3D"mailto:=
tamas@bitsofproof.com">tamas@bitsofproof.com</a>&gt; wrote:<br>
&gt;&gt; So you agree, that SSS should not contain specific flag for testne=
t?<br>
&gt;&gt;<br>
&gt;&gt; Or for that matter not even BIP32 needs them since it is not an ad=
dress to<br>
&gt;&gt; send to.<br>
&gt;<br>
&gt; I think the convention we have so far is that addresses and address<br=
>
&gt; relate thing we share normally contain an opaque &#39;version&#39; ide=
ntifier<br>
&gt; which we use to identify the purpose for the data (E.g. network<br>
&gt; meaning, etc.) and I think its a generally reasonable custom.<br>
&gt;<br>
</div></div><div class=3D"">&gt; ------------------------------------------=
------------------------------------<br>
&gt; Start Your Social Network Today - Download eXo Platform<br>
&gt; Build your Enterprise Intranet with eXo Platform Software<br>
&gt; Java Based Open Source Intranet - Social, Extensible, Cloud Ready<br>
&gt; Get Started Now And Turn Your Intranet Into A Collaboration Platform<b=
r>
&gt; <a href=3D"http://p.sf.net/sfu/ExoPlatform" target=3D"_blank">http://p=
.sf.net/sfu/ExoPlatform</a><br>
&gt; _______________________________________________<br>
&gt; Bitcoin-development mailing list<br>
&gt; <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d=
evelopment@lists.sourceforge.net</a><br>
&gt; <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo=
pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco=
in-development</a><br>
<br>
</div>---------------------------------------------------------------------=
---------<br>
Is your legacy SCM system holding you back? Join Perforce May 7 to find out=
:<br>
&amp;#149; 3 signs your SCM is hindering your productivity<br>
&amp;#149; Requirements for releasing software faster<br>
&amp;#149; Expert tips and advice for migrating your SCM now<br>
<a href=3D"http://p.sf.net/sfu/perforce" target=3D"_blank">http://p.sf.net/=
sfu/perforce</a><br>
<div class=3D"HOEnZb"><div class=3D"h5">___________________________________=
____________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>

--001a1139bcd42da74504f932d3a1--