Vanity bitcoin addresses: a new way to keep your CPU busy

[SgtSpike]

If mining hardware was instead dedicated to generating new addresses; how long do you think would it take till someone stumbled on an existing address that had more BTC stored than what the person would have earned by mining?

I think someone quotes something along the lines of billions of years in a previous discussion regarding this.

I suppose it depends on how efficient your algorithms are, but I wouldn't count on finding anything anytime soon.

[EricJ2190]

If mining hardware was instead dedicated to generating new addresses; how long do you think would it take till someone stumbled on an existing address that had more BTC stored than what the person would have earned by mining?

Never. Even if the whole generating network was behind it, it would probably never even stumble upon a previously used address, much less one that is worth more than the number of blocks it could have generated instead. Generating blocks is trivial compared to this.

Their are 2^160 possible addresses. Lets say 2^32 (4 billion) people use Bitcoin and each generate 2^16 (65 thousand) address. That gives us 2^48 total addresses out of 2^160 possible. The probability of a generated address matching one of these is 1/(2^112). The probably of finding a block at 35 times the current difficulty is around 1/(2^64). Therefore, it would take 2^48 (281 trillion) times longer to find a previously used address. So if it takes you ten minutes to find a block, it will take over five billion years to find a used address.

Now keep in mind that we don't have 4 billion users, most users have far less then 65 thousand addresses, and the current difficulty is much lower then I used in these calculations. Mining sounds a lot more profitable.

NOTE: I assumed generating an address took equal time as generating a proof-of-work hash. However, I believe generating an address is actually slower since it involves both EC key generation and hashing.

[no_alone]

If mining hardware was instead dedicated to generating new addresses; how long do you think would it take till someone stumbled on an existing address that had more BTC stored than what the person would have earned by mining?

Never. Even if the whole generating network was behind it, it would probably never even stumble upon a previously used address, much less one that is worth more than the number of blocks it could have generated instead. Generating blocks is trivial compared to this.

Their are 2^160 possible addresses. Lets say 2^32 (4 billion) people use Bitcoin and each generate 2^16 (65 thousand) address. That gives us 2^48 total addresses out of 2^160 possible. The probability of a generated address matching one of these is 1/(2^112). The probably of finding a block at 35 times the current difficulty is around 1/(2^64). Therefore, it would take 2^48 (281 trillion) times longer to find a previously used address. So if it takes you ten minutes to find a block, it will take over five billion years to find a used address.

Now keep in mind that we don't have 4 billion users, most users have far less then 65 thousand addresses, and the current difficulty is much lower then I used in these calculations. Mining sounds a lot more profitable.

NOTE: I assumed generating an address took equal time as generating a proof-of-work hash. However, I believe generating an address is actually slower since it involves both EC key generation and hashing.

Dont you just like probability

[joan]

If mining hardware was instead dedicated to generating new addresses; how long do you think would it take till someone stumbled on an existing address that had more BTC stored than what the person would have earned by mining?

(…)

Their are 2^160 possible addresses. Lets say 2^32 (4 billion) people use Bitcoin and each generate 2^16 (65 thousand) address. That gives us 2^48 total addresses out of 2^160 possible. The probability of a generated address matching one of these is 1/(2^112).

The probability for two addresses to match is much higher than 1/(2^112) though. It's more complex than doing 2^160/2^48. Check the Birthday attack.
Also, TiagoTiago mentionned using current mining resources to generate addresses, so I guess it's fair to say that the 2^16 figure is underestimated, that would be more like… 2^16 per second. (But there is not 4 billion miners, yet)

While we are on probabilities, and I'm by no means an expert in these, someone mentioned in a previous page of this thread that to find the "1Kahlahan…" vanity address (8 fixed chars) would take roughly 1.28e14 attempts.
I think this is underestimated. (It seems to come from the intuitive 58^8).
My own computation gives me 2.99e+15, which is an order of magnitude higher. (I decode the base58 and do the maths on the hash160).

[Yeti]

Thanks for reviving this old thread.

I've added a "vanityAddress" function in my bash lib:

Cool, except it doesn't work...

Code:

bash: ibase=16; n=${1^^}; while(n>0) { n%3A ; n/=3A }: bad substitution

grondilu, my hero! This script works very nicely without patching the source code (I just use a Bitcoin binary)!

I did the following modifications to make it compatible with GNU Bash 3.x:

Code:

