Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Tfcsj-0002G6-BB for bitcoin-development@lists.sourceforge.net; Mon, 03 Dec 2012 20:44:49 +0000 X-ACL-Warn: Received: from vps7135.xlshosting.net ([178.18.90.41]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Tfcsh-0008OJ-Al for bitcoin-development@lists.sourceforge.net; Mon, 03 Dec 2012 20:44:49 +0000 Received: by vps7135.xlshosting.net (Postfix, from userid 1000) id 13BB361226; Mon, 3 Dec 2012 21:44:40 +0100 (CET) Date: Mon, 3 Dec 2012 21:44:40 +0100 From: Pieter Wuille To: Amir Taaki Message-ID: <20121203204438.GA30654@vps7135.xlshosting.net> References: <1354542572.51243.YahooMailNeo@web121001.mail.ne1.yahoo.com> <1354546114.71509.YahooMailNeo@web121006.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1354546114.71509.YahooMailNeo@web121006.mail.ne1.yahoo.com> X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: 1.2 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list X-Headers-End: 1Tfcsh-0008OJ-Al Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers 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: Mon, 03 Dec 2012 20:44:49 -0000 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. -- Pieter