<p>When I read pyramids' answer, I was very skeptical. It didn't really seem right to me that addresses generated from a hash (in this case from a public key) would have anything but a random distribution. To test out the distribution of addresses, I downloaded <a href="https://bitcointalk.org/index.php?topic=267618.0" rel="nofollow noreferrer">the dataset linked to in this forum thread</a> and counted up how many times addresses appeared. There are something like 2.4 million real addresses in this dataset, so I figured it would give me a pretty decent sample size. Sure enough, pyramids was right, I ended up with a count something like this:</p>

<p><img src="https://i.sstatic.net/lgBhG.png" alt="Address Distribution"></p>

<p>As it turns out, you are much more likely to see an address where the second character is 2-Q than anything else. After some research, it turns out that the reason why this is the case is fairly subtle, and requires some background on how addresses are generated. The technical details of how an address is generated are <a href="https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses" rel="nofollow noreferrer">here</a> and <a href="https://en.bitcoin.it/wiki/Base58Check_encoding" rel="nofollow noreferrer">here</a>, but the tl;dr is this:</p>

<ol>
<li>Hash your public key first with SHA-256, and then with RIPEMD-160.</li>
<li>Add a version number and checksum to the above.</li>
<li><strong>Convert the bytes of this value from step 2 to an integer.</strong></li>
<li>Convert the number from step 3 to a base 58 encoded string.</li>
</ol>

<p><strong>NOTE:</strong> The stuff below this statement is very heavily edited from what my original answer was. The original answer was based on some personal research I had done and it turns out that I got it wrong. Thanks to @MeniRosenfeld for correcting me in a comment.</p>

<p>Step number 3 above is where the bias towards addresses starting with characters between 2 and Q is introduced. The data that you have after step 2 is 25 bytes long, but because of the version number that is pre-pended is fixed (0x00 for the Main Network), there are only 24 bytes that add to the integer you produce. With 24 bytes of data, you will never get a number big enough to generate an address where the second character is anything greater than Q. If however, those 24 bytes produce an integer that is less than ~2.6896e56 you can actually base58 encode it in 33 characters instead of 34 during step 4. When you have numbers this size, there is room available to have a number that will generate an address where the second character is any of the characters between 2 and z. Therefore, the reason that it is much more rare to get one of these numbers is that there are simply fewer of them. The addresses that have a second character between R and z can only be addresses that are 33 characters long while the others can be any address that is 34 characters long or any of the addresses that are 33 characters that have a second character between 2 and Q. This is skewed even further by the fact that there are 58 times more addresses with 34 characters than 33 due to the additional length.</p>

<p>It should also be noted that because of the way base58 encoding works, every extra empty byte present at the beginning of the data in step 3 ends up as a 1 added to the beginning of the final address. Therefore, the first bin on the graph doesn't fit in with the others because it is where all addresses of length between 32 and 27 ended up.</p>

CC BY-SA 3.0
2014-01-26T23:46:38.733Z
These aren't addresses which start with a version byte of 0x01. It's the other way around - these are addresses where the pubkey hash has a few more zeros after the 0 version byte, so you get a shorter address. Within these shorter addresses 1s is possible, but there are only 1/58 as many addresses which are 1 character shorter.
Meni Rosenfeld
CC BY-SA 3.0
2014-01-27T04:16:06.560Z
@pyramids - Thanks, I've edited my answer to clear some of this up. Your number is a little off, however. Most addresses are 34 characters, and they can be anywhere between 34 and 27 characters long. See https://en.bitcoin.it/wiki/Address.
TwentyMiles
CC BY-SA 3.0
2014-01-26T22:27:23.537Z
2014-01-27T04:11:44.113Z
2014-01-27T04:11:44.113Z
TwentyMiles
<p>I've generated 10000-50000 key pairs using Chrome Bit Kit app or www.bitaddress.org and have noticed the scarcity of public keys which begin with <strong>1S</strong> and/or <strong>1s</strong>.</p>

<p>Why is this the case?</p>

