1

What is the relationship between a Bitcoin Private Key / Public Key / Address? I see that a private key / public key pair is generated, but is there a possibility of generating a private key already in use? And, also I'm assuming that a wallet address is a bitcoin address? Does each wallet address have a one-one relationship with a private key?

Thanks

1

4 Answers 4

2

Private keys

Old wallets used one private key generated randomly by the wallet when first run.

In modern "Hierarchical Deterministic" (HD) wallets. One private key is generated either randomly or derived from a phrase called a seed-phrase or recovery-phrase which itself is generated from a random number. Then many other private keys are generated from this using a "derivation path" which can differ between different brands of wallet. The derivation path is chosen by the developers and some different developers chose different derivation paths. This affects wallet recovery.

Public keys

One public key is generated from (along with?) each private key.

Addresses

Addresses are constructed from public keys for certain common types of transaction. Not all transactions involve addresses.

The most common types of transaction create addresses as a prefix followed by a hash of a public key followed by a checksum (so that typing errors may be detected).

Because HD wallets generate a new address for each transaction, behind the scenes they are using the fixed derivation path to generate new private keys and public keys from which to create the address.

So HD wallets have many addresses, it isn't sensible to think of a "wallet address".


Relationships and Probabilities

What is the relationship between a Bitcoin Private Key / Public Key / Address?

Something not entirely unlike this:

entropy --> random number  --> phrase --> private key --> public key --> address
                   |                        ^   |
                   '------------------------'   +--> private key --> pubkey --> addr
                                                +--> private key --> pubkey --> addr
                                                :
                                                '--> private key --> pubkey --> addr

is there a possibility of generating a private key already in use?

Its about as likely as your home spontaneously changing into a pot of petunias. Which physicists might tell you is theoretically possible but not ever going to occur due to its improbability. The point is we are talking about statistical probabilities involving numbers that are far more vast than most of us have any hope of comprehending because they are far greater than any numbers we routinely encounter or can imagine.

And, also I'm assuming that a wallet address is a bitcoin address?

Yes.

Does each wallet address have a one-one relationship with a private key?

So far yes.

New types of transactions can be invented and I imagine new types of address could be invented.

