<p>private keys above the group order have the same addresses as the keys starting at 0.</p>

<pre><code>0000000000000000000000000000000000000000000000000000000000000000 fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141  1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a
0000000000000000000000000000000000000000000000000000000000000001 fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364142  1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm
0000000000000000000000000000000000000000000000000000000000000002 fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364143  1LagHJk2FyCV2VzrNHVqg3gYG4TSYwDV4m
0000000000000000000000000000000000000000000000000000000000000003 fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364144  1NZUP3JAc9JkmbvmoTv7nVgZGtyJjirKV1
</code></pre>

<p>...</p>

<pre><code>000000000000000000000000000000014551231950b75fc4402da1732fc9bebb fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffc  1HtRa3HaTfX4eDrTzkZWfnLD9cZAyhMDEd
000000000000000000000000000000014551231950b75fc4402da1732fc9bebc fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffd  1FvN1jJU6kQCub9nQFuJhdfixpBdngxLme
000000000000000000000000000000014551231950b75fc4402da1732fc9bebd fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe  1JHzdjEL4xQ7yifAaQQKAfqPyAN92vfstP
000000000000000000000000000000014551231950b75fc4402da1732fc9bebe ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff  12M4QznuNZH2BRVbLK8SKvNqGTPJpCpST7
</code></pre>

CC BY-SA 3.0
2017-12-25T21:20:38.010Z
The ones larger than the group order are invalid though, something must be doing `mod n` on the numbers to make a pubkey out of them.
arubi
CC BY-SA 3.0
2014-06-18T00:21:35.150Z
2014-06-18T00:21:35.150Z
Willem Hengeveld
<p><strong>Yes,</strong> you can have two keys generate the <em>same address</em>.</p>

<p>There are 2^160 possible addresses, and 2^256 possible private keys, so each address corresponds to roughly 2^(256-160)=2^96 private keys. Any of these will generate the same address and thus be able to spend the money owned by that address. Since 2^160 is so large, however, it would take a near-eternity to find any collisions.</p>

