From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z68iP-00005f-Gg for bitcoin-development@lists.sourceforge.net; Sat, 20 Jun 2015 02:41:05 +0000 Received: from mail-pd0-f178.google.com ([209.85.192.178]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z68iO-0008Ga-G1 for bitcoin-development@lists.sourceforge.net; Sat, 20 Jun 2015 02:41:05 +0000 Received: by pdjn11 with SMTP id n11so101995882pdj.0 for ; Fri, 19 Jun 2015 19:40:58 -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:references:in-reply-to:openpgp:content-type; bh=X3v5QMqkjQg4LMMf6LaNqMirVoSLLTsweTLm/6W9oXg=; b=RrH5O1SsXTD6Jqv6mQUetIqPgv1p8Khg4jYwLhW+l3ygoQYmx7pAdQ5EdGzLtfDl0n +G4nF/l6I//agAFYQ6zzys1EDX0pE5OuXh7cy46MlCS0CTybAaILyESRt2k7d+4Tpk+3 RqNjFSSsL9b7RoKjWa5Bz8fdryFweE2a4CD2qhMalg/80t4oZCaH5g74vNV4VEr2SFJN Pbr1TNyDv1fE/yB6OBRWYBFXsM9/OeH/x36e2/UiBIlWS6dcJGYN7a1WXwsbblrtlptm FJZWobHv3yWpvuotA8HWE03SVwNZj5sG86eZGk8RM8U9kbEPtdaQ/sykbAO/VbIUsmTE Vs0w== X-Gm-Message-State: ALoCoQnt7o2Bq0nwZiuBRlumvtlCAc03eletB4OlimRz8WZCVOIYMlqrDQti22FW6WjhkFLgPRda X-Received: by 10.66.236.226 with SMTP id ux2mr38116335pac.64.1434768058765; Fri, 19 Jun 2015 19:40:58 -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 x16sm12478162pbt.87.2015.06.19.19.40.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jun 2015 19:40:57 -0700 (PDT) Message-ID: <5584D2B4.6040501@gem.co> Date: Fri, 19 Jun 2015 19:40:52 -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 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" 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: 1Z68iO-0008Ga-G1 Subject: Re: [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: Sat, 20 Jun 2015 02:41:05 -0000 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--