Why are Bitcoin addresses starting with 1s or 1S so rare? 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?
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 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:



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 and here, but the tl;dr is this:


Hash your public key first with SHA-256, and then with RIPEMD-160.
Add a version number and checksum to the above.
Convert the bytes of this value from step 2 to an integer.
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 @MeniRosenfeld 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.