From: Matt Smith <matt@gem•co>
To: "Matt @ Envrin Group" <matt@envrin•com>,
bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Alternate HD path structure: BIP, blog, or wat?
Date: Fri, 19 Jun 2015 16:31:51 -0700 [thread overview]
Message-ID: <5584A667.2050205@gem.co> (raw)
In-Reply-To: <558488D0.50904@envrin.com>
[-- Attachment #1: Type: text/plain, Size: 2380 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2015-06-19 23:32 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 [this message]
2015-06-20 0:57 ` Andreas Petersson
2015-06-20 2:40 ` Matt Smith
2015-06-20 1:58 ` Matt @ Envrin Group
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=5584A667.2050205@gem.co \
--to=matt@gem$(echo .)co \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=matt@envrin$(echo .)com \
/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