I envision using this in services, so I've not done any work to recommend how the keys would be represented directly in the client (I just map from a seed value and
a hierarchy string in order to deterministic ally derive ECDSA public and private keys).
I'm happy to release my source code for this (Python). But I'd first like to get feedback about any security concerns with my scheme (I note that I don't introduce the enlarged
key space that BIP 32 does with its "chain code" - I'm wondering if that represents a weakness of my scheme vs. BIP 32).
On Mon, Dec 3, 2012 at 12:44 PM, Pieter Wuille
<pieter.wuille@gmail.com> wrote:
On Mon, Dec 03, 2012 at 06:48:34AM -0800, Amir Taaki wrote:
> 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 don't think there is a compelling reason to encourage uncompressed public
keys anymore on the network. They take more space in the block chain for no
additional value whatsoever. Software may of course continue supporting
uncompressed keys if they wish to provide compatibility, but for a new
standard, I think it makes sense to standardize on just compressed keys.
And since that software thus needs to support the compressed encoding,
there is no reason to use a different encoding inside the derivation scheme
itself.
Regarding the encoding itself, it is not hard: just 0x02 or 0x03 (depending
on whether Y is even or odd) followed by the 32-byte encoding of X. Decoding
is harder, but is never needed in the derivation. Software internally can use
any representation (and it will), which in almost all circumstances stores
both X and Y (and even more). Decoding compressed public keys is somewhat
harder, as Y must be reconstructed (but the algorithm isn't hard) - this is
only necessary when someone wants to import an extended public key though for
watch-only wallets.
--
Mike Koss
CTO, CoinLab
(425) 246-7701 (m)