Topic: Vanity bitcoin addresses: a new way to keep your CPU busy - page 2. (Read 29764 times)
Anyway to generate a vanity address in windows with the current bitcoin client? My friend wants one.
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.
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.
The wiki says:
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
.
Quote
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
.
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.
I should have known that since the bitcoin client probably does internal checks when generating an address.
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",
$ _
> ./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.
Nope, probably a bug. The address you generated is not a valid bitcoin address.
Hmm, if I quote the regex in the shell, the generated address is shorter:
Does that make sense? I understand addresses have a fixed length.
Code:
$ ./bitcoind getaddressesbyaccount ''
[
"12345Vypv2QSmuRXcciT5oEB27mPbWGeva",
...
]
$ ./bitcoind getnewaddress '' '^11'
...searching...
$ ./bitcoind getaddressesbyaccount ''
[
"11dYT3E4D9QWocteC9bnMzvWaSSqNn8m4",
"12345Vypv2QSmuRXcciT5oEB27mPbWGeva",
...
]
$ ./bitcoind getnewaddress '' ^11
...searching...
$ ./bitcoind getaddressesbyaccount ''
[
"113wjPuzxuDn3WjjautVdQu28DhA8zqhy3",
"11dYT3E4D9QWocteC9bnMzvWaSSqNn8m4",
"12345Vypv2QSmuRXcciT5oEB27mPbWGeva",
...
]
$ _
[
"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.
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.
Thanks for reviving this old thread.
I've added a "vanityAddress" function in my bash lib:
Cool, except it doesn't work...I've added a "vanityAddress" function in my bash lib:
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)
}
# 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!
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).
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
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.
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.
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?
The point is, nothing extra (except electricity) is being consumed by generating vanity addresses. An address that is generated then discarded may as well have never been generated. The network never has any indication that this address ever existed.
maybe a comparison will help: if the world population grew by a factor of a thousand and then every person lived for a thousand years and generated a thousand keys per second while they lived, there would still be no issue with 'wasting' keys.
its not a math issue its a conceptual issue. also lol³ at your "thousand keys per second" analogy for a system that by definition wants to be around 2033.
... it seems like intentionally creating identifiable addresses goes counter to security through anonymity from the get-go ...
obviously, you wouldn't choose a 'vanity' address if you didn't want it to leak some information. but just because bitcoin provides anonymity doesn't mean everyone cares to be anonymous in every transaction.
for example, many people post in this forum under their real names and have bitcoin addresses in their signatures. that involves 'intentionally creating identifiable addresses' in much the same way.
I wonder how many who are doing this realise they are effectively tying the value of their bitcoins to their reputations?
Only their donations are tied (with proper caution) to them and how could you get donations without tying in your rep?
... it seems like intentionally creating identifiable addresses goes counter to security through anonymity from the get-go ...
obviously, you wouldn't choose a 'vanity' address if you didn't want it to leak some information. but just because bitcoin provides anonymity doesn't mean everyone cares to be anonymous in every transaction.
for example, many people post in this forum under their real names and have bitcoin addresses in their signatures. that involves 'intentionally creating identifiable addresses' in much the same way.
I wonder how many who are doing this realise they are effectively tying the value of their bitcoins to their reputations?
Someone mod poclbm (simplest python miner I could find) to use the GPU for address generation. The CPU is so slow!
... it seems like intentionally creating identifiable addresses goes counter to security through anonymity from the get-go ...
obviously, you wouldn't choose a 'vanity' address if you didn't want it to leak some information. but just because bitcoin provides anonymity doesn't mean everyone cares to be anonymous in every transaction.
for example, many people post in this forum under their real names and have bitcoin addresses in their signatures. that involves 'intentionally creating identifiable addresses' in much the same way.
Jump to: