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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jan.moller@gmail.com>) id 1WcWFG-0007aV-F9
for bitcoin-development@lists.sourceforge.net;
Tue, 22 Apr 2014 08:40:02 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.47 as permitted sender)
client-ip=209.85.216.47; envelope-from=jan.moller@gmail.com;
helo=mail-qa0-f47.google.com;
Received: from mail-qa0-f47.google.com ([209.85.216.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WcWFC-000793-1X
for bitcoin-development@lists.sourceforge.net;
Tue, 22 Apr 2014 08:40:01 +0000
Received: by mail-qa0-f47.google.com with SMTP id m5so4803123qaj.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 22 Apr 2014 01:39:52 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.224.75.10 with SMTP id w10mr45386298qaj.52.1398155992460;
Tue, 22 Apr 2014 01:39:52 -0700 (PDT)
Received: by 10.140.24.201 with HTTP; Tue, 22 Apr 2014 01:39:52 -0700 (PDT)
In-Reply-To: <2336265.urqHVhRi8n@crushinator>
References: <CAC7yFxSE8-TWPN-kuFiqdPKMDuprbiVJi7-z-ym+AUyA_f-xJw@mail.gmail.com>
<1927948.OEZHQcsQ9n@crushinator>
<CABh=4qOQhxEte3yQfCMNOZdedExtpqARQRDSfxQMqk-2KwJamw@mail.gmail.com>
<2336265.urqHVhRi8n@crushinator>
Date: Tue, 22 Apr 2014 10:39:52 +0200
Message-ID: <CABh=4qPX=w4815O1bRSu+y-KviKS=Brai-umgmheZM5Ar6xv1w@mail.gmail.com>
From: =?UTF-8?Q?Jan_M=C3=B8ller?= <jan.moller@gmail.com>
To: Matt Whitlock <bip@mattwhitlock.name>
Content-Type: multipart/alternative; boundary=001a11c2fe04458fab04f79d8feb
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 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: 1WcWFC-000793-1X
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
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: Tue, 22 Apr 2014 08:40:02 -0000
--001a11c2fe04458fab04f79d8feb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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.
On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock <bip@mattwhitlock.name>wrot=
e:
> 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 sens=
e 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 the=
n
> > 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?
>
--001a11c2fe04458fab04f79d8feb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Necessary Shares =3D M+1, not a problem=C2=A0<div><br></di=
v><div>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.<br><di=
v class=3D"gmail_extra">
<br><br><div class=3D"gmail_quote">On Tue, Apr 22, 2014 at 10:29 AM, Matt W=
hitlock <span dir=3D"ltr"><<a href=3D"mailto:bip@mattwhitlock.name" targ=
et=3D"_blank">bip@mattwhitlock.name</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<div class=3D"HOEnZb"><div class=3D"h5">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 i=
t makes sense to<br>
> > allow<br>
> > > the user to select 1 share if that is what he wants.<br>
> ><br>
> > How does that make sense? Decomposing a key/seed into 1 share is<=
br>
> > functionally equivalent to dispensing with the secret sharing sch=
eme<br>
> > entirely.<br>
> ><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 coul=
d be<br>
> reasons for just having one piece of paper to manage. If M can be 1 th=
en<br>
> the software/hardware doesn't have to support multiple formats,<br=
>
> import/export paths + UI =C2=A0(one for SIPA keys in one share, one fo=
r HD seeds<br>
> in one share, one for SIPA keys + HD seeds in multiple shares).<br>
><br>
> Less complexity & more freedom of choice.<br>
<br>
</div></div>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?<br>
</blockquote></div><br></div></div></div>
--001a11c2fe04458fab04f79d8feb--
|