CC BY-SA 3.0
2013-12-09T12:39:27.410Z
Shall I consider myself lucky? I created my wallet yesterday and I got one starting with 1s.
janosrusiczki
<public-key><bitaddress.org>
Why are Bitcoin addresses starting with 1s or 1S so rare?
Wizard Of Ozzie
# Why are Bitcoin addresses starting with 1s or 1S so rare?

(Asked by: username_0 on 2013-12-09)

I've generated 10000-50000 key pairs using Chrome Bit Kit app or www.bitaddress.org and have noticed the scarcity of public keys which begin with **1S** and/or **1s**.

Why is this the case?

**Tags:** public-key, bitaddress.org

> **Comments:**
> **username_1**: Shall I consider myself lucky? I created my wallet yesterday and I got one starting with 1s.  

---

## 1 answers

### Answer by username_2 on 2014-01-26. Score: 12 | Accepted answer

When I read pyramids' answer, I was very skeptical. It didn't really seem right to me that addresses generated from a hash (in this case from a public key) would have anything but a random distribution. To test out the distribution of addresses, I downloaded [the dataset linked to in this forum thread](https://bitcointalk.org/index.php?topic=267618.0) and counted up how many times addresses appeared. There are something like 2.4 million real addresses in this dataset, so I figured it would give me a pretty decent sample size. Sure enough, pyramids was right, I ended up with a count something like this:

![Address Distribution](https://i.sstatic.net/lgBhG.png)

As it turns out, you are much more likely to see an address where the second character is 2-Q than anything else. After some research, it turns out that the reason why this is the case is fairly subtle, and requires some background on how addresses are generated. The technical details of how an address is generated are [here](https://en.bitcoin.it/wiki/Technical_background_of_Bitcoin_addresses) and [here](https://en.bitcoin.it/wiki/Base58Check_encoding), but the tl;dr is this:

1. Hash your public key first with SHA-256, and then with RIPEMD-160.
2. Add a version number and checksum to the above.
3. **Convert the bytes of this value from step 2 to an integer.**
4. Convert the number from step 3 to a base 58 encoded string.

**NOTE:** The stuff below this statement is very heavily edited from what my original answer was. The original answer was based on some personal research I had done and it turns out that I got it wrong. Thanks to @username_3 for correcting me in a comment.

Step number 3 above is where the bias towards addresses starting with characters between 2 and Q is introduced. The data that you have after step 2 is 25 bytes long, but because of the version number that is pre-pended is fixed (0x00 for the Main Network), there are only 24 bytes that add to the integer you produce. With 24 bytes of data, you will never get a number big enough to generate an address where the second character is anything greater than Q. If however, those 24 bytes produce an integer that is less than ~2.6896e56 you can actually base58 encode it in 33 characters instead of 34 during step 4. When you have numbers this size, there is room available to have a number that will generate an address where the second character is any of the characters between 2 and z. Therefore, the reason that it is much more rare to get one of these numbers is that there are simply fewer of them. The addresses that have a second character between R and z can only be addresses that are 33 characters long while the others can be any address that is 34 characters long or any of the addresses that are 33 characters that have a second character between 2 and Q. This is skewed even further by the fact that there are 58 times more addresses with 34 characters than 33 due to the additional length.

It should also be noted that because of the way base58 encoding works, every extra empty byte present at the beginning of the data in step 3 ends up as a 1 added to the beginning of the final address. Therefore, the first bin on the graph doesn't fit in with the others because it is where all addresses of length between 32 and 27 ended up.

> **Comments:**
> **username_3**: These aren't addresses which start with a version byte of 0x01. It's the other way around - these are addresses where the pubkey hash has a few more zeros after the 0 version byte, so you get a shorter address. Within these shorter addresses 1s is possible, but there are only 1/58 as many addresses which are 1 character shorter.  
> **username_2**: @pyramids - Thanks, I've edited my answer to clear some of this up. Your number is a little off, however. Most addresses are 34 characters, and they can be anywhere between 34 and 27 characters long. See https://en.bitcoin.it/wiki/Address.  

---

