From: "Matt @ Envrin Group" <matt@envrin•com>
To: Matt Smith <matt@gem•co>, bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?
Date: Sat, 20 Jun 2015 08:58:46 +0700 [thread overview]
Message-ID: <5584C8D6.1050401@envrin.com> (raw)
In-Reply-To: <5584A667.2050205@gem.co>
Say you generate a child key using the path m/6'/4'/7'/99'/0/196, which
is what your proposed path structure would be, and it results in the
address 1DpY7PtPVURvjrGsdAjbZAZ7cL9GD8tc5w.
When the wallet notices a transaction in the blockchain that has
1DpY7PtPVURvjrGsdAjbZAZ7cL9GD8tc5w as an output, it's going to have to
lookup the address within its database to get the values 6/4/7/99/0/196,
as there's no way to retrieve them from just the address. So
technically, you might as well just use m/account'/change/index if using
hardened child keys, or m/change/index if not, as recommended, because
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 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 – 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:
>> 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 variables
>> (purpose, network, asset_type, account, change, index) need to be stored
>> internally within the wallet database, as there's no way to retrieve the
>> 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 the
>> wallet when you lookup the address.
>>
>> Matt
next prev parent reply other threads:[~2015-06-20 1:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-19 20:42 Matt Smith
2015-06-19 21:25 ` Matt @ Envrin Group
2015-06-19 23:31 ` Matt Smith
2015-06-20 0:57 ` Andreas Petersson
2015-06-20 2:40 ` Matt Smith
2015-06-20 1:58 ` Matt @ Envrin Group [this message]
2015-06-20 10:11 ` Jonas Schnelli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5584C8D6.1050401@envrin.com \
--to=matt@envrin$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=matt@gem$(echo .)co \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox