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
|
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 <elombrozo@gmail.com>) id 1WJj3I-0005Kl-32
for bitcoin-development@lists.sourceforge.net;
Sat, 01 Mar 2014 12:30:00 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.220.47 as permitted sender)
client-ip=209.85.220.47; envelope-from=elombrozo@gmail.com;
helo=mail-pa0-f47.google.com;
Received: from mail-pa0-f47.google.com ([209.85.220.47])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WJj3H-00056G-4G
for bitcoin-development@lists.sourceforge.net;
Sat, 01 Mar 2014 12:30:00 +0000
Received: by mail-pa0-f47.google.com with SMTP id lj1so1925774pab.20
for <bitcoin-development@lists.sourceforge.net>;
Sat, 01 Mar 2014 04:29:53 -0800 (PST)
X-Received: by 10.66.182.199 with SMTP id eg7mr9225463pac.135.1393676993276;
Sat, 01 Mar 2014 04:29:53 -0800 (PST)
Received: from [192.168.1.107] (cpe-76-88-33-166.san.res.rr.com.
[76.88.33.166])
by mx.google.com with ESMTPSA id sm5sm2025056pab.19.2014.03.01.04.29.50
for <bitcoin-development@lists.sourceforge.net>
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sat, 01 Mar 2014 04:29:51 -0800 (PST)
From: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: multipart/signed;
boundary="Apple-Mail=_449E2016-C8B9-49D1-B3D2-D63D90C89667";
protocol="application/pgp-signature"; micalg=pgp-sha1
Message-Id: <B837A283-4B5B-4753-A4A2-1AA27F1A2175@gmail.com>
Date: Sat, 1 Mar 2014 04:29:48 -0800
To: bitcoin-development@lists.sourceforge.net
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-Spam-Score: -1.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
(elombrozo[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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: 1WJj3H-00056G-4G
Subject: [Bitcoin-development] Making the H in HD keychains useful
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: Sat, 01 Mar 2014 12:30:00 -0000
--Apple-Mail=_449E2016-C8B9-49D1-B3D2-D63D90C89667
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
I've been trying to find ways to make HD keychain wallets (BIP0032) =
really usable from an application development perspective. I think we =
all know a number of solid use cases and possible applications for the D =
in HD, but nobody seems to have really found a way to make use of the H =
in a way that is actually manageable from a usability standpoint.
After pondering it a bit more, I think I've stumbled upon at least a =
couple issues that seem to give hints as to how we can change this.
Hierarchical organizations do not generally tend to be designed up =
front, cast in stone. In the real world, hierarchies tend to evolve =
organically, growing new branches as entities differentiate themselves =
to different purposes. Organizations grow over time. Sometimes branches =
merge, sometimes branches die. This means that for HD keychains to be =
truly useful, they too need to be sufficiently flexible to adapt to the =
needs of a growing and evolving organization. It needs to be simple to =
create and move branches around as the need for them arises without =
having to plan the structure a priori.
A significant problem I'm runnign into in trying to build applications =
around the BIP0032 standard is the lack of a clear separation between =
signing keys and hierarchical nodes. That's to say, a child of a node =
can either be used as a signing key or as a parent for new branches to =
the tree. =46rom a usability standpoint, what this means is that one =
must be very careful in how one allocates keys from the very beginning - =
if one mixes signing keys with new branching nodes in the same =
generation, the whole thing becomes a horrendous mess. Moreover, it is =
impossible to generally distinguish these two fundamentally different =
types of objects (at least from a use model perspective) just from the =
extended key representation, something that is certain to create =
significant confusion as we try to design applications that can share =
these types of objects.
An organization might begin as a single individual who just wants to =
generate signing keys for him/herself. Later on, this individual might =
bring on another individual or two and create new branches for them. =
With the current HD keychain structure, unless this individual made sure =
to set aside these new branches from the start, the individual is now =
forced to mix the new branches in at the same level of the hierarchy as =
the signing keys. Instead, it should be possible to branch off any node =
without having to worry at all about whether or not that node has been =
used to generate signing keys at all.
A possible workaround to this issue is to always allocate a specific =
child for hierarchical derivation and the rest of the children for =
signing keys. Then to create subbranches, the specific child would be =
used as the new parent, effectively alternating generations between =
signing keys and organizational nodes. However, this solution seems =
pretty ugly.
A better solution, IMO, is to only use BIP0032 for organizational =
hierarchy and have a different mechanism for generating a sequence of =
signing keys from a given node. This different mechanism could be used =
standalone by those not needing the full set of hierarchical features. =
For those who do want to use the hierarchical features, it could be =
seeded by the keys in the BIP0032 hierarchy. These individual signing =
keys would NEVER be represented in the same format as the organizational =
hierarchy nodes, thus ensuring applications can share these structures =
without risk of confusion.
Until we make this clear distinction between organizational hierarchy =
(which parallels real-world organizations) and signing keys (which are =
merely cryptographic primitives, preferably never even shown directly to =
most endusers), I think we'll fail to find good ways to make the H in HD =
keychains useful.
-Eric Lombrozo
--Apple-Mail=_449E2016-C8B9-49D1-B3D2-D63D90C89667
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJTEdK8AAoJEAA1EyJsW9n+mDcP/jcJqZ/Z3vbOzACBUJa3Kc2g
YjRJUD4TTXL7xrDpenVpmFQF5XVCCNTzt7aYo1Un1WZlGbeoIw2hzuaE4upU0bfT
RVcBr71+iSlU3E2SubY7LS8TXDd28GGoeb73HYlq44xLcuuOITLljkQjE21fg6dq
kh/rlBY31B0be0H1btESfG0ekzx2v0mvOs+dWefANX2MoGJpJtL0ZUyUmBRxYgdk
lEcxYXsP53CpMdcikR3EX1LjnWHqDaR/6dLhCnV3Ko6mZAFyXuK3Udj/FtskKlDG
RbquFY6z/ZzdAJSrOo8iUVGMyQdEektlNunHt7hyXmwwD7Hjn1KkWSlPQd3h3bcs
WE1BGcL9lVrXnmBTkfGm9KMgyiYHu63hr85cZ44vg3QIVTXUOzXnzYFVulgfDM6v
mZLSFIaVdCXx6bKX/oFedx1Z/vKtmazNXoga2bG53YDLGHay+06fydDykQ7mlSe9
mtxV7cIf3F7MXlVyFeHSPnH/5eY98iH3jFc5B+QTyk+0IAN61GJ/tvXcR6tggg6+
kYwY+HBVz2LUKAYrJVvqB5noAazP9V+no/VEHA+K3jWPvBP+9AlSr1AfO0yeT4k2
gWQ7INCSn1QWX0/h+NiKbVRz/uYWQEWaSIdscKmuZK97dhRkaUGfGy01xdErQUX6
vcu8zpRgdXYdT51O18rw
=glfk
-----END PGP SIGNATURE-----
--Apple-Mail=_449E2016-C8B9-49D1-B3D2-D63D90C89667--
|
