The wiki entry on Address says:
Some Bitcoin addresses can be shorter than 34 characters (as few as 27 in theory) and still be valid. [...] These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.
Alright, but according to this diagram, a main-network address is:
Base58Check(00 ++ RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY)) ++ checksum)
Next we look at the entry for Base58Check and we see step 4 is:
4) Treating the results of step 3 - a series of bytes - as a single big-endian bignumber, convert to base-58 using normal mathematical steps (bignumber division) and the base-58 alphabet described below. The result should be normalized to not have any leading base-58 zeroes (character '1').
First strange thing - if it's treated as a single big-endian number, shouldn't prepending the main network byte of 00 not have any effect? Since that is the most significant byte it'd be like writing 00123 instead of 123 in regular notation, no?
Second strange thing - if the result should be normalized to have no leading zeroes, doesn't that mean that the output should never have any 1s in it? Step 5 seems contradictory to this
5) The leading character '1', which has a value of zero in base58, is reserved for representing an entire leading zero byte, as when it is in a leading position, has no value as a base-58 symbol. There can be one or more leading '1's when necessary to represent one or more leading zero bytes. Count the number of leading zero bytes that were the result of step 3 (for old Bitcoin addresses, there will always be at least one for the version/application byte; for new addresses, there will never be any). Each leading zero byte shall be represented by its own character '1' in the final result.
It seems step 4 would have stripped out any possible leading bytes. However, in the case that it didn't, and for some reason it didn't with the prepended 00 byte, shouldn't an address have multiple leading 1s, e.g. 11175tWpb... instead of simply being shorter, e.g. 175tWpb...?
EDIT: Ok, it seems that what it is saying is that given payload X, base58(X) is normalized to remove the zeroes, and then you prepend a 1 for each leading byte of X, not base58(X). It still raises the question of why addresses are shorter instead of having multiple 1s. Is it that the RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY)) happens never to have too many leading 0s (which would be prepended as 1s) while base58(RIPEMD160(SHA256(04 ++ pubkeyX ++ pubkeyY))) does (and they are cut out of the final result)?
