Message-ID: <5584D2B4.6040501@gem.co>
Date: Fri, 19 Jun 2015 19:40:52 -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
References: <55847E98.3050307@gem.co>
	<558488D0.50904@envrin.com>	<5584A667.2050205@gem.co>
	<5584BA85.3050008@petersson.at>
In-Reply-To: <5584BA85.3050008@petersson.at>
OpenPGP: id=FA305457B4CB1A8936558F5844F963F563331857
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="7nNbsoGkm70xmoo7J3f4q3NkXhFv27ixt"
Subject: Re: [Bitcoin-development] Alternate HD path structure: BIP, blog,
 or wat?
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--7nNbsoGkm70xmoo7J3f4q3NkXhFv27ixt
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

> to avoid having an internal mapping from 9'-> 0' to find out what
> blockchain to query, this sounds like it should be trivial for any wall=
et.

Trivial to implement, a headache to *maintain*

But if a new platform is released on an existing blockchain, my wallet
doesn't need to know about the new magic number it claims in order to
handle it correctly.

Say I make a new token layer, BobCoin, which runs on bitcoin and say I
use an HD wallet and always generate new BobCoin token addresses as
m/##'/0'/808'/*'/*/*. If I import that wallet into older HD wallet
software that doesn't know anything about BobCoin, it will still:

- understand what blockchain to query for utxos on the addresses below
that path
- be able to generate valid BobCoin addresses without any updates

I think this is particularly valuable if you're developing against a
platform where updates can't be forced on clients.

To be clear: I am not suggesting this as a general-purpose successor to
BIP44.

=96
Matt Smith | Gem
https://gem.co | GH: @thedoctor


On 6/19/15 5:57 PM, Andreas Petersson wrote:
>> m/##'/0'/99'/0'
>>
>> where 99 is the identifier for, say, counterparty
>=20
>=20
> What is stopping you from using m/44'/9'/a'/c/i as descibed here:
> http://doc.satoshilabs.com/slips/slip-0044.html
>=20
> to avoid having an internal mapping from 9'-> 0' to find out what
> blockchain to query, this sounds like it should be trivial for any wall=
et.
>=20
>=20
> -----------------------------------------------------------------------=
-------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>=20


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

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

iQEcBAEBCAAGBQJVhNK2AAoJEET5Y/VjMxhXj38H/jJzp/krZIbC+H3kBrHVTdlH
Qn41YZ0xfA6nWVdktaSuoNJhcsHGvf5hpVhrMY43T5z64NakcEndQNadOCqGyBmb
jOiWw8/hYGj7T06w5LZ+Gefi/OVf2F0z4MTjzAsQH5X2Ra2wdMS9lAYVdDArfy3t
GPeFgu7r9lUirM1LpyAyFzPVwJRh4jm4RidCPYgoh5t8bbIZOY0UDP9OHZ3uiwLM
Fti5EZ0ILnj5MBK8R2EHYklY2naAOkznLMUvqqAJH4n17RjfJhPjFWcGXKk7/71G
XVPCpACe4SXJel2mSJpdPsy/Hi+eNLn68/5V+Q/zxoAHKkf6hTfuCb77pgp6ZBE=
=8tm9
-----END PGP SIGNATURE-----

--7nNbsoGkm70xmoo7J3f4q3NkXhFv27ixt--