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 04:25:36 +0700 [thread overview]
Message-ID: <558488D0.50904@envrin.com> (raw)
In-Reply-To: <55847E98.3050307@gem.co>
[-- Attachment #1: Type: text/plain, Size: 2958 bytes --]
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
On 06/20/2015 03:42 AM, Matt Smith wrote:
> Hey guys,
>
> The crew at Gem is considering a new HD wallet path structure for our
> wallets, which are coin-agnostic, that separates the coin_type field
> into two fields as such:
>
> m / purpose' / network' / asset_type' / account' / change / index
>
> where network refers to the blockchain (0 - bitcoin, 1 - testnet3, 2 -
> litecoin, etc) and the new asset_type refers to the kind of asset to be
> held in accounts below that path (Open Assets, Omni, Counterparty).
>
> The intent is to allow us to validate the address format, select the
> appropriate daemon to scan for tokenized assets, and choose multiple
> blockchain data sources (that may not know anything about token systems
> running on the blockchain they expose) relevant to an HDNode in the
> wallet using only information in the HDNode's path -- without having to
> maintain an explicit mapping of coin_type -> network.
>
> For example, we already have the issue of mapping network identifiers
> because of the lack of standardization across cryptocurrency libraries
> which ends up being ugly and obnoxious to maintain, i.e.
>
> netcode_map = {
> testnet: testnet3,
> bitcoin_testnet: testnet3,
> testnet3: testnet3,
> XTN: testnet3, ...
> }
> netcode_i_want = netcode_map[netcode_returned_by_libwhatever]
>
> We want to avoid maintaining a similar asset_type_to_blockchain mapping.
> Additionally, it would be helpful for utxo selection to exclude utxos
> tied to assets based on path.
>
> BIP43 seems to suggest that we request a BIP number and publish an
> informational BIP specifying the new purpose. If that's not appropriate,
> then maybe we just need to publish the information in a blog post to
> allow any wallet developers who want to to implement
> import_from_gem_structure.
>
> I was also wondering if anyone had previously suggested something
> similar that I missed when cruising the mailing list archives on the
> subject.
>
> Thanks,
> --
> Matt Smith | Gem
> https://gem.co | GH: @thedoctor
>
>
> ------------------------------------------------------------------------------
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 3792 bytes --]
next prev parent reply other threads:[~2015-06-19 21:45 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 [this message]
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
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=558488D0.50904@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