From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z63Vw-0002sH-49 for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 21:07:52 +0000 Received: from mail-pa0-f41.google.com ([209.85.220.41]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z63Vv-00083z-4V for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 21:07:52 +0000 Received: by pacyx8 with SMTP id yx8so92549183pac.2 for ; Fri, 19 Jun 2015 14:07:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=IjeEThhBKcgDal5aHDy8psVxZOL1WJG9Cff3iPrlfPA=; b=UEwzCvtVB0YBdIpRzShFH9sMpeZBthXZAQyQONzfw4md9B7/M/pztlOkQfHQpsE/GE bcFwZrAReZcnESptF9aiXPd9qxtgf/lMRqWM5/rUwErfZrkFsK/98ccX6aLzOCYfGDRI n/4UkT0ivj2tNdK/X3KBZMO8XLgr7lY85eVpFe/9oosX2RAaU5qbMoW5LfUzbH2TdVjH 944YsxHMiQ1+cBHCPRweDY8BRcy96N4QyeYpMK87xorCjx7XMphEIB+LEtxT0YDIbAFZ FzSLAHrtPiNOtRhYv7hya15opCkwtRFF4OFXCrQJUn6qPuGlrvvdeB+YQssjqTUB1V5N 5dNA== X-Gm-Message-State: ALoCoQk21JvhLu+gQHw9Cz5YbA0i9UiT7vJvT6t8UmvXjwc3pZQXzRcvN4cPQMnZ6CDYQKfwqgU2 X-Received: by 10.68.136.134 with SMTP id qa6mr35827376pbb.66.1434746539489; Fri, 19 Jun 2015 13:42:19 -0700 (PDT) Received: from velocity.local (static-108-47-15-123.lsanca.fios.verizon.net. [108.47.15.123]) by mx.google.com with ESMTPSA id l7sm512494pbq.66.2015.06.19.13.42.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2015 13:42:18 -0700 (PDT) Message-ID: <55847E98.3050307@gem.co> Date: Fri, 19 Jun 2015 13:42:00 -0700 From: Matt Smith 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" X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1Z63Vv-00083z-4V Subject: [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: Fri, 19 Jun 2015 21:07:52 -0000 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--