encodeBase58() {
    # 58 = 0x3A
    n=`echo $1 | tr '[:lower:]' '[:upper:]'`
    bc <<<"ibase=16; n=$n; while(n>0) { n%3A ; n/=3A }" |
    tac |
    while read n
    do echo -n ${base58[n]}
    done
}
...
publicKeyToAddress() {
    hash160ToAddress $(openssl ec -pubin -pubout -outform DER 2>/dev/null | tail -c65 | hash160)
}

It found a simple two letter address very quickly. Now if someone could port this to OpenCL, that would be great!

[EricJ2190]

If mining hardware was instead dedicated to generating new addresses; how long do you think would it take till someone stumbled on an existing address that had more BTC stored than what the person would have earned by mining?

(…)

Their are 2^160 possible addresses. Lets say 2^32 (4 billion) people use Bitcoin and each generate 2^16 (65 thousand) address. That gives us 2^48 total addresses out of 2^160 possible. The probability of a generated address matching one of these is 1/(2^112).

The probability for two addresses to match is much higher than 1/(2^112) though. It's more complex than doing 2^160/2^48. Check the Birthday attack.
Also, TiagoTiago mentionned using current mining resources to generate addresses, so I guess it's fair to say that the 2^16 figure is underestimated, that would be more like… 2^16 per second. (But there is not 4 billion miners, yet)

While we are on probabilities, and I'm by no means an expert in these, someone mentioned in a previous page of this thread that to find the "1Kahlahan…" vanity address (8 fixed chars) would take roughly 1.28e14 attempts.
I think this is underestimated. (It seems to come from the intuitive 58^8).
My own computation gives me 2.99e+15, which is an order of magnitude higher. (I decode the base58 and do the maths on the hash160).

The 2^16 figure is just the for the number of addresses actually being used by each normal user, not what you can generate. My point in that part was that there are no more than 2^48 bitcoin addresses that would be of any interest to find a private key for.

For the Birthday Attack, this just means it would be easier to find some two private keys that result in a common but unspecified address. However, we are not looking for any collision here. We specifically are looking for a key with an address in the set of previously used addresses. This is the same as PoW hashing, which I am comparing it with, where we are looking for value with a hash in the set of acceptable hashes.

[dserrano5]

Hmm, if I quote the regex in the shell, the generated address is shorter:

Code:

$ ./bitcoind getaddressesbyaccount ''
[
    "12345Vypv2QSmuRXcciT5oEB27mPbWGeva",
    ...
]
$ ./bitcoind getnewaddress '' '^11'
...searching...
$ ./bitcoind getaddressesbyaccount ''
[
    "11dYT3E4D9QWocteC9bnMzvWaSSqNn8m4",
    "12345Vypv2QSmuRXcciT5oEB27mPbWGeva",
    ...
]
$ ./bitcoind getnewaddress '' ^11
...searching...
$ ./bitcoind getaddressesbyaccount ''
[
    "113wjPuzxuDn3WjjautVdQu28DhA8zqhy3",
    "11dYT3E4D9QWocteC9bnMzvWaSSqNn8m4",
    "12345Vypv2QSmuRXcciT5oEB27mPbWGeva",
    ...
]
$ _

Does that make sense? I understand addresses have a fixed length.

[Yeti]

Nope, probably a bug. The address you generated is not a valid bitcoin address.

[dserrano5]

Nope, probably a bug. The address you generated is not a valid bitcoin address.

bitcoind disagrees:

Code:

$ for I in 113wjPuzxuDn3WjjautVdQu28DhA8zqhy3 11dYT3E4D9QWocteC9bnMzvWaSSqNn8m4 12345Vypv2QSmuRXcciT5oEB27mPbWGeva; do
>     ./bitcoind validateaddress $I |grep -E 'isvalid|address'
> done
    "isvalid" : true,
    "address" : "113wjPuzxuDn3WjjautVdQu28DhA8zqhy3",
    "isvalid" : true,
    "address" : "11dYT3E4D9QWocteC9bnMzvWaSSqNn8m4",
    "isvalid" : true,
    "address" : "12345Vypv2QSmuRXcciT5oEB27mPbWGeva",
$ _

A different installation of bitcoin (version 0.3.21) on a different computer gives the same output.

[Yeti]

Ok, good to know. Then all the "checkAddress" scripts are wrong. They seem to check for a fixed length.

I should have known that since the bitcoin client probably does internal checks when generating an address.

[dserrano5]

The wiki says:

Mainline addresses can be 25-34 characters in length, and testnet addresses can be 26-34 characters in length. Most addresses are 33 or 34 characters long, though.

I had already read that when I first knew about bitcoin, but I read so many things in a couple of days that it's no surprise I've forgotten many of them .

[Yeti]

Yeah, the regex that is used in grondilu's scripts is pretty simple. It just checks for base58 characters and a length of 34. Theymos' PHP script validates the checksum, afai can tell.

grondilu, do you have a newer version of your bash lib with checksum check? Otherwise I'm tempted to port the checksum check to bash.

[Ryland R. Taylor-Almanza]

Anyway to generate a vanity address in windows with the current bitcoin client? My friend wants one.

[BitVapes]

Anyway to generate a vanity address in windows with the current bitcoin client? My friend wants one.

someone posted a working patch for the latest bitcoin source, it compiled fine for me in linux.  I verified it worked by having it "search" for a 1-byte vanity address 'a' and it gave me one.

I let it run for a few minutes trying to find one with 'BitVapes' but I'm sure it would take over 9,000 years.   I did notice it only tied to one cpu core so I kicked off multiple instances to max out my cpus before shutting it down for fear of melting my box on this basically futile but fun effort.

[SgtSpike]

Anyway to generate a vanity address in windows with the current bitcoin client? My friend wants one.

someone posted a working patch for the latest bitcoin source, it compiled fine for me in linux.  I verified it worked by having it "search" for a 1-byte vanity address 'a' and it gave me one.

I let it run for a few minutes trying to find one with 'BitVapes' but I'm sure it would take over 9,000 years.   I did notice it only tied to one cpu core so I kicked off multiple instances to max out my cpus before shutting it down for fear of melting my box on this basically futile but fun effort.

Just curious - does the patch say how many addresses it generates and looks through per second?

[BitVapes]

Just curious - does the patch say how many addresses it generates and looks through per second?

not that I can tell, it just says "Searching..."

[joan]

It should dump a message in the log every 100K attempts though.

[dserrano5]

Just curious - does the patch say how many addresses it generates and looks through per second?

Look in the debug.log for lines like "Vanity key tried 100000". Give it some minutes (20?) to appear though.

What I really miss in the debug log is a timestamp; shouldn't be hard to add even when not being able to say hello in C++ .

[samr7]

I have an observation to make about this.

The parts of the address after the leading "1" would appear to be computed from a pseudorandom integer ranging 0 .. (256^24)-1.

The largest possible value is 33 base-58 digits long, approximately:

23.33798 x 58^32

If the address value is chosen randomly between 0 and the value above, then:

95.715% will be equal or greater than 58^32, and that group will produce an address with 33 characters following the "1", where the first letter is in the set "23456789ABCDEFGHJKLMNPQR".

3.894% will be less than 58^32 and greater than or equal to 256^23.  These will produce an address with 32 characters following the "1", with any base-58 character except "1" as the first letter.

0.391% will be less than 256^23, i.e. the most significant byte is 0.  The base-58 encoder will prefix these with at least two 1s instead of one.

So, the easier vanity addresses start with "23456789ABCDEFGHJKLMNPQR".  If you want a vanity address starting with any letter from "STUVWXYZabcdefghijkmnopqrstuvwxyz", you're going to have to spend a lot more cycles to find it.

[SgtSpike]

I have an observation to make about this.

The parts of the address after the leading "1" would appear to be computed from a pseudorandom integer ranging 0 .. (256^24)-1.

The largest possible value is 33 base-58 digits long, approximately:

23.33798 x 58^32

If the address value is chosen randomly between 0 and the value above, then:

95.715% will be equal or greater than 58^32, and that group will produce an address with 33 characters following the "1", where the first letter is in the set "23456789ABCDEFGHJKLMNPQR".

3.894% will be less than 58^32 and greater than or equal to 256^23.  These will produce an address with 32 characters following the "1", with any base-58 character except "1" as the first letter.

0.391% will be less than 256^23, i.e. the most significant byte is 0.  The base-58 encoder will prefix these with at least two 1s instead of one.

So, the easier vanity addresses start with "23456789ABCDEFGHJKLMNPQR".  If you want a vanity address starting with any letter from "STUVWXYZabcdefghijkmnopqrstuvwxyz", you're going to have to spend a lot more cycles to find it.

Interesting...  I have noticed a lot fewer lower case letters in addresses than upper case, and wondered why that was....