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
|
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 <matt@envrin.com>) id 1Z6843-00076e-Ge
for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 01:59:23 +0000
X-ACL-Warn:
Received: from 2.7a.be.static.xlhost.com ([209.190.122.2] helo=mail.envrin.com)
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Z6842-000784-ME for bitcoin-development@lists.sourceforge.net;
Sat, 20 Jun 2015 01:59:23 +0000
Received: from [192.168.1.2] (unknown [223.205.10.10])
by mail.envrin.com (Postfix) with ESMTPA id 13C9661B4B;
Fri, 19 Jun 2015 22:32:25 -0400 (EDT)
Message-ID: <5584C8D6.1050401@envrin.com>
Date: Sat, 20 Jun 2015 08:58:46 +0700
From: "Matt @ Envrin Group" <matt@envrin.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Matt Smith <matt@gem.co>, bitcoin-development@lists.sourceforge.net
References: <55847E98.3050307@gem.co> <558488D0.50904@envrin.com>
<5584A667.2050205@gem.co>
In-Reply-To: <5584A667.2050205@gem.co>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
0.5 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z6842-000784-ME
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: Sat, 20 Jun 2015 01:59:23 -0000
Say you generate a child key using the path m/6'/4'/7'/99'/0/196, which=20
is what your proposed path structure would be, and it results in the=20
address 1DpY7PtPVURvjrGsdAjbZAZ7cL9GD8tc5w.
When the wallet notices a transaction in the blockchain that has=20
1DpY7PtPVURvjrGsdAjbZAZ7cL9GD8tc5w as an output, it's going to have to=20
lookup the address within its database to get the values 6/4/7/99/0/196,=20
as there's no way to retrieve them from just the address. So=20
technically, you might as well just use m/account'/change/index if using=20
hardened child keys, or m/change/index if not, as recommended, because=20
the wallet will still function the exact same way.
Matt
On 06/20/2015 06:31 AM, Matt Smith wrote:
> I'm not sure I understand your question about the need to store paths i=
n
> 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 chec=
k
> 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 n=
ot
> 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, w=
e
> 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:
>> Hi Matt,
>>
>> 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.
>>
>> I'm a little uncertain as to the relevance though. All those variable=
s
>> (purpose, network, asset_type, account, change, index) need to be stor=
ed
>> internally within the wallet database, as there's no way to retrieve t=
he
>> 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 fro=
m
>> just the address, and b) the values will be stored internally within t=
he
>> wallet when you lookup the address.
>>
>> Matt
|