2
  • Thanks @redgrittybrick!. Explains it well. So, the first private key in your diagram is essentially the crucial part of this scenario? If I have this (since it's my own bitcoin account), then I can simply use it on another wallet provider, and just add my private key there, and the bitcoins will be there for me to send from?
    – Chris J
    Commented Dec 30, 2020 at 2:59
  • @Chris: Yes. But the new wallet must use the same derivation path. Many wallets allow you to choose the derivation path. Some don't. Commented Dec 30, 2020 at 10:02
4

Using Elliptical Curve Digital Signature Algorithm (ECDSA), the private key is used to generate the public key, a secure hash function is then applied to the public key and a checksum appended to produce a Base58 formatted bitcoin address.

A private key collision is theoretically possible, but practically impossible due to the sheer number of them available on the network (quadrillions+).

1
  • 2
    Just to add a little color: the number of private keys is way way way bigger than a quadrillion. It is more than 115 quadrillion quadrillion quadrillion quadrillion quadrillion. The limit on the number of private keys is the order "n" of the Generator, which is "fairly close" to 2 raised to the 256 power. The actual value of "n" is: 115792089237316195423570985008687907852837564279074904382605163141518161494337
    – hft
    Commented Nov 24, 2021 at 20:51
3

What is the relationship between a Bitcoin Private Key / Public Key / Address?

The Public Key (a curve point) is equal to the Generator (a fixed curve point) multiplied by the Private Key (an integer).

There are multiple different kinds of addresses. But, one common type of address is an encoded hash of the public key. (In practice what is hashed is the byte representation of the x-coordinate of the public key with either 0x02 or 0x03 appended to the front to account for the sign of the y-coordinate, and additionally there is some checksum data--just another type of hash--appended prior to encoding).

is there a possibility of generating a private key already in use?

Yes there is. For example, if you choose your private key to be the number 1 then you will have chosen a bad private key (the private key 1 is already in use--see if you can find it!).

However, if you choose your private key at random from integers greater than zero and less than 115792089237316195423570985008687907852837564279074904382605163141518161494337, then you will have a valid key and the chance of a key collision is very very low (because 115792089237316195423570985008687907852837564279074904382605163141518161494337 is very very large).

8
  • 1
    Two nits: (1) there are multiple types of addresses (some encode a hash of a public key, some of a script, and new P2TR ones encode a public key directly), however none of them are a hash of just the x coordinate (P2PKH addresses also hash the parity of the Y coordinate). (2) The number 0 is not a valid private key (and neither is the curve order, as mod n they are the same). Commented Nov 24, 2021 at 21:40
  • Re (2): Yes, I agree, that was inaccurate, I updated the answer to state greater than 0 and less than n. Re (1): Since I didn't specify the hash function, the part in nit (1) about the hash doesn't technically apply. (A hash function that is the action of ripemd160 on the sha256 of '\x02'+x-coordinate is still a hash function. Similarly appending on the checksum is still a hash function.) Since the function can be applied to arbitrary input and produces a fixed size output, it's still a hash function.
    – hft
    Commented Nov 24, 2021 at 22:08
  • 1
    Sure! Perhaps I wasn't clear, my nit is not that you should mention other types, but the fact that what you currently state is wrong: P2PKH addresses are a hash of public keys, but not just of their X coordinate. Commented Nov 24, 2021 at 22:32
  • 1
    OK, I think maybe I see what you are getting at... But I would contend that, in some sense, it is "mostly" the x-coordinate that gets hashed, and only "a little" the y-coordinate (just effectively the sign of y--the y value is implicit). In other words, in practice, the public key (a curve point) must be converted to a byte string in order to be processed by the hash function. This conversion to bytes is performed by converting the x-coordinate to a byte string and then appending either 0x02 or 0x03 to the front of the byte string to account for the sign of the y-coordinate.
    – hft
    Commented Nov 24, 2021 at 23:06
  • 1
    I updated the answer. I'm guessing this is probably answered elsewhere on this forum as well...
    – hft
    Commented Nov 24, 2021 at 23:09
3

A private key is an integer k from the range (0, n), 0 and n excluded, where n is the order of the generator G, which is 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141, a number slightly smaller than 2256. The public key K is the corresponding elliptic curve point on secp256k1: K = k×G, where G is the base point or generator of secp256k1.

A Pay to Public Key Hash (P2PKH) address is derived from the public key by first applying a SHA256 hash and then a RIPEMD-160 hash. The address is then encoded using Base58Check. This means that there are only 2160 addresses for about 2256 private keys. Therefore, about 296 private keys map to each address. Since there is no central registration of addresses after they are generated, there is no mechanism to prevent key collisions, but as Travis already explained, the sheer size of the number space makes collisions astronomically unlikely to occur. The question Is each Bitcoin address unique? goes into more detail.

By now, there are a number of different address types that can be derived from the same private keys. So strictly speaking, there can be multiple addresses associated with the same private key, but for most practical purposes you can assume that each address is unique and has a one-to-one relationship with a private key.

Without further context, I would take "wallet address" and "bitcoin address" indeed to refer to the same concept.

5
  • I think the range of the private key is actually limited to the order "n" of the generator, which is close to 2**256, but not equal to it. The order is 115792089237316195423570985008687907852837564279074904382605163141518161494337
    – hft
    Commented Nov 24, 2021 at 20:55
  • See section 2.4.1 here: secg.org/sec2-v2.pdf
    – hft
    Commented Nov 24, 2021 at 20:56
  • 1
    Thank you for the note, @hft, I hope this is better.
    – Murch
    Commented Nov 24, 2021 at 21:39
  • 1
    you are welcome. One other nitpick: it is just SHA256, not SHA256d that is applied prior to the RIPEMD-160 hash when forming the unchecksummed address hash.
    – hft
    Commented Nov 24, 2021 at 22:13
  • 1
    Indeed, thank you for pointing that out. I've corrected my post.
    – Murch
    Commented Nov 25, 2021 at 13:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.