flatfly
Legendary
Offline
Activity: 1120
Merit: 1016
090930
|
|
October 05, 2012, 10:59:36 AM Last edit: October 06, 2012, 08:33:59 AM by flatfly |
|
|
|
|
|
malevolent
can into space
Legendary
Offline
Activity: 3472
Merit: 1725
|
|
October 05, 2012, 02:43:57 PM |
|
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.
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.
|
Signature space available for rent.
|
|
|
nibor
|
|
October 07, 2012, 10:45:22 AM |
|
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.
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?
|
|
|
|
Remember remember the 5th of November
Legendary
Offline
Activity: 1862
Merit: 1011
Reverse engineer from time to time
|
|
October 07, 2012, 10:53:44 AM |
|
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.
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. How did you come up with this algorithm?
|
BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
|
|
|
flatfly
Legendary
Offline
Activity: 1120
Merit: 1016
090930
|
|
October 08, 2012, 05:45:30 PM Last edit: October 08, 2012, 06:01:31 PM by flatfly |
|
@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?
|
|
|
|
Remember remember the 5th of November
Legendary
Offline
Activity: 1862
Merit: 1011
Reverse engineer from time to time
|
|
October 10, 2012, 08:38:48 PM |
|
Are you talking about the vanity miner or vanitygen?
|
BTC:1AiCRMxgf1ptVQwx6hDuKMu4f7F27QmJC2
|
|
|
samr7 (OP)
Full Member
Offline
Activity: 140
Merit: 430
Firstbits: 1samr7
|
|
October 12, 2012, 06:01:01 AM |
|
Can't get the ocl version to work... On nvidia: 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 Hi tgbtc, Try upgrading your NVIDIA driver. That version looks kinda old. Your GTX 285 card should work without question though. on 7970: (seems it is finding matches, but disregarding due to mismatch? CPU hash: 6707a76e848f5e9368c2d9d9ec6d60880df44891 GPU hash: 020b0bda39a9bbb2eeddd194a8be20934835dff6 Found delta: 94027 Start delta: 1
When you get the CPU hash/GPU hash mismatch, it means the OpenCL device is producing incorrect results. I have not had a chance to test it on an AMD 7XXX series GCN card yet, but others have reported that it works. Try running it with -V on that card for a little while and see what you get. Since it's producing incorrect results, the performance numbers may or may not mean anything. 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.
|
|
|
|
samr7 (OP)
Full Member
Offline
Activity: 140
Merit: 430
Firstbits: 1samr7
|
|
October 12, 2012, 06:20:39 AM |
|
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.
|
|
|
|
BkkCoins
|
|
October 12, 2012, 06:48:13 AM |
|
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.
|
|
|
|
flatfly
Legendary
Offline
Activity: 1120
Merit: 1016
090930
|
|
October 14, 2012, 11:29:40 AM |
|
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
|
|
|
|
nibor
|
|
October 16, 2012, 10:31:26 PM |
|
New site looking for beta testers: https://bitcoinvanity.appspot.comAllows 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.
|
|
|
|
crazyates
Legendary
Offline
Activity: 952
Merit: 1000
|
|
October 17, 2012, 05:08:57 AM |
|
I just found this, and I must say, it's awesome! Getting ~30Mkey/s on my 7970 @ 1150/1485.
|
|
|
|
fizzisist
|
|
October 17, 2012, 10:56:02 PM |
|
I posted this question in the vanity pool thread, but realized it really belongs here since it's about oclvanityminer. 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: 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: 3600 * rate * reward / difficulty Where rate is the calculated Mkey/s for your hardware (so vg_output_timing() will have to been called already).
|
|
|
|
fizzisist
|
|
October 17, 2012, 11:57:59 PM |
|
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 would love this. Just started trying to figure out how to calculate this, but I'd rather not reinvent the wheel...
|
|
|
|
slush
Legendary
Offline
Activity: 1386
Merit: 1097
|
|
October 19, 2012, 09:35:58 AM |
|
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 :-).
|
|
|
|
crazyates
Legendary
Offline
Activity: 952
Merit: 1000
|
|
October 19, 2012, 04:33:53 PM |
|
I just found this, and I must say, it's awesome! Getting ~30Mkey/s on my 7970 @ 1150/1485.
on 7970: (seems it is finding matches, but disregarding due to mismatch? CPU hash: 6707a76e848f5e9368c2d9d9ec6d60880df44891 GPU hash: 020b0bda39a9bbb2eeddd194a8be20934835dff6 Found delta: 94027 Start delta: 1
When you get the CPU hash/GPU hash mismatch, it means the OpenCL device is producing incorrect results. I have not had a chance to test it on an AMD 7XXX series GCN card yet, but others have reported that it works. Try running it with -V on that card for a little while and see what you get. Since it's producing incorrect results, the performance numbers may or may not mean anything. Looks like I spoke too soon, cuz I'm actually getting this this error on my 7970, with 12.8 drivers. I tried a few different flag options, but nothing really worked.
|
|
|
|
The00Dustin
|
|
October 19, 2012, 06:47:39 PM |
|
This one does not work for me - window opens and closes after like 5 seconds: oclvanityminer.exe -u https://vanitypool.appspot.com/ -a mybtcaddressgoeshere This one works, uses both CPU cores: vanitygen.exe something WinXP SP3, GPU ATi 4670, SDK 2.5, OpenCL 1.1 Any clue? Try oclvanitygen.exe something to see if the problem has to do with opencl.
|
|
|
|
crazyates
Legendary
Offline
Activity: 952
Merit: 1000
|
|
October 20, 2012, 05:29:43 AM |
|
Looks like I spoke too soon, cuz I'm actually getting this this error on my 7970, with 12.8 drivers. I tried a few different flag options, but nothing really worked.
Well I only get 9Mkey/s instead of 30, but the -S option produces valid results.
|
|
|
|
BkkCoins
|
|
October 20, 2012, 09:34:31 AM |
|
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 would love this. Just started trying to figure out how to calculate this, but I'd rather not reinvent the wheel... I've now created a repo on github for this. I had to rewrite some today due to a hard disk crash last week but hopefully I didn't mess it up. I think it may actually be better this time around but it hasn't been tested as much as my older version. https://github.com/bkkcoins/vanitycalc
|
|
|
|
fizzisist
|
|
October 20, 2012, 06:06:39 PM |
|
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 would love this. Just started trying to figure out how to calculate this, but I'd rather not reinvent the wheel... I've now created a repo on github for this. I had to rewrite some today due to a hard disk crash last week but hopefully I didn't mess it up. I think it may actually be better this time around but it hasn't been tested as much as my older version. https://github.com/bkkcoins/vanitycalcYes! Thank you! I tested this out on Debian and it works like a charm.
|
|
|
|
|