Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 154. (Read 1153691 times)
I tried vanitypool (cool stuff!) and when my miner found a match, miner printed out HTML page to the console ("Thank you for submitting your solution."). Is that HTML dump expected or it is some bug? It definitely looks weird :-).
If anyone is interested I have written a very short Python module wrapper for the vanitygen difficulty calculation. It creates a Python callable function by linking with the vanitygen C source.
I can put it up on my github if there is interest. It's very short but does expose the difficulty calc routine so you can call it from Python and I use it on my Python vanitycoin.com server API as part of estimating the price for vanity requests.
I can put it up on my github if there is interest. It's very short but does expose the difficulty calc routine so you can call it from Python and I use it on my Python vanitycoin.com server API as part of estimating the price for vanity requests.
I would love this. Just started trying to figure out how to calculate this, but I'd rather not reinvent the wheel...
I posted this question in the vanity pool thread, but realized it really belongs here since it's about oclvanityminer.
BTC (per) Mkey (per) Hour
So...
Say you generate 60Mkey/s...
If the BTC/MkeyHr was 0.005, then you'd make (theoretically, its based on luck) 0.005BTC * 60 every hour.
That would just be BTC/hr, and it would be based on your key generation rate. A more sensible value to quote would be just BTC/Mkey. I get the feeling that this is in fact what is shown in the SW, although I haven't looked closely at it yet. On the other hand, there is no reason it couldn't just show BTC/hr in the SW since it knows your keyrate. (Aside: is that the correct term here? Did I just coin that?
)
I finally had a chance to look at the source and apparently the units of the "value" shown are simply BTC/Mkey, but multiplied by 3600, or in code:
This is not BTC/MKeyHr, this is a meaningless number. More correctly, you could say the units are BTC*s/Mkey*hr. I suggest removing the 3600 and just displaying the value as BTC/Mkey. If the number is too small (too many decimals to be easily readable), change it to BTC/Gkey, since most people are calculating at least a Gkey every minute. If you would like to go one step further, you can show BTC/hr as:
Where rate is the calculated Mkey/s for your hardware (so vg_output_timing() will have to been called already).
Yep, just tried out the client for the first time and I see "Value: 0.000022 BTC/MkeyHr," and it picked that over all the other work. What's with the "Hr?"
BTC (per) Mkey (per) Hour
So...
Say you generate 60Mkey/s...
If the BTC/MkeyHr was 0.005, then you'd make (theoretically, its based on luck) 0.005BTC * 60 every hour.
That would just be BTC/hr, and it would be based on your key generation rate. A more sensible value to quote would be just BTC/Mkey. I get the feeling that this is in fact what is shown in the SW, although I haven't looked closely at it yet. On the other hand, there is no reason it couldn't just show BTC/hr in the SW since it knows your keyrate. (Aside: is that the correct term here? Did I just coin that?
)I finally had a chance to look at the source and apparently the units of the "value" shown are simply BTC/Mkey, but multiplied by 3600, or in code:
Code:
wip->value = (reward * 1000000.0 * 3600.0) / difficulty;
This is not BTC/MKeyHr, this is a meaningless number. More correctly, you could say the units are BTC*s/Mkey*hr. I suggest removing the 3600 and just displaying the value as BTC/Mkey. If the number is too small (too many decimals to be easily readable), change it to BTC/Gkey, since most people are calculating at least a Gkey every minute. If you would like to go one step further, you can show BTC/hr as:
Code:
3600 * rate * reward / difficulty
Where rate is the calculated Mkey/s for your hardware (so vg_output_timing() will have to been called already).
I just found this, and I must say, it's awesome! Getting ~30Mkey/s on my 7970 @ 1150/1485.
New site looking for beta testers:
https://bitcoinvanity.appspot.com
Allows the average non-technical user create free, secure (site does not know the private key) vanity addresses.
Currently in Beta, so might take a while to generate addresses but that should speed up soon.
Give it a go and PM me with any issues.
Please do not post replies on this thread - I will open a fresh one in services once out of Beta and with some more power behind it in terms of GPUs.
Hmm perhaps my question wasn't very clear. I'm aware of what you said, what I meant to ask is, does it search within the full (2^256) range of possible private keys or a subset of it. I would have checked the source myself but my C/C++ is a little too rusty...
Hi flatfly,
Vanitygen won't systematically search the entire keyspace. It picks a random spot, checks a few hundred million keys, and moves to another random spot. I didn't think it was even worth making it systematic given how improbable it is that two instances of vanitygen will ever check the same keys, as long as the random number generator is behaving correctly.
It also uses a different random spot for each thread or OpenCL device that's being used to search.
when searching for a vanity pattern, it occured to me that you could match the compressed keys for each generated secret as well. That would double the efficiency/expected ETA of pretty much every query, wouldn't it? Well, perhaps not double, but at least greatly speed it up...
I still have to read about compressed keys, but you're probably correct about this, yes!
BTW kudos on deep space vagabond! I love it.
Thanks for your answers and glad you liked DSV
If anyone is interested I have written a very short Python module wrapper for the vanitygen difficulty calculation. It creates a Python callable function by linking with the vanitygen C source.
I can put it up on my github if there is interest. It's very short but does expose the difficulty calc routine so you can call it from Python and I use it on my Python vanitycoin.com server API as part of estimating the price for vanity requests.
I can put it up on my github if there is interest. It's very short but does expose the difficulty calc routine so you can call it from Python and I use it on my Python vanitycoin.com server API as part of estimating the price for vanity requests.
samr7 - could you give me more info on this. Am I right in thinking I need to understand get_prefix_ranges?
Hi nibor,
What are you trying to do?
To give a base-58 example of how to determine difficulty, let's say you want the prefix 1Boat. The idea is that when you compute the address of a private key, it is almost completely random and unpredictable, and we consider it to have equal probability of being any possible address. So, for the prefix 1Boat, any addresses in the following range would work:
1Boat11111111111111111111111111111 - 1Boatzzzzzzzzzzzzzzzzzzzzzzzzzzzzz
Not all of these are valid addresses due to the checksum part at the very end, but we'll gloss over that.
All you have to do is figure out how many addresses are in that range, call it (matching addresses), and then compute:
difficulty = (total addresses, 2^192) / (matching addresses)
That's the average number of addresses you'll have to test before finding a match.
It gets a little bit more complicated because above we're only considering 34 character addresses, and it's possible to have shorter addresses with the same prefix, addresses that are 33 characters or shorter. In fact, to get a prefix beginning with 1R - 1z, it is only possible using a 33 character address, and this is why those prefixes are so difficult.
Can't get the ocl version to work...
On nvidia:
On nvidia:
Code:
vg_ocl_context_callback error: CL_MEM_OBJECT_ALLOCATION_FAILURE error executing CL_COMMAND_NDRANGE_KERNEL on GeForce GTX 285 (Device 0).
clWaitForEvents(NDRange,0): CL_MEM_OBJECT_ALLOCATION_FAILURE
Device: GeForce GTX 285
Vendor: NVIDIA Corporation (10de)
Driver: 285.62
Profile: FULL_PROFILE
Version: OpenCL 1.0 CUDA
Max compute units: 30
Max workgroup size: 512
Global memory: 1073741824
Max allocation: 268435456
clWaitForEvents(NDRange,0): CL_MEM_OBJECT_ALLOCATION_FAILURE
Device: GeForce GTX 285
Vendor: NVIDIA Corporation (10de)
Driver: 285.62
Profile: FULL_PROFILE
Version: OpenCL 1.0 CUDA
Max compute units: 30
Max workgroup size: 512
Global memory: 1073741824
Max allocation: 268435456
Hi tgbtc,
Try upgrading your NVIDIA driver. That version looks kinda old. Your GTX 285 card should work without question though.
Hmm perhaps my question wasn't very clear. I'm aware of what you said, what I meant to ask is, does it search within the full (2^256) range of possible private keys or a subset of it. I would have checked the source myself but my C/C++ is a little too rusty...
Hi flatfly,
Vanitygen won't systematically search the entire keyspace. It picks a random spot, checks a few hundred million keys, and moves to another random spot. I didn't think it was even worth making it systematic given how improbable it is that two instances of vanitygen will ever check the same keys, as long as the random number generator is behaving correctly.
It also uses a different random spot for each thread or OpenCL device that's being used to search.
when searching for a vanity pattern, it occured to me that you could match the compressed keys for each generated secret as well. That would double the efficiency/expected ETA of pretty much every query, wouldn't it? Well, perhaps not double, but at least greatly speed it up...
I still have to read about compressed keys, but you're probably correct about this, yes!
BTW kudos on deep space vagabond! I love it.
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
Are you talking about the vanity miner or vanitygen?
@samr7:
when searching for a vanity pattern, it occured to me that you could match the compressed keys for each generated secret as well. That would double the efficiency/expected ETA of pretty much every query, wouldn't it? Well, perhaps not double, but at least greatly speed it up...
Or am I just saying nonsense again?
when searching for a vanity pattern, it occured to me that you could match the compressed keys for each generated secret as well. That would double the efficiency/expected ETA of pretty much every query, wouldn't it? Well, perhaps not double, but at least greatly speed it up...
Or am I just saying nonsense again?
legendary
Activity: 1862
Merit: 1011
Reverse engineer from time to time
samr7,
Is it possible for you to comment a little on what the difficulty number represents and how it's calculated. I tried looking thru the code and figuring it out but BN math and probability is definitely not my forte. I ended up being pretty confused.
I'd like to be able to estimate the probability for a prefix pattern in my own code without running vanitygen - if not perfect mathematically then a rough time estimate would work.
Is it possible for you to comment a little on what the difficulty number represents and how it's calculated. I tried looking thru the code and figuring it out but BN math and probability is definitely not my forte. I ended up being pretty confused.
I'd like to be able to estimate the probability for a prefix pattern in my own code without running vanitygen - if not perfect mathematically then a rough time estimate would work.
Hi BkkCoins,
Difficulty is the number of keys that have to be checked, on average, to find a match.
The simplest way to do this is to have a table of prefix difficulties, and for each character after the beginning of the prefix, multiply by 58. For this, you'd have something like:
11 = 256
12-1P = 22
1Q = 65
1R-1z = 1353
So, 1Abc = 22 x 58 x 58 = 74008, and 1egg = 1353 x 58 x 58 = 4551492, which are very close to the exact difficulties. This scheme wouldn't be very accurate for multiple leading 1s, and certain suffixes of 1Q, without special handling of those cases.
The exact, but more complicated way to do this is to follow the formula:
Difficulty = (Total addresses) / (Matching addresses)
The tricky part is figuring out the number of matching addresses. If your keys were 10-digit base-10 numbers, and you wanted to find everything with a prefix of 12345, with no leading 0s, then:
Total keys = 10000000000
Matches = 1234500000 ... 1234599999 = 100000 total matches
Difficulty = 10000000000 / 100000 = 100000, or 1:100000 keys
It's more complex to do this for base-58, but as in the example, the task is to convert a base-58 prefix into ranges of numbers that result in matches. If you're interested, I will post more about this.
samr7,
Is it possible for you to comment a little on what the difficulty number represents and how it's calculated. I tried looking thru the code and figuring it out but BN math and probability is definitely not my forte. I ended up being pretty confused.
I'd like to be able to estimate the probability for a prefix pattern in my own code without running vanitygen - if not perfect mathematically then a rough time estimate would work.
Is it possible for you to comment a little on what the difficulty number represents and how it's calculated. I tried looking thru the code and figuring it out but BN math and probability is definitely not my forte. I ended up being pretty confused.
I'd like to be able to estimate the probability for a prefix pattern in my own code without running vanitygen - if not perfect mathematically then a rough time estimate would work.
Hi BkkCoins,
Difficulty is the number of keys that have to be checked, on average, to find a match.
The simplest way to do this is to have a table of prefix difficulties, and for each character after the beginning of the prefix, multiply by 58. For this, you'd have something like:
11 = 256
12-1P = 22
1Q = 65
1R-1z = 1353
So, 1Abc = 22 x 58 x 58 = 74008, and 1egg = 1353 x 58 x 58 = 4551492, which are very close to the exact difficulties. This scheme wouldn't be very accurate for multiple leading 1s, and certain suffixes of 1Q, without special handling of those cases.
The exact, but more complicated way to do this is to follow the formula:
Difficulty = (Total addresses) / (Matching addresses)
The tricky part is figuring out the number of matching addresses. If your keys were 10-digit base-10 numbers, and you wanted to find everything with a prefix of 12345, with no leading 0s, then:
Total keys = 10000000000
Matches = 1234500000 ... 1234599999 = 100000 total matches
Difficulty = 10000000000 / 100000 = 100000, or 1:100000 keys
It's more complex to do this for base-58, but as in the example, the task is to convert a base-58 prefix into ranges of numbers that result in matches. If you're interested, I will post more about this.
samr7 - could you give me more info on this. Am I right in thinking I need to understand get_prefix_ranges?
Well then I guess I have no idea. I'm a C++ guy in my day job but I haven't looked into the fine details of the BTC algos.
OP hasn't posted for over a month so I'm not sure he's around anymore.
OP hasn't posted for over a month so I'm not sure he's around anymore.
He didn't post from August 2011 till July 2012, he has a life I guess, but I'm sure he hasn't abandoned his useful project.
Nvm, it was actually just a misunderstanding on my part.
EDIT: wasn't easy, but I found the answer I was looking for here:
http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&forum_name=bitcoin-development
EDIT: wasn't easy, but I found the answer I was looking for here:
http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&forum_name=bitcoin-development
Well then I guess I have no idea. I'm a C++ guy in my day job but I haven't looked into the fine details of the BTC algos.
OP hasn't posted for over a month so I'm not sure he's around anymore.
OP hasn't posted for over a month so I'm not sure he's around anymore.
Hmm perhaps my question wasn't very clear. I'm aware of what you said, what I meant to ask is, does it search within the full (2^256) range of possible private keys or a subset of it. I would have checked the source myself but my C/C++ is a little too rusty...
It picks random starting points within the 256 bit private key space and increments from there. So yes it considers the entire 256 bit space.
Sorry to insist, but are you sure? How do compressed private keys (introduced in bitcoind/bitcoin-qt 0.6.0) fit in there? From what I've been able to read, vanitygen doesn't support them and they are actually separate from noncompressed keys (ie, can't be expressed as normal uncompressed base58 keys) - so what proportion of the 2^256 search range do they represent? Or am I totally misunderstanding compressed keys?
Hmm perhaps my question wasn't very clear. I'm aware of what you said, what I meant to ask is, does it search within the full (2^256) range of possible private keys or a subset of it. I would have checked the source myself but my C/C++ is a little too rusty...
It picks random starting points within the 256 bit private key space and increments from there. So yes it considers the entire 256 bit space.
Which gets me wondering, does Vanitygen search the entire keyspace? (*)
If not, what proportion of the entire keyspace does it search?
(*) What about addresses associated with compressed keys?
If not, what proportion of the entire keyspace does it search?
(*) What about addresses associated with compressed keys?
The starting point of a phrase search is random, it gets a private key from the openssl rand ecdsa library and starts searching from there, simply incrementing the key. After searching many addresses for a phrase match, it will again get another random private key. The keys searched and returned with a found vanity phrase in the corresponding Bitcoin address can be from anywhere in the range of valid keys, but certainly it cannot "search the entire keyspace", as that would take somewhere just north of the age of the universe.
Hmm perhaps my question wasn't very clear. I'm aware of what you said, what I meant to ask is, does it search within the full (2^256) range of possible private keys or a subset of it. I would have checked the source myself but my C/C++ is a little too rusty...
Which gets me wondering, does Vanitygen search the entire keyspace? (*)
If not, what proportion of the entire keyspace does it search?
(*) What about addresses associated with compressed keys?
If not, what proportion of the entire keyspace does it search?
(*) What about addresses associated with compressed keys?
The starting point of a phrase search is random, it gets a private key from the openssl rand ecdsa library and starts searching from there, simply incrementing the key. After searching many addresses for a phrase match, it will again get another random private key. The keys searched and returned with a found vanity phrase in the corresponding Bitcoin address can be from anywhere in the range of valid keys, but certainly it cannot "search the entire keyspace", as that would take somewhere just north of the age of the universe.
Jump to: