Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WXWZQ-0003rN-Kd for bitcoin-development@lists.sourceforge.net; Tue, 08 Apr 2014 14:00:13 +0000 X-ACL-Warn: Received: from wp059.webpack.hosteurope.de ([80.237.132.66]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WXWZN-0004zU-LF for bitcoin-development@lists.sourceforge.net; Tue, 08 Apr 2014 14:00:12 +0000 Received: from [37.143.74.116] (helo=[192.168.2.2]); authenticated by wp059.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1WXWZH-0005Pw-5O; Tue, 08 Apr 2014 16:00:03 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_96CA6582-346A-47D2-A1A9-F1856A2B561F"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Tamas Blummer In-Reply-To: Date: Tue, 8 Apr 2014 16:00:14 +0200 Message-Id: <41F77B0F-FCC5-4614-A435-7B44257F7A7C@bitsofproof.com> References: <53344FF8.7030204@gk2.sk> To: Pieter Wuille X-Mailer: Apple Mail (2.1874) X-bounce-key: webpack.hosteurope.de; tamas@bitsofproof.com; 1396965609; 6448a492; X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WXWZN-0004zU-LF Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] New BIP32 structure 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: Tue, 08 Apr 2014 14:00:16 -0000 --Apple-Mail=_96CA6582-346A-47D2-A1A9-F1856A2B561F Content-Type: multipart/alternative; boundary="Apple-Mail=_F21F128D-DD75-43EF-8086-F0C23B5651C2" --Apple-Mail=_F21F128D-DD75-43EF-8086-F0C23B5651C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Pieter, your suggestion has charm since =93Bitcoin seed=94 would even not need=20= a global dictionary like the interpretation of the first level, since it = would be self describing. Regards, Tamas Blummer http://bitsofproof.com On 08.04.2014, at 15:53, Pieter Wuille wrote: > I see the cause of our disagreement now. >=20 > You actually want to share a single BIP32 tree across different > currency types, but do it in a way that guarantees that they never use > the same keys. >=20 > I would have expected that different chains would use independent > chains, and have serializations encode which chain they belong to. >=20 > Let me offer an alternative suggestion, which is compatible with the > original default BIP32 structure: > * You can use one seed across different chains, but the master nodes > are separate. > * To derive the master node from the seed, the key string "Bitcoin > seed" is replaced by something chain-specific. > * Every encoded node (including master nodes) has a chain-specific > serialization magic. >=20 > This is in practice almost the same as your suggestion, except that > the m/cointype' in m/cointype'/account'/change/n is replaced by > different masters. The only disadvantage I see is that you do not have > a way to encode the "super master" that is the parent of all > chain-specific masters. You can - and with the same security > properties - encode the seed, though. >=20 > --=20 > Pieter >=20 >=20 > On Tue, Apr 8, 2014 at 3:43 PM, slush wrote: >> tl;dr; >>=20 >> It is dangerous to expect that other seed than "xprv" does not = contain >> bitcoins or that "xprv" contains only bitcoins, because technically = are both >> situations possible. It is still safer to do the lookup; the magic = itself is >> ambiguous. >>=20 >> Marek >>=20 >> On Tue, Apr 8, 2014 at 3:40 PM, slush wrote: >>>=20 >>>=20 >>> Serialization magic of bip32 seed is in my opinion completely = unnecessary. >>> Most of software does not care about it anyway; You can use = xprv/xpub pair >>> for main net, testnet, litecoin, dogecoin, whatevercoin. >>>=20 >>> Instead using the same seed (xprv) and then separate the chains = *inside* >>> the bip32 path seems more useful to me. >>>=20 >>> Marek >>=20 >>=20 >=20 > = --------------------------------------------------------------------------= ---- > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment=20 > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 --Apple-Mail=_F21F128D-DD75-43EF-8086-F0C23B5651C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Pieter,

your suggestion has charm = since =93Bitcoin seed=94 would even not need 
a global = dictionary like the interpretation of the first level, since it would be = self describing.

Regards,

Tamas = Blummer
http://bitsofproof.com

On 08.04.2014, at 15:53, Pieter Wuille <pieter.wuille@gmail.com> = wrote:

I see the cause of our disagreement now.

You = actually want to share a single BIP32 tree across different
currency = types, but do it in a way that guarantees that they never use
the = same keys.

I would have expected that different chains would use = independent
chains, and have serializations encode which chain they = belong to.

Let me offer an alternative suggestion, which is = compatible with the
original default BIP32 structure:
* You can = use one seed across different chains, but the master nodes
are = separate.
* To derive the master node from the seed, the key string = "Bitcoin
seed" is replaced by something chain-specific.
* Every = encoded node (including master nodes) has a = chain-specific
serialization magic.

This is in practice almost = the same as your suggestion, except that
the m/cointype' in = m/cointype'/account'/change/n is replaced by
different masters. The = only disadvantage I see is that you do not have
a way to encode the = "super master" that is the parent of all
chain-specific masters. You = can - and with the same security
properties - encode the seed, = though.

--
Pieter


On Tue, Apr 8, 2014 at 3:43 PM, = slush <slush@centrum.cz> = wrote:
tl;dr;

It is dangerous to = expect that other seed than "xprv" does not contain
bitcoins or that = "xprv" contains only bitcoins, because technically are = both
situations possible. It is still safer to do the lookup; the = magic itself is
ambiguous.

Marek

On Tue, Apr 8, 2014 at = 3:40 PM, slush <slush@centrum.cz> = wrote:


Serialization magic of bip32 = seed is in my opinion completely unnecessary.
Most of software does = not care about it anyway; You can use xprv/xpub pair
for main net, = testnet, litecoin, dogecoin, whatevercoin.

Instead using the same = seed (xprv) and then separate the chains *inside*
the bip32 path = seems more useful to = me.

Marek



----------------= --------------------------------------------------------------
Put = Bad Developers to Shame
Dominate Development with Jenkins Continuous = Integration
Continuously Automate Build, Test & Deployment =
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Clo= udbees
_______________________________________________
Bitcoin-d= evelopment mailing = list
Bitcoin-development@lists.sourceforge.net
https://lists.sourcef= orge.net/lists/listinfo/bitcoin-development


=
= --Apple-Mail=_F21F128D-DD75-43EF-8086-F0C23B5651C2-- --Apple-Mail=_96CA6582-346A-47D2-A1A9-F1856A2B561F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJTRADuAAoJEPZykcUXcTkc3fEH/3mUgcsmIJy96qDmQG5o8l6k FB983TjpvUlSK7mVN/3VmR1R8bqT06TWrlXU6tj6T0kRJm79JBfxrrVHEDpoY4Cv 42Ag/SlJmw2MSwl7RirHPWyfw/07uEM1TnCtHUh04ljY75NeTsbi0rCqjJjn+mfP 9bBNTduu+9+qCf32bu85LODh/Ha0XBb83hsqR6y6QfxD2weiKGZj3kAVrmW8/T/3 rWHzADrHX5bUsLA5tpyCZpD1mxUG4d0K0LyHw0h3HkiW86yb+AyzzGdQKQHxHQyG zGTLAliuym6p9m19MY8lWBoJr2xdfjthpupPdUdPOgVId/P5K5EXIwyrm32R42s= =gD8X -----END PGP SIGNATURE----- --Apple-Mail=_96CA6582-346A-47D2-A1A9-F1856A2B561F--