Bitcoin Forum
December 16, 2017, 05:02:15 PM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
   Home   Help Search Donate Login Register  
Pages: [1]
Author Topic: Converting public keys to compressed public keys  (Read 4262 times)
Hero Member
Offline Offline

Activity: 630

My PGP Key: 92C7689C

View Profile WWW
May 14, 2013, 09:04:24 PM

This is just a quick sanity check, as I didn't find much on the matter that was definitive, but I want to make sure I'm doing the right thing with my deterministic wallet manager.

I wanted to implement support for compressed addresses.  I figured out compressed private WIF keys quickly enough: tack on 01 to the end of the private hexadecimal key and base58-encode it.  Handling of the public key wasn't as well-documented.  I tried looking at and the Casascius address utility source for some clues, but the latter calls a library not available for this project and I couldn't quite make sense of the former.

If I have it right, it turned out to be nearly as simple:  split the public key (less the leading 04) in half and look at the last digit of the second half.  If that digit is even, prepend the first half with 02; if odd, prepend the first half with 03.  Push the result through the same hash and base58-encoding process to get the compressed address. 

Does this sound right?

Going the other way (from a compressed public key to an uncompressed public key) looks like it'd be much more involved, but I don't need that functionality for what I'm doing.

(If anyone's interested, the aforementioned deterministic wallet manager includes some Python code with no bignum or ECDSA dependencies that calculates addresses and private keys from hexadecimal private keys.  In its current form, it decodes to Bitcoin or Litecoin addresses, in either compressed or uncompressed format.)

My Bitgem Pool - PPLNS, Stratum | BTG Explorer
Tipjars: BTC 1TipsGocnz2N5qgAm9f7JLrsMqkb3oXe2 LTC LTipsVC7XaFy9M6Zaf1aGGe8w8xVUeWFvR BTG gTipsVB9qmyYHuqMMKTuCYMHpfkUFBXKrZ | My Bitcoin Note Generator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Hero Member
Offline Offline

Posts: 1513443735

View Profile Personal Message (Offline)

Reply with quote  #2

Report to moderator
Offline Offline

Activity: 1302

View Profile
May 14, 2013, 09:17:58 PM

Yup, you have it right, at least functionally.

The pubkey is structured data with a eight bit header followed by one or two fields of 256 bits each.  The first field is X and is always present.  The second field is Y, and is only present when the header is 0x04.  Stripping off the 0x04 and taking the first half is the same operation as unpacking the X value, so what you are doing is exactly right.  I just like to explain it in detail so that other people reading this thread will understand what that operation represents logically.

You just need to keep track of whether you are compressing or not.  If you are using the compressed form, you must use the compression flag in the WIF.  Even though they represent the exact same idea, the compressed WIF won't work with the uncompressed pubkey, nor the reverse.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
Offline Offline

Activity: 15

View Profile
May 16, 2013, 01:50:04 AM

Keep in mind that the compressed and uncompressed public keys have different hashes, and thus result in different Bitcoin addresses.  You need the right one to unlock a Txout.
Pages: [1]
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!