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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <matt@gem.co>) id 1Z65lT-0006Rv-AJ
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 23:32:03 +0000
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 1Z65lS-0003Dr-7O
for bitcoin-development@lists.sourceforge.net;
Fri, 19 Jun 2015 23:32:03 +0000
Received: by paceq1 with SMTP id eq1so69640083pac.3
for <bitcoin-development@lists.sourceforge.net>;
Fri, 19 Jun 2015 16:31:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to
:subject:references:in-reply-to:openpgp:content-type;
bh=FmwqVB5NfHeE9sm12M7mwDHkkxhkndvwzkSnFQ3hy4o=;
b=XpxNvkQyQw8mrvzQ0++BpJfAZ7fxe13cZG9q0bAmo3TgiKHavYDubHgXpdYEJdF4hG
JbojIqynsHBSdrY19Uu5TUQz9Nz6PFI+qjlujd8tyUE9Xjl3kMY5L36ZCKKyl+FMa7j5
pmMARTCKss4SGfDea2C7Id0ep1cR1lHHoeVEA9YUiaMXyMtYyFTMfcLhxWIazyKQ5Th2
AgEobVKnobkfIs8Fz0aWgVzC1R/Nmf/NdXADj9Sfv4O7s2Q0qWJ8u5BPkJDgNSNIuNQI
07oumC/9nxT1QdBf9xdCdnLiU+slvod0t0MUUbJQ4lt72z83mIbOUGkrZNEdIeg6OlZV
ovWg==
X-Gm-Message-State: ALoCoQlDUleftMbyrt9CgOVMof3WYTW0uM9m/OBeXuEor9FoQ5Kl1AXaQ+a1mWq0TJYM9zlOzcon
X-Received: by 10.66.118.166 with SMTP id kn6mr36119848pab.93.1434756716460;
Fri, 19 Jun 2015 16:31:56 -0700 (PDT)
Received: from velocity.local (static-108-47-15-123.lsanca.fios.verizon.net.
[108.47.15.123]) by mx.google.com with ESMTPSA id
nt6sm12271355pbc.18.2015.06.19.16.31.55
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 19 Jun 2015 16:31:55 -0700 (PDT)
Message-ID: <5584A667.2050205@gem.co>
Date: Fri, 19 Jun 2015 16:31:51 -0700
From: Matt Smith <matt@gem.co>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "Matt @ Envrin Group" <matt@envrin.com>,
bitcoin-development@lists.sourceforge.net
References: <55847E98.3050307@gem.co> <558488D0.50904@envrin.com>
In-Reply-To: <558488D0.50904@envrin.com>
OpenPGP: id=FA305457B4CB1A8936558F5844F963F563331857
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="8JhuPogBtqRvGQfNhkmqKpMMj3VvAX5Qj"
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: 1Z65lS-0003Dr-7O
Subject: Re: [Bitcoin-development] Alternate HD path structure: BIP, blog,
or wat?
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, 19 Jun 2015 23:32:03 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--8JhuPogBtqRvGQfNhkmqKpMMj3VvAX5Qj
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
I'm not sure I understand your question about the need to store paths in
the wallet database -- there's no way to infer the path of an address
inside an HD wallet from the address alone (short of an exhaustive
search), and HD wallets need to store either the paths, addresses, or
both that have been previously derived/used to monitor the blockchain
usefully, but those facts aren't new or specific to this path format.
The motivation for this path structure over standard bip44 is that it
separates the concept of network (or which blockchain I'm using) and
coin_type (or what kind of thing I'm sending over that blockchain).
This is useful, for example, if I want to import a wallet into my
application and I know that an account was in use at
m/##'/0'/99'/0'
where 99 is the identifier for, say, counterparty - I only need to check
the addresses derived below that path for balances against
counterpartyd. It may be worth pointing out that I expect multisig HD
wallet imports to require master keys and a list of account paths =96 not=
a list of addresses, as it's very possible that a new address could be
derived between the time when the wallet data was exported and when it
will be imported.
This use case might be very specific to our model, but the reason I
figured we should request a BIP # for this is that to start using it, we
need to pick a number for the purpose field and don't want to do it
arbitrarily (and risk having to change it later) or overload 44 (which
would be misleading).
Did I either a) answer or b) misunderstand your questions?
--
Matt Smith | Gem
https://gem.co | GH: @thedoctor
On 6/19/15 2:25 PM, Matt @ Envrin Group wrote:
>=20
> Hi Matt,
>=20
> I think your best bet is probably just push it out privately via blog
> post / Github, and see if it gains any traction with other developers.
>=20
> I'm a little uncertain as to the relevance though. All those variables=
> (purpose, network, asset_type, account, change, index) need to be store=
d
> internally within the wallet database, as there's no way to retrieve th=
e
> path used from just the address, correct? In that case, what's the
> meaning of that exact path structure when a) it can't be retrieved from=
> just the address, and b) the values will be stored internally within th=
e
> wallet when you lookup the address.
>=20
> Matt
--8JhuPogBtqRvGQfNhkmqKpMMj3VvAX5Qj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJVhKZrAAoJEET5Y/VjMxhXlC8IAMF+MI9db69Er9yQHJRetxwu
xnUPthy8kp63LN8ntCOH8NLDQiAtxglTSUeepQX7wvWzC4T3JWJERz13hxJEShBB
+bO5m6VD60z5WkF3EqjCHkg6Rv2pTSOaMjJ+T/KSNPCNKwseshPEiwX9I76i6wxW
waMv4B/CVwXUNzuHQRgrOLemcHUjzC+54MhOJCMdgTyNyX2W2gZDeWbnxjeHyc7c
C6VwPdjmXD2s5rcaJb1xbQhFbGMFaeB+S+D8Z3OnNcPat4cUV3fA2CuLIKoNCsE/
/gGDiN5vurF0vYLh0t+nizM4CpM2VtKQVkUOolD7cEpmymVyPPoaxjphpq0QFvs=
=MLwD
-----END PGP SIGNATURE-----
--8JhuPogBtqRvGQfNhkmqKpMMj3VvAX5Qj--
|
