<h1>Private keys</h1>
<p>Old wallets used one private key generated randomly by the wallet when first run.</p>
<p>In modern &quot;Hierarchical Deterministic&quot; (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 &quot;derivation path&quot; 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.</p>
<h1>Public keys</h1>
<p>One public key is generated from (along with?) each private key.</p>
<h1>Addresses</h1>
<p>Addresses are constructed from public keys for certain common types of transaction. Not all transactions involve addresses.</p>
<p>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).</p>
<p>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.</p>
<p>So HD wallets have many addresses, it isn't sensible to think of <em>a</em> &quot;wallet address&quot;.</p>
<hr />
<h1>Relationships and Probabilities</h1>
<blockquote>
<p>What is the relationship between a Bitcoin Private Key / Public Key / Address?</p>
</blockquote>
<p>Something not entirely unlike this:</p>
<pre><code>entropy --&gt; random number  --&gt; phrase --&gt; private key --&gt; public key --&gt; address
                   |                        ^   |
                   '------------------------'   +--&gt; private key --&gt; pubkey --&gt; addr
                                                +--&gt; private key --&gt; pubkey --&gt; addr
                                                :
                                                '--&gt; private key --&gt; pubkey --&gt; addr
</code></pre>
<blockquote>
<p>is there a possibility of generating a private key already in use?</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>And, also I'm assuming that a wallet address is a bitcoin address?</p>
</blockquote>
<p>Yes.</p>
<blockquote>
<p>Does each wallet address have a one-one relationship with a private key?</p>
</blockquote>
<p>So far yes.</p>
<p>New types of transactions can be invented and I imagine new types of address could be invented.</p>

CC BY-SA 4.0
2020-12-30T02:59:09.990Z
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
CC BY-SA 4.0
2020-12-30T10:02:35.850Z
@Chris: Yes. But the new wallet must use the same derivation path. Many wallets allow you to choose the derivation path. Some don't.
RedGrittyBrick
CC BY-SA 4.0
2020-12-29T17:48:22.753Z
2020-12-29T17:53:42.640Z
2020-12-29T17:53:42.640Z
RedGrittyBrick
<p>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.</p>
<p>A private key collision is theoretically possible, but practically impossible due to the sheer number of them available on the network (quadrillions+).</p>

CC BY-SA 4.0
2021-11-24T20:51:58.740Z
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
CC BY-SA 4.0
2020-12-29T09:59:38.650Z
2020-12-29T09:59:38.650Z
Travis Patron
<blockquote>
<p>What is the relationship between a Bitcoin Private Key / Public Key / Address?</p>
</blockquote>
<p>The Public Key (a curve point) is equal to the Generator (a fixed curve point) multiplied by the Private Key (an integer).</p>
<p>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).</p>
<blockquote>
<p>is there a possibility of generating a private key already in use?</p>
</blockquote>
<p>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 <strong>is</strong> already in use--see if you can find it!).</p>
<p>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).</p>

CC BY-SA 4.0
2021-11-24T21:40:00.533Z
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).
Pieter Wuille
CC BY-SA 4.0
2021-11-24T22:08:25.013Z
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
CC BY-SA 4.0
2021-11-24T22:09:52.927Z
The part in Nit (1) about multiple address is a valid nit, but maybe too much info for OP to handle? Anyways, I updated the answer to reflect nit 1 as well.
hft
CC BY-SA 4.0
2021-11-24T22:32:50.863Z
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.
Pieter Wuille
CC BY-SA 4.0
2021-11-24T23:06:48.897Z
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
CC BY-SA 4.0
2021-11-24T23:09:42.283Z
I updated the answer. I'm guessing this is probably answered elsewhere on this forum as well...
hft
CC BY-SA 4.0
2021-11-25T14:23:40.553Z
Just so you see where I'm coming from: the pair (y parity, x coordinate) uniquely identifies a point, and thus a hash of that is effectively the same as hashing (x coord, y coord). While just hashing the x coordinate would have a distinguishable outcome: it would imply that negating a private key would not change the hash (because only the y coordinate would change).
Pieter Wuille
CC BY-SA 4.0
2021-11-25T19:20:05.717Z
yep yep, gotcha!
hft
CC BY-SA 4.0
2021-11-24T20:49:43.067Z
2021-11-24T23:09:00.880Z
2021-11-24T23:09:00.880Z
hft
<p>A private key is an integer <code>k</code> from the range (0, <em>n</em>), 0 and <em>n</em> excluded, where <em>n</em> is the order of the generator <code>G</code>, which is 0xFFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141, a number slightly smaller than 2<sup>256</sup>. The public key <code>K</code> is the corresponding elliptic curve point on secp256k1: <code>K = k×G</code>, where <code>G</code> is the base point or generator of secp256k1.</p>
<p>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 2<sup>160</sup> addresses for about 2<sup>256</sup> private keys. Therefore, about 2<sup>96</sup> 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 <a href="https://bitcoin.stackexchange.com/a/100897/5406">explained</a>, the sheer size of the number space makes collisions astronomically unlikely to occur. The question <a href="https://bitcoin.stackexchange.com/q/8804/5406">Is each Bitcoin address unique?</a> goes into more detail.</p>
<p>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 <strong>for most practical purposes you can assume that each address is unique and has a one-to-one relationship with a private key.</strong></p>
<p>Without further context, I would take &quot;wallet address&quot; and &quot;bitcoin address&quot; indeed to refer to the same concept.</p>

