ok, also what is the reasoning behind serialising points using a compressed format before going into the hash function? I'm looking at the sec1-v2.pdf and the compression format is a little confusing.
I think the octet string for X is 32 bytes (using q = curve.order) and secp256k1 is a prime field so we follow step 2.2.1 ________________________________ From: Pieter Wuille <pieter.wui...@gmail.com> To: Amir Taaki <zgen...@yahoo.com> Cc: "bitcoin-development@lists.sourceforge.net" <bitcoin-development@lists.sourceforge.net> Sent: Monday, December 3, 2012 2:54 PM Subject: Re: [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers On Mon, Dec 3, 2012 at 2:49 PM, Amir Taaki <zgen...@yahoo.com> wrote: Can this be amended? I think it makes much more sense to allow people to input labels not numbers at this level. > >General category names for different accounts is much more human than numbers, >and you can still use incrementing numbers if you prefer. > There is no way to iterate over all strings. The intention is that a wallet application can detect a new account that becomes in use (e.g. during disaster recovery), so the accounts get assigned incrementing numbers. I wouldn't mind adding the ability to do "non-standard derivations" using arbitrary strings, if this recoverability property is not desired. -- Pieter ------------------------------------------------------------------------------ Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
