Message-ID: <55847E98.3050307@gem.co>
Date: Fri, 19 Jun 2015 13:42:00 -0700
From: Matt Smith <matt@gem.co>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
	rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="HWGpQ5eAHUfXk1jfBRMqWqa4q4POT0QWF"
Subject: [Bitcoin-development] Alternate HD path structure: BIP, blog,
	or wat?
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HWGpQ5eAHUfXk1jfBRMqWqa4q4POT0QWF
Content-Type: multipart/mixed; boundary="------------080008040000040505010108"

This is a multi-part message in MIME format.
--------------080008040000040505010108
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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 =3D {
  testnet: testnet3,
  bitcoin_testnet: testnet3,
  testnet3: testnet3,
  XTN: testnet3, ...
}
netcode_i_want =3D 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,
=E2=80=93
Matt Smith | Gem
https://gem.co | GH: @thedoctor

--------------080008040000040505010108
Content-Type: application/pgp-keys;
 name="0x63331857.asc"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
 filename="0x63331857.asc"

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBFSRrZIBCADLyCv6gtNVazcvDgxznXQFpIV7glGPDHtgEHDh5MZQctjb+VvS
cpEOwf2Au6IZUtIIWGxUHJZorLikTS5t+eArB/TnCW2rV+u7XM5eU5AS5+9AxX6J
Ac2+s+SB3kVN4bnWwQMhyAIU14q8ifKAy1vinmXmB5lFoBue1v38vYvGQ+pyB82v
IYR183rTVQoNJ/Q69jHq41XeF9KL6McDVcGVpozu2jKMrVBRvHxSiQUrOQ3Fg+aX
4UcZRXz2bocN7h4Tx1G8RxqwAxggv4D4deghqh9F2dhQ3nPROteoQcVvDJ49uPPv
ZHC+fiT4uQ0WqwpgypcES/+Cnp1jg7fXEYrXABEBAAG0L2tleWJhc2UuaW8vaW10
aGVkb2N0b3IgPGltdGhlZG9jdG9yQGtleWJhc2UuaW8+iQEzBBMBCgAdAhsDAwsJ
BwMVCggCHgECF4AFAlVSEUAFCQhFMa4ACgkQRPlj9WMzGFe9ZggAllq2z6dwJ7IW
pf6cxK78uJ6yUUc1pGs47s9+rzxVYk8w9pC5fe9EVitkMNnk+711ZXJHGVvOQ5pe
37dQWtEkhWCy3kSPTL87BW4/VhfBD8SJOY4O5Ede8P4zUGXJ/5geFyt+h8AueU0g
tcV+8DRYjPgYqNvgw5ktix6GlMy3eK48uDDFStv5WNt4yIfCiF6G/RDK+aEMtXBR
TGekwKQEH0d2gkhxgXn4RIMP7lqNNs4MafFVkQXnv9H4JEiMTxH2l6sSrKe3nCi2
WPWO89hLOeqv1Tv+Tu3xwxKKDNuZaGxwDFDQJup6Sam8wrxcvPqcza31whS2oTq3
ENshjosFxbQYTWF0dCBTbWl0aCA8bWF0dEBnZW0uY28+iQE9BBMBCgAnAhsDBQsJ
CAcDBRUKCQgLBRYCAwEAAh4BAheABQJVUhFABQkIRTGuAAoJEET5Y/VjMxhXozEH
/js195So9Bkr55PybKzFX48w/IBRsjqwVQQPbUClN2mXwTt0/MrzDpHZg7BP5KQx
OnERi4y+L/FSUSUcyrN8rVndZXowVr5yN3Cww2fynwuDHkopKewnW69jakV552TT
iK/s6DYwDPM4y5vSrYzUqdoV/d9ebgMaYTYXAKwQY6YX/7F+lYEUerAM6j9jpnv6
0AKqaA/7o0JOxT6q7ibQrIzulJCl9edZl4sxh4oTuCChXcVZ50bCgjuWgswzCIPf
zJ9fQyoR+SBAmXTGcqNaoENU2iH0Id+Rg8JTle4/3BM+blG0BqBz5KCwRgZuIZcj
bgHpX1kqsSY716cr2zBOpr25AQ0EVJGtkgEIAL8RW6weG0rixAX3ZRhlzrKFxgma
583d77id0JRuBz7wS/ACRQgzm+cjoVot9W2jOPrJs2L1RiwceVbQ50YSgouaG92k
Cyuiw0ijON73AxgS7IJGjk3Q8FS5nU6XP3poH1Tol9dYAEViLAAVscpAYNx8IlMM
0gWxlZSYhOoSQI7RG0sHR4u4hjxwsFl/saKjaBmbNaH09YAZ5wEVGKcXCxKuLR9S
nPz1zOsvtgymZEb2sX3/Vnu6e9vy+9oj5w4NFyqOinklUKC9CXe57IG7JxELxTH0
PzYOJKPCTJcUF4R2OOFTRVoDTMH2M0Et7CSMmsMVVENFXzSWXdmyrQ1DtAkAEQEA
AYkBHwQYAQoACQUCVJGtkgIbDAAKCRBE+WP1YzMYV9DCB/45OFdjDmIMcHCc/Xjz
7fffPkRmCjyk7XzWuPlg/6/6DB/lIOcQlYmbVElFY1o1A0ApS2+btWgIso+7/I6u
Wr4RTfZ8dp+mpwQ8irXhgXnRu0VkY8W15FhkWmlzyFzcmNV8FW5LX0piTJ/JmpNX
0qp4xERw0Lb2oPDM1+SWSlOtpGxnIKx4VHuWdIKY5nJka/aQzlU8pYfun4VAQqx4
I3Vc+FqCtfO8FhSLQN+mdsrF7pUw1xx6hF4fpTYjjal7ImrLfedFfADJHBLHtIrA
f5msn7KlKzOiKk33+Wv05qxbAkBg9AjTTzy6sFDpt21IU1t25l09TAF0tfy4Oz7+
p02Q
=3DLfTd
-----END PGP PUBLIC KEY BLOCK-----

--------------080008040000040505010108--

--HWGpQ5eAHUfXk1jfBRMqWqa4q4POT0QWF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJVhH6pAAoJEET5Y/VjMxhXua8H/0LkankGvCTHBR7OEyci6ezf
WGtgRtkbuz2tPWnuB2ISNbXQV+uX4dwFgp3y6YX8etFgZZ3PltQ3ZIaJmzuei7YY
ToTK4I9a08io3kmEwVOUV02EKXE7mChjJsUfYyiPl87sihEnX97v5BisHsYEW4Go
0UbioVb2+pwAIv8lWSn74zv+/nnPcvS6kOIxhfXSsD77CY4ZFKK+NHMVll3ll+RB
68IHV/z86lfk9MnxfEXQA/h2QJHDWgggny8P2YvCPIKLIwsEAiSzpXrYGx4NmzEv
kgnp76PlQgdvlBeX+nLs7aHfkCY92Ot6+hc0tDRr+l71b36E/BaogvHgJh5Frrw=
=krA5
-----END PGP SIGNATURE-----

--HWGpQ5eAHUfXk1jfBRMqWqa4q4POT0QWF--