<p>Whether two private keys can generate the <em>same public key</em> is another question. I think the answer is yes, but I am not sure on that. The public key in uncompressed form consists of two 256-bit numbers, which are X and Y coordinates on an elliptic curve. However, the <a href="https://bitcointalk.org/index.php?topic=316350.0">compressed form</a> is just the X coordinate <a href="https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm">plus a bit</a>, from which you can calculate the whole public key. This means the space is (at most) 2^257. Unless there is a one-to-one mapping due to the mathematical properties of the cryptography used, each compressed public key corresponds to roughly 0.5 private keys (with the same distribution you'd get from picking a random number from 1 to 2^257, 2^256 times), so some private keys will collide, while others will not.</p>

<p><em>Actually finding</em> any pair of different private keys that generate the same public key or address would be quite difficult. Either it would involve a huge amount of computation and/or luck, or it would be due to finding a serious vulnerability in the algorithm(s) used.</p>

CC BY-SA 3.0
2014-05-02T20:10:07.847Z
Yes and no. Both keys can be used to spend tx outputs in pay-to-pubkey-hash format (the most common). But if the tx output is in pay-to-pubkey format, then only the private key corresponding to the pubkey can redeem it.
uminatsu
CC BY-SA 3.0
2014-05-02T20:31:04.293Z
@André Yep. It would have a good deal of notoriety if anyone noticed two signatures with different public keys for the same address in the blockchain. And to uminatsu: you're right, if there is a one-to-one mapping of private to public keys. In any case, paying to a pubkey hash gives you 256 bits of security instead of 160 (both are fine for real-world use, so the shorter is nicer for saving space)
Tim S.
CC BY-SA 4.0
2024-10-27T04:28:30.617Z
Yes there is a one-to-one mapping of privatekey to (standard) publickey. Specifically the order of secp256k1 'n' is slightly less than (within the Hasse bound of) the order of the underlying prime field 'p' which is chosen to be slightly less than 2^256. Exactly (n-1)/2 values in GF(p) are valid X values in the curve equation, each of which has exactly two valid Y's, thus the number of points is n-1 which is also the number of integers in 1..n-1. (If you use ONLY the X-coordinate there are indeed collisions, as in BIP340 for Taproot years after your post.)
dave_thompson_085
CC BY-SA 3.0
2014-05-02T17:35:06.867Z
2014-05-02T20:35:16.447Z
2014-05-02T20:35:16.447Z
Tim S.
<p>I know that private key is generated randomly by wallet. Is it possible that wallet generate the same address which is used in Bitcoin?</p>

<p>In other words:
Given two private keys k<sub>a</sub> &ne; k<sub>b</sub>, is it possible that they both generate the same public Bitcoin address?</p>

<address><client><address-generation><key-collision>
Can two private keys generate the same (public) Bitcoin address?
user3473712
# Can two private keys generate the same (public) Bitcoin address?

(Asked by: username_0 on 2014-05-02)

I know that private key is generated randomly by wallet. Is it possible that wallet generate the same address which is used in Bitcoin?

In other words:
Given two private keys ka ≠ kb, is it possible that they both generate the same public Bitcoin address?

**Tags:** address, client, address-generation, key-collision


---

## 2 answers

### Answer by username_3 on 2014-05-02. Score: 23 | Accepted answer

**Yes,** you can have two keys generate the *same address*.

There are 2^160 possible addresses, and 2^256 possible private keys, so each address corresponds to roughly 2^(256-160)=2^96 private keys. Any of these will generate the same address and thus be able to spend the money owned by that address. Since 2^160 is so large, however, it would take a near-eternity to find any collisions.

Whether two private keys can generate the *same public key* is another question. I think the answer is yes, but I am not sure on that. The public key in uncompressed form consists of two 256-bit numbers, which are X and Y coordinates on an elliptic curve. However, the [compressed form](https://bitcointalk.org/index.php?topic=316350.0) is just the X coordinate [plus a bit](https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm), from which you can calculate the whole public key. This means the space is (at most) 2^257. Unless there is a one-to-one mapping due to the mathematical properties of the cryptography used, each compressed public key corresponds to roughly 0.5 private keys (with the same distribution you'd get from picking a random number from 1 to 2^257, 2^256 times), so some private keys will collide, while others will not.

*Actually finding* any pair of different private keys that generate the same public key or address would be quite difficult. Either it would involve a huge amount of computation and/or luck, or it would be due to finding a serious vulnerability in the algorithm(s) used.

> **Comments:**
> **username_4**: Yes and no. Both keys can be used to spend tx outputs in pay-to-pubkey-hash format (the most common). But if the tx output is in pay-to-pubkey format, then only the private key corresponding to the pubkey can redeem it.  
> **username_3**: @André Yep. It would have a good deal of notoriety if anyone noticed two signatures with different public keys for the same address in the blockchain. And to username_4: you're right, if there is a one-to-one mapping of private to public keys. In any case, paying to a pubkey hash gives you 256 bits of security instead of 160 (both are fine for real-world use, so the shorter is nicer for saving space)  
> **username_5**: Yes there is a one-to-one mapping of privatekey to (standard) publickey. Specifically the order of secp256k1 'n' is slightly less than (within the Hasse bound of) the order of the underlying prime field 'p' which is chosen to be slightly less than 2^256. Exactly (n-1)/2 values in GF(p) are valid X values in the curve equation, each of which has exactly two valid Y's, thus the number of points is n-1 which is also the number of integers in 1..n-1. (If you use ONLY the X-coordinate there are indeed collisions, as in BIP340 for Taproot years after your post.)  

---

### Answer by username_1 on 2014-06-18. Score: 2

private keys above the group order have the same addresses as the keys starting at 0.

```
0000000000000000000000000000000000000000000000000000000000000000 fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141  1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a
0000000000000000000000000000000000000000000000000000000000000001 fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364142  1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm
0000000000000000000000000000000000000000000000000000000000000002 fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364143  1LagHJk2FyCV2VzrNHVqg3gYG4TSYwDV4m
0000000000000000000000000000000000000000000000000000000000000003 fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364144  1NZUP3JAc9JkmbvmoTv7nVgZGtyJjirKV1

```

...

```
000000000000000000000000000000014551231950b75fc4402da1732fc9bebb fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffc  1HtRa3HaTfX4eDrTzkZWfnLD9cZAyhMDEd
000000000000000000000000000000014551231950b75fc4402da1732fc9bebc fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffd  1FvN1jJU6kQCub9nQFuJhdfixpBdngxLme
000000000000000000000000000000014551231950b75fc4402da1732fc9bebd fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe  1JHzdjEL4xQ7yifAaQQKAfqPyAN92vfstP
000000000000000000000000000000014551231950b75fc4402da1732fc9bebe ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff  12M4QznuNZH2BRVbLK8SKvNqGTPJpCpST7

```

> **Comments:**
> **username_2**: The ones larger than the group order are invalid though, something must be doing `mod n` on the numbers to make a pubkey out of them.  

---