CC BY-SA 4.0
2021-11-24T20:55:13.017Z
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
CC BY-SA 4.0
2021-11-24T20:56:15.360Z
See section 2.4.1 here: https://www.secg.org/sec2-v2.pdf
hft
CC BY-SA 4.0
2021-11-24T21:39:19.947Z
Thank you for the note, @hft, I hope this is better.
Murch
CC BY-SA 4.0
2021-11-24T22:13:13.113Z
you are welcome. One other nitpick: it is just SHA256, not SHA256**d** that is applied prior to the RIPEMD-160 hash when forming the unchecksummed address hash.
hft
CC BY-SA 4.0
2021-11-25T13:46:10.370Z
Indeed, thank you for pointing that out. I've corrected my post.
Murch
CC BY-SA 4.0
2020-12-29T13:50:43.963Z
2021-11-25T13:45:42.057Z
2021-11-25T13:45:42.057Z
Murch
<p>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?</p>
<p>Thanks</p>

CC BY-SA 4.0
2020-12-29T13:30:41.480Z
Related: https://bitcoin.stackexchange.com/q/48322/5406, https://bitcoin.stackexchange.com/q/8804/5406, https://bitcoin.stackexchange.com/q/25024/5406, https://bitcoin.stackexchange.com/a/25071/5406
Murch
<address><private-key><address-generation><ecdsa>
What is the relationship between a Bitcoin Private Key / Public Key / Address?
Chris J
# What is the relationship between a Bitcoin Private Key / Public Key / Address?

(Asked by: username_0 on 2020-12-29)

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

**Tags:** address, private-key, address-generation, ecdsa

> **Comments:**
> **username_1**: Related: https://bitcoin.stackexchange.com/q/48322/5406, https://bitcoin.stackexchange.com/q/8804/5406, https://bitcoin.stackexchange.com/q/25024/5406, https://bitcoin.stackexchange.com/a/25071/5406  

---

## 4 answers

### Answer by username_2 on 2020-12-29. Score: 2 | Accepted answer

# 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.

> **Comments:**
> **username_0**: Thanks @username_2!.  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?  
> **username_2**: @username_0: Yes. But the new wallet must use the same derivation path. Many wallets allow you to choose the derivation path. Some don't.  

---

### Answer by username_3 on 2020-12-29. Score: 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+).

> **Comments:**
> **username_4**: 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  

---

### Answer by username_4 on 2021-11-24. Score: 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).

> **Comments:**
> **username_5**: 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).  
> **username_4**: 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.  
> **username_4**: The part in Nit (1) about multiple address is a valid nit, but maybe too much info for OP to handle? Anyways, I updated the answer to reflect nit 1 as well.  
> **username_5**: 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.  
> **username_4**: 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.  
> **username_4**: I updated the answer. I'm guessing this is probably answered elsewhere on this forum as well...  
> **username_5**: Just so you see where I'm coming from: the pair (y parity, x coordinate) uniquely identifies a point, and thus a hash of that is effectively the same as hashing (x coord, y coord). While just hashing the x coordinate would have a distinguishable outcome: it would imply that negating a private key would not change the hash (because only the y coordinate would change).  
> **username_4**: yep yep, gotcha!  

---

### Answer by username_1 on 2020-12-29. Score: 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](https://bitcoin.stackexchange.com/a/100897/5406), the sheer size of the number space makes collisions astronomically unlikely to occur. The question [Is each Bitcoin address unique?](https://bitcoin.stackexchange.com/q/8804/5406) 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.

> **Comments:**
> **username_4**: 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  
> **username_4**: See section 2.4.1 here: https://www.secg.org/sec2-v2.pdf  
> **username_1**: Thank you for the note, @username_4, I hope this is better.  
> **username_4**: you are welcome. One other nitpick: it is just SHA256, not SHA256**d** that is applied prior to the RIPEMD-160 hash when forming the unchecksummed address hash.  
> **username_1**: Indeed, thank you for pointing that out. I've corrected my post.  

---

