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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <allport@gmail.com>) id 1WcZDo-0005q9-25
for bitcoin-development@lists.sourceforge.net;
Tue, 22 Apr 2014 11:50:44 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.182 as permitted sender)
client-ip=209.85.220.182; envelope-from=allport@gmail.com;
helo=mail-vc0-f182.google.com;
Received: from mail-vc0-f182.google.com ([209.85.220.182])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WcZDk-0007kJ-Jm
for bitcoin-development@lists.sourceforge.net;
Tue, 22 Apr 2014 11:50:43 +0000
Received: by mail-vc0-f182.google.com with SMTP id ib6so2474777vcb.27
for <bitcoin-development@lists.sourceforge.net>;
Tue, 22 Apr 2014 04:50:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.58.202.133 with SMTP id ki5mr34727731vec.19.1398167435049;
Tue, 22 Apr 2014 04:50:35 -0700 (PDT)
Received: by 10.52.145.145 with HTTP; Tue, 22 Apr 2014 04:50:34 -0700 (PDT)
Received: by 10.52.145.145 with HTTP; Tue, 22 Apr 2014 04:50:34 -0700 (PDT)
In-Reply-To: <9644584.QTKx69qfup@crushinator>
References: <CAC7yFxSE8-TWPN-kuFiqdPKMDuprbiVJi7-z-ym+AUyA_f-xJw@mail.gmail.com>
<2336265.urqHVhRi8n@crushinator>
<CABh=4qPX=w4815O1bRSu+y-KviKS=Brai-umgmheZM5Ar6xv1w@mail.gmail.com>
<9644584.QTKx69qfup@crushinator>
Date: Tue, 22 Apr 2014 07:50:34 -0400
Message-ID: <CAK2MuX11Y2=SLfWb3meeo5-VatdEQi-0HHi+Ge2r+HE=d_LSig@mail.gmail.com>
From: Justin A <allport@gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>
Content-Type: multipart/alternative; boundary=047d7bea42604d831904f7a039a3
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
(allport[at]gmail.com)
-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: 1WcZDk-0007kJ-Jm
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: Tue, 22 Apr 2014 11:50:44 -0000
--047d7bea42604d831904f7a039a3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Is there a reason you prefer doing the M-1 offset as opposed to limiting
the range to 255 instead? Seems like something that will certainly confuse
some developers in exchange for adding one more value at the high end of a
range. I don't gather there's much difference between 255 and 256 here is
there? Also requires the small bit of explanation to hang around as a rider
in all future documentation, and the name of the field may not be
self-documenting anymore.
By way of predicting how I'm wrong, perhaps it is better to have a field
where all possible values are legitimate (by not biasing you would have to
check it's not zero), or perhaps it's important that powers of 2 be
represented here? Perhaps there's some use case at 256 that 255 just won't
do for?
I'm mostly just curious, as I find problems and funnies crop up when people
get clever with optimization of things like message bit-packing etc.. If
it's not necessary then maybe better to keep to what's intuitive (i.e. the
girls name is clear and self-documenting)
Anyway enough of my bike shedding!
On Apr 22, 2014 5:38 AM, "Matt Whitlock" <bip@mattwhitlock.name> wrote:
> On Tuesday, 22 April 2014, at 10:39 am, Jan M=C3=B8ller wrote:
> > On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock <bip@mattwhitlock.name
> >wrote:
> > > On Tuesday, 22 April 2014, at 10:27 am, Jan M=C3=B8ller wrote:
> > > > > > - Please allow M=3D1. From a usability point of view it makes
> sense to allow
> > > > > > the user to select 1 share if that is what he wants.
> > > > >
> > > > > How does that make sense? Decomposing a key/seed into 1 share is
> > > > > functionally equivalent to dispensing with the secret sharing
> scheme
> > > > > entirely.
> > > > >
> > > > I agree that it may look silly to have just one-of-one share from a
> > > > technical point of view, but from an end-user point of view there
> could be
> > > > reasons for just having one piece of paper to manage. If M can be 1
> then
> > > > the software/hardware doesn't have to support multiple formats,
> > > > import/export paths + UI (one for SIPA keys in one share, one for
> HD seeds
> > > > in one share, one for SIPA keys + HD seeds in multiple shares).
> > > >
> > > > Less complexity & more freedom of choice.
> > >
> > > Alright. It's a fair argument. Do you agree with encoding M using a
> bias
> > > of -1 so that M up to and including 256 can be encoded in one byte?
> >
> > Necessary Shares =3D M+1, not a problem
> >
> > I would probably encode N-of-M in 1 byte as I don't see good use cases
> with
> > more than 17 shares. Anyway, I am fine with it as it is.
>
> Encoding bias of M changed to -1, and test vectors updated:
> https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
>
>
> -------------------------------------------------------------------------=
-----
> 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
>
--047d7bea42604d831904f7a039a3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Is there a reason you prefer doing the M-1 offset as opposed=
to limiting the range to 255 instead? Seems like something that will certa=
inly confuse some developers in exchange for adding one more value at the h=
igh end of a range. I don't gather there's much difference between =
255 and 256 here is there? Also requires the small bit of explanation to ha=
ng around as a rider in all future documentation, and the name of the field=
may not be self-documenting anymore.</p>
<p dir=3D"ltr">By way of predicting how I'm wrong, perhaps it is better=
to have a field where all possible values are legitimate (by not biasing y=
ou would have to check it's not zero), or perhaps it's important th=
at powers of 2 be represented here? Perhaps there's some use case at 25=
6 that 255 just won't do for?</p>
<p dir=3D"ltr">I'm mostly just curious, as I find problems and funnies =
crop up when people get clever with optimization of things like message bit=
-packing etc.. If it's not necessary then maybe better to keep to what&=
#39;s intuitive (i.e. the girls name is clear and self-documenting)</p>
<p dir=3D"ltr">Anyway enough of my bike shedding!</p>
<div class=3D"gmail_quote">On Apr 22, 2014 5:38 AM, "Matt Whitlock&quo=
t; <<a href=3D"mailto:bip@mattwhitlock.name">bip@mattwhitlock.name</a>&g=
t; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tuesday, 22 April 2014, at 10:39 am, Jan M=C3=B8ller wrote:<br>
> On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock <<a href=3D"mailto:=
bip@mattwhitlock.name">bip@mattwhitlock.name</a>>wrote:<br>
> > On Tuesday, 22 April 2014, at 10:27 am, Jan M=C3=B8ller wrote:<br=
>
> > > > > =C2=A0- Please allow M=3D1. From a usability point=
of view it makes sense to allow<br>
> > > > > the user to select 1 share if that is what he want=
s.<br>
> > > ><br>
> > > > How does that make sense? Decomposing a key/seed into 1=
share is<br>
> > > > functionally equivalent to dispensing with the secret s=
haring scheme<br>
> > > > entirely.<br>
> > > ><br>
> > > I agree that it may look silly to have just one-of-one share=
from a<br>
> > > technical point of view, but from an end-user point of view =
there could be<br>
> > > reasons for just having one piece of paper to manage. If M c=
an be 1 then<br>
> > > the software/hardware doesn't have to support multiple f=
ormats,<br>
> > > import/export paths + UI =C2=A0(one for SIPA keys in one sha=
re, one for HD seeds<br>
> > > in one share, one for SIPA keys + HD seeds in multiple share=
s).<br>
> > ><br>
> > > Less complexity & more freedom of choice.<br>
> ><br>
> > Alright. It's a fair argument. Do you agree with encoding M u=
sing a bias<br>
> > of -1 so that M up to and including 256 can be encoded in one byt=
e?<br>
><br>
> Necessary Shares =3D M+1, not a problem<br>
><br>
> I would probably encode N-of-M in 1 byte as I don't see good use c=
ases with<br>
> more than 17 shares. Anyway, I am fine with it as it is.<br>
<br>
Encoding bias of M changed to -1, and test vectors updated:<br>
<a href=3D"https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki=
" target=3D"_blank">https://github.com/whitslack/btctool/blob/bip/bip-xxxx.=
mediawiki</a><br>
<br>
---------------------------------------------------------------------------=
---<br>
Start Your Social Network Today - Download eXo Platform<br>
Build your Enterprise Intranet with eXo Platform Software<br>
Java Based Open Source Intranet - Social, Extensible, Cloud Ready<br>
Get Started Now And Turn Your Intranet Into A Collaboration Platform<br>
<a href=3D"http://p.sf.net/sfu/ExoPlatform" target=3D"_blank">http://p.sf.n=
et/sfu/ExoPlatform</a><br>
_______________________________________________<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>
</blockquote></div>
--047d7bea42604d831904f7a039a3--
|
