Bitcoin Forum
April 30, 2024, 11:45:39 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How many public base58 addresses exist for a given private key?  (Read 3250 times)
flatfly (OP)
Legendary
*
Offline Offline

Activity: 1078
Merit: 1011

760930


View Profile
October 06, 2012, 08:34:20 PM
Last edit: October 06, 2012, 08:44:47 PM by flatfly
 #1

TIL that one private key corresponds to more than one public (base58) address.
(Yeah, I admit I'm still a newbie for these things...)


The question is, how many of those public base58 addresses exist for one given private key?

Is the answer 2 (one "regular" and one "compressed") ?

[EDIT] By private key, I mean "32-byte secret', in case that matters.
I HATE TABLES I HATE TABLES I HA(╯°□°)╯︵ ┻━┻ TABLES I HATE TABLES I HATE TABLES
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714477539
Hero Member
*
Offline Offline

Posts: 1714477539

View Profile Personal Message (Offline)

Ignore
1714477539
Reply with quote  #2

1714477539
Report to moderator
1714477539
Hero Member
*
Offline Offline

Posts: 1714477539

View Profile Personal Message (Offline)

Ignore
1714477539
Reply with quote  #2

1714477539
Report to moderator
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1072
Merit: 1174


View Profile WWW
October 07, 2012, 12:23:18 AM
 #2

That is correct; a compressed and an uncompressed one.

EDIT: Bitcoin private keys in base58 wallet import format have a marker to distinguish the compressed and uncompressed one, although it is technically not part of the secret key. An importing wallet must know which address to associate with it though (and associating it to both would be wasteful and not useful, as keys should only be used once anyway).

I do Bitcoin stuff.
flatfly (OP)
Legendary
*
Offline Offline

Activity: 1078
Merit: 1011

760930


View Profile
October 07, 2012, 05:20:54 AM
Last edit: October 07, 2012, 08:25:21 AM by flatfly
 #3

Thanks Pieter. Is it easy to compute the uncompressed equivalent public address from:

- the compressed public address
+ the private key expressed in WIF compressed format

- the compressed public address alone?
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
October 07, 2012, 07:13:09 AM
 #4

Well, there is really only one public key for a given private key.  The two forms are just different expressions for the same thing.

We start by picking a private key k which is just a 256 bit integer.  Then we multiply (EC multiplication, not regular) a defined base point on the curve by k.  That gives us a point on the plane, two 256 bit integers, x and y(x, y) is our public key.  It turns out that if we know x, we can almost calculate y pretty easily.  I say almost calculate, because there is a square root, so we find two possible values for y, one positive and one negative.  So, we can "compress" the public key by giving x, and the sign of y, 257 bits instead of 512.  (In practice it is 272 vs 520, but whatever.)

It is easy to calculate the full public key using either the compressed key, or the private key.  Private keys are scalars, not points, so they can't be "compressed".

To calculate the public key from the private key, it is just G*kG is the base point defined in sec2 for secp256k1 (the curve we use).

To calculate it from the compressed key, the magnitude of y is sqrt(x3+7).  You already have x because it is stored normally in the compressed key, along with z which tells you the sign of y.

The bitcoin address is calculated by hashing the public key.  I think the hash is always performed using the full point, and I know that using the full point works, because I've calculated addresses using the uncompressed key, sent coins to them, and spent them using the corresponding private key.  I don't think that starting the hash process using a compressed key will work, but it is late, and I don't feel like digging through the code to find out for sure.  Hopefully someone will chime in.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1072
Merit: 1174


View Profile WWW
October 07, 2012, 01:02:28 PM
 #5

The bitcoin address is calculated by hashing the public key.  I think the hash is always performed using the full point, and I know that using the full point works, because I've calculated addresses using the uncompressed key, sent coins to them, and spent them using the corresponding private key.  I don't think that starting the hash process using a compressed key will work, but it is late, and I don't feel like digging through the code to find out for sure.  Hopefully someone will chime in.

Actually, that is exactly what is done. A base58 address corresponding to a compressed public key is formed by using the normal encoding process (base58(0x00 + ripemd160(sha256(pubkey)) + checksum)) on the compressed public key. You can't even tell from an address which type of key was used. That is why it works in a backward-compatible way: old verifying nodes don't know anything about compressed public key, but their software (which uses OpenSSL) accepts compressed public keys as public keys, so the verification works, and the hash also works out fine.

I do Bitcoin stuff.
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
October 07, 2012, 04:03:17 PM
 #6

Hmm.  That's interesting.  That means that the wallet has to keep track of both versions, and it has to be ready to use either one to redeem txouts.  Or at the very least, it has to when importing a private key.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1072
Merit: 1174


View Profile WWW
October 07, 2012, 04:05:19 PM
 #7

No, only one of both is used. There is no point is having both: which address/pubkey is used, is decided at key generation time, and only one address is ever exposed. There is no reason to expect payments to an address that was never given out.

I do Bitcoin stuff.
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
October 07, 2012, 04:22:59 PM
 #8

No, only one of both is used. There is no point is having both: which address/pubkey is used, is decided at key generation time, and only one address is ever exposed. There is no reason to expect payments to an address that was never given out.

But when you import a private key, the WIF doesn't tell the client which of the two (or maybe three*) addresses has been used with it.

* Is the hybrid format also valid?

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Pieter Wuille
Legendary
*
qt
Offline Offline

Activity: 1072
Merit: 1174


View Profile WWW
October 07, 2012, 04:27:57 PM
 #9

EDIT: Bitcoin private keys in base58 wallet import format have a marker to distinguish the compressed and uncompressed one, although it is technically not part of the secret key. An importing wallet must know which address to associate with it though (and associating it to both would be wasteful and not useful, as keys should only be used once anyway).

I do Bitcoin stuff.
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1386
Merit: 1136


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
October 07, 2012, 04:38:48 PM
 #10

There is a different encoding for denoting a private key should be converted to a bitcoin address using compressed notation, the encoding currently makes the private key start with "L" or a nearby letter rather than the number 5.

Which, incidentally, I believe should be changed so that the private key code still starts with 5, but starts with 5P,5Q,5R (or a similarly different set of prefixes) instead of 5J,5K,5L, so as to not lead users to ask unnecessary questions about why it's different, but still keeping it visually discernible for those who have an interest in the compress flag.  (the different prefix would be achieved by using 0x82 in place of 0x80 as the first byte... we skip 0x81 so as to avoid both sets containing '5L' prefixes)

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper or hardware wallets instead.
kjj
Legendary
*
Offline Offline

Activity: 1302
Merit: 1024



View Profile
October 07, 2012, 04:58:01 PM
 #11

Hmm.  Looks like the wiki is out of date then.

By the way, I'm sure that this was discussed at the time, but this seems like a really odd way to resolve the ambiguity.

17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8
I routinely ignore posters with paid advertising in their sigs.  You should too.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!