From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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" 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 , 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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