<p>First of all, since a single key can be represented by tons of different address types, let's assume what you meant to ask is about private keys. As @dave_thompson_085 points out, most addresses are actually limited to a 2^160 space by a RIPEMD hash. So that number may be closer to the actual amount of keys you'd need to sweep &quot;all&quot; the bitcoin.</p>
<p>But you are basically correct, the security of ECDSA is based on really big, really random numbers that are so big and so random no one will ever generate the same number as you.</p>
<p>A few details though, from my understanding:</p>
<p>The order of the curve is <code>0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141</code></p>
<p><a href="https://www.secg.org/sec2-v2.pdf" rel="nofollow noreferrer">ref 1</a>
<a href="https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#specification" rel="nofollow noreferrer">ref 2</a></p>
<p>So there is a slightly lower number of possible private keys than just <code>2^256</code></p>
<p>Also, not all Bitcoin outputs require a single key for spending. There are multisig scripts and more complicated spending policies. Assuming you had &quot;all&quot; the private keys and could look them up in a practical way, I suppose you could assemble multisigs where necessary. But that's not all - plenty of transactions are <a href="https://en.bitcoin.it/wiki/Hashlock" rel="nofollow noreferrer">HTLCs</a> which require the pre-image to a hash in addition to a valid signature to spend.</p>
<p>Another thing is that some Bitcoin addresses really are black holes (burn addresses). If an address represents a point that is not on the secp256k1 curve, then there is literally no private key.</p>
<p>Some Bitcoin may also have been sent to unrecoverable scripts like <code>OP_RETURN</code> or scripts that require finding a <a href="https://bitcointalk.org/index.php?topic=293382.0" rel="nofollow noreferrer">hash collision</a>.</p>

CC BY-SA 4.0
2020-08-14T08:16:35.197Z
Privatekeys are slightly under 2^256, but _addresses_ (for txn types that use them, as you note), are 2^160. Which is still more than can be stored in the universe.
dave_thompson_085
CC BY-SA 4.0
2020-08-14T10:42:10.020Z
Good point. Will add
pinhead
CC BY-SA 4.0
2020-08-13T11:26:47.547Z
2020-08-14T10:48:01.113Z
2020-08-14T10:48:01.113Z
pinhead
<p>We know that bitcoin adresses are generated with a 256 bit number(the amount of multiplication  that is used on secp256k1 curve). So there can be 2^256 addresses at most where all the bitcoin sits on. Can we say that if one can somehow get all the bitcoin addresses(I know it is not doable), you get all the bitcoins that is generated/mined ?</p>

<address>
Is it safe to say that all bitcoin that is mined is staying in the bitcoin adresses that is generated between 2^0 and 2^256?
Efe
# Is it safe to say that all bitcoin that is mined is staying in the bitcoin adresses that is generated between 2^0 and 2^256?

(Asked by: username_0 on 2020-08-13)

We know that bitcoin adresses are generated with a 256 bit number(the amount of multiplication that is used on secp256k1 curve). So there can be 2^256 addresses at most where all the bitcoin sits on. Can we say that if one can somehow get all the bitcoin addresses(I know it is not doable), you get all the bitcoins that is generated/mined ?

**Tags:** address


---

## 1 answers

### Answer by username_1 on 2020-08-13. Score: 4

First of all, since a single key can be represented by tons of different address types, let's assume what you meant to ask is about private keys. As @dave\_thompson\_085 points out, most addresses are actually limited to a 2^160 space by a RIPEMD hash. So that number may be closer to the actual amount of keys you'd need to sweep "all" the bitcoin.

But you are basically correct, the security of ECDSA is based on really big, really random numbers that are so big and so random no one will ever generate the same number as you.

A few details though, from my understanding:

The order of the curve is `0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141`

[ref 1](https://www.secg.org/sec2-v2.pdf)
[ref 2](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#specification)

So there is a slightly lower number of possible private keys than just `2^256`

Also, not all Bitcoin outputs require a single key for spending. There are multisig scripts and more complicated spending policies. Assuming you had "all" the private keys and could look them up in a practical way, I suppose you could assemble multisigs where necessary. But that's not all - plenty of transactions are [HTLCs](https://en.bitcoin.it/wiki/Hashlock) which require the pre-image to a hash in addition to a valid signature to spend.

Another thing is that some Bitcoin addresses really are black holes (burn addresses). If an address represents a point that is not on the secp256k1 curve, then there is literally no private key.

Some Bitcoin may also have been sent to unrecoverable scripts like `OP_RETURN` or scripts that require finding a [hash collision](https://bitcointalk.org/index.php?topic=293382.0).

> **Comments:**
> **username_2**: Privatekeys are slightly under 2^256, but _addresses_ (for txn types that use them, as you note), are 2^160. Which is still more than can be stored in the universe.  
> **username_1**: Good point. Will add  

---

