btw I am finding vanity addresses aiming for with lower case are much harder to compute seemingly, 1 out of 58 I generated so far with vanitygen -i are lower first char. I think there maybe a target range miscalculation in vanitygen that is discarding valid finds? Clearly all start strings are possible because 1zzz finds lots and so does 1111. The alphabet is [1-0][A-Z][a-z] and strings before 1QQQ are easier. Except 1111 is harder. I am not really understanding why this is. OpenSSL doco says it uses big endian encoding. And the base58 encoder seems to use the same convention, so you would expect restrictions on the most significant digit. However that doesnt seem to be the case empirically.
The address is encoded as 0x1 || hash(160-bits) || checksum(32-bits) which is 193-bits. Now log(58,2^193) = 32.9465 and 2^193/58^32 = 46.676 however the bignum is encoded big endian
Adam
The change happens at a particular address
This is a result of how the 25-byte (50 digit hexadecimal) underlying hashes are converted into Base58 (represented by numbers and letters) addresses, and the different maximum values that can be stored in 25 base256 digits vs 34 base58 digits.
The Bitcoin address in it's native binary form (that you never see) is 25 bytes, it's parts are:
byte 0: Network ID Byte (0x00 for main bitcoin network)
byte 1-20: ripemd160 hash (20 bytes) of sha256 hash (32 bytes) of 0x04+public key (65 bytes)
byte 21-24: checksum: first four bytes of sha256 hash of sha256 hash of bytes 0-20 above
This would be 50 hexadecimal characters long (base16), with a possible digit value between 0-F - 24 bytes or 48 hexadecimal digits of random hash output, plus the beginning "00" byte.
We will ignore byte 0, it is always 0x00, and Base58 conversion always preserves this leading 0 byte by directly encoding it as a "1".
That means the "vanity" part of the address is generated by the first several bytes of the underlying ripemd160 hash
The minimum this can be is
0000000000000000000000000000000000000000 00000000.
The maximum value that this can be is
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF ffff ffff(the extra 0s and lower case "f"s are the checksum part.)
Here are some sample addresses before and after the "wraparound" of the maximum hash value.
See how the 1QL
a addresses are full length, but the 1QL
c addresses are one digit shorter? That is because the only way to have an address starting at 1QLc or greater is by having a binary address that is 59x smaller. There are 59x less possible hashes that will generate a 33 character 1aaaa address than will generate a 34 character 1AAAA address.
