Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 176. (Read 1153655 times)
This is awesome, makes me wish I had something better then a old centrino laptop
So, does anyone else have/had an issue where olcvanitygen never finds a matching key, and just continues searching regardless of how easy the request is?
Same problem here on 0.17 binary / Win7 32 bit / 5770 / Catalyst 11.6/2.4 - it just searches without returning an address find, even with something simple like oclvanitygen.exe -d 0 1111. Safe mode does the same thing. 0.16 has the same problem, only it crashes compiling if you don't use safe mode.
New one creates 26meg text files before finishing. I posted the first sections of each, cutting out the middle part.
file (-d0 -vV 1): http://pastebin.com/PvcvCwKv
file (-d0 -vV 1cat): http://pastebin.com/YqGJtFcv
For the CPU one
file (-d2 -vV 1): http://pastebin.com/e88vBWFa
file (-d0 -vV 1): http://pastebin.com/PvcvCwKv
file (-d0 -vV 1cat): http://pastebin.com/YqGJtFcv
For the CPU one
file (-d2 -vV 1): http://pastebin.com/e88vBWFa
Thanks for posting that. It's going to take a little more time to understand what's wrong. For the first dump, the column array has the wrong value for column 0, which makes absolutely no sense. Also the X/Y values produced for (0,0)-(0,31) are the expected values for (1, 32)-(1,63), which would suggest that somewhere, the pointer to the temporary result buffer is off by 8192 bytes. I can't find any similarities on expected vs. produced Z values. The second dump doesn't have any X/Y or Z similarities. The zeros at the end are kinda interesting too, also suggesting a bad pointer somewhere.
I'm going to add a specific test case for column-major load/store of bignums, and give you something new to try. Hang on and thanks again!
The problem with this position is that the shorter address is random happenstance, not the goal or the defined problem. By that position I could say that my generated address 1CoinsLoLBY6o9khnW95MkbW2eEZQaxTRa beats it, by having eight characters that mean something, although that was also randomness and not something that was searched for. Or I could change my forum nick to 6o9, and say it has 13 digits.
If vanitygen had an option for finding only short addresses with a vanity phrase, then it would really be something to find a 25 character address with a word you searched for in it.
If vanitygen had an option for finding only short addresses with a vanity phrase, then it would really be something to find a 25 character address with a word you searched for in it.
Good points!
I guess it's possible to cheat like that. Maybe we should adopt Boggle or Scrabble rules, with case-sensitive bonuses? Perhaps forum handle inclusion should be limited to the beginning of a prefix?
Is a 25 character address even possible, short of having a long sequence of 1s?
We'll never know wether or not it's valid 
It almost certainly is valid. In theory, there are approx. 2^96 private keys that would fit.
So far RaTTuS seems to have set the bar for complexity with his public address. Even though the prefix is only "1" + 6-characters, it's a 33-character address, and is much less common than a 34-character "1" + 7-character prefix. To beat it, one would need to show:
- An address containing a 7-character or longer interior sequence, case-sensitive
- A 34-character address with a "1" + 8-character prefix, case-sensitive
- A 33-character address with a "1" + 7-character prefix, case-sensitive
If vanitygen had an option for finding only short addresses with a vanity phrase, then it would really be something to find a 25 character address with a word you searched for in it.
Sorry, I was out for a week. Running with -vV causes it to crash out. -S doesn't help; still crashes out.
Running without -vV and without -S dumps out a lot of stuff.
I posted the output here: http://pastebin.com/hxuenQ79
Running without -vV and without -S dumps out a lot of stuff.
I posted the output here: http://pastebin.com/hxuenQ79
Most interesting!
Unfortunately, the crash was caused by stupidity on my part in the process of building it against 32-bit OpenSSL. Here's a new one that has been tested with the CPU device. Beware, the output goes to stderr now, so to get the output to a file, use oclvanitygen -d0 -vV 1 2>file.
As for the result you got, 3b4df4363caa9e3bd9da58020d3080be8230a4ae is indeed significant, it's the hash of the zero point. At the very least, this validates that the hash functions are working. Probably at least one zero is being introduced into the z_heap, and since the heap_invert function doesn't check for zeros, it's producing zero for all outputs. If the validation output works this time, maybe the root cause will be clear.
If it doesn't crash this time and produces interesting results, would you also be willing to test it against the CPU device?
Thanks.
New one creates 26meg text files before finishing. I posted the first sections of each, cutting out the middle part.
file (-d0 -vV 1): http://pastebin.com/PvcvCwKv
file (-d0 -vV 1cat): http://pastebin.com/YqGJtFcv
For the CPU one
file (-d2 -vV 1): http://pastebin.com/e88vBWFa
Hope that helps. It does't really mean anything to me
Sorry, I was out for a week. Running with -vV causes it to crash out. -S doesn't help; still crashes out.
Running without -vV and without -S dumps out a lot of stuff.
I posted the output here: http://pastebin.com/hxuenQ79
Running without -vV and without -S dumps out a lot of stuff.
I posted the output here: http://pastebin.com/hxuenQ79
Most interesting!
Unfortunately, the crash was caused by stupidity on my part in the process of building it against 32-bit OpenSSL. Here's a new one that has been tested with the CPU device. Beware, the output goes to stderr now, so to get the output to a file, use oclvanitygen -d0 -vV 1 2>file.
As for the result you got, 3b4df4363caa9e3bd9da58020d3080be8230a4ae is indeed significant, it's the hash of the zero point. At the very least, this validates that the hash functions are working. Probably at least one zero is being introduced into the z_heap, and since the heap_invert function doesn't check for zeros, it's producing zero for all outputs. If the validation output works this time, maybe the root cause will be clear.
If it doesn't crash this time and produces interesting results, would you also be willing to test it against the CPU device?
Thanks.
Tested with both new and old with -S. Same thing happens on both: the probability cunts up, then goes away, and it just keep counting the # of completed attempts without ever finding anything.
Thank you Rassah!
I posted a binary of oclvanitygen with verification functions here. Run it with the -vV flags to enable verification mode. It should run extremely slow, maybe 20-30 Kkey/s. If either the first or second kernel is producing incorrect results, it should produce copious output to your terminal. If it does this, pipe the output to a file (>error.txt), post it to pastebin or such, and post the link.
This may not be enough to isolate the problem to a specific function. In case it's not, I'm currently working on a more comprehensive test suite, one that provides device-side unit tests for the various bignum arithmetic primitives.
Sorry, I was out for a week. Running with -vV causes it to crash out. -S doesn't help; still crashes out.
Running without -vV and without -S dumps out a lot of stuff.
I posted the output here: http://pastebin.com/hxuenQ79
umm
Address: 1xxxxxxxxU9UK2z7JaYhg6ky2HuRkoxKTU
Address: 1xxxxxxxxFpUTSFeDcHwAWmw78Emm4ncE
^ I've replaced eight of the 1st characters - why do I get different lengths on these generated ones?
Address: 1xxxxxxxxU9UK2z7JaYhg6ky2HuRkoxKTU
Address: 1xxxxxxxxFpUTSFeDcHwAWmw78Emm4ncE
^ I've replaced eight of the 1st characters - why do I get different lengths on these generated ones?
it appears 33 and 34 character addresses are valid with the 33 char address the more unusual tougher one?
umm
Address: 1xxxxxxxxU9UK2z7JaYhg6ky2HuRkoxKTU
Address: 1xxxxxxxxFpUTSFeDcHwAWmw78Emm4ncE
^ I've replaced eight of the 1st characters - why do I get different lengths on these generated ones?
Address: 1xxxxxxxxU9UK2z7JaYhg6ky2HuRkoxKTU
Address: 1xxxxxxxxFpUTSFeDcHwAWmw78Emm4ncE
^ I've replaced eight of the 1st characters - why do I get different lengths on these generated ones?
how do you do 64 bit builds on windows, when i build now i only get 32 bit binaries.
With the MS tools, all you have to do is use the Visual Studio x64 Win64 build environment window. Make sure all the dependencies are built/rebuilt for x64. Then just build as normal. If you're using Shining Light Productions OpenSSL, you might have to get the Win64 build.
how do you do 64 bit builds on windows, when i build now i only get 32 bit binaries.
The checksum matches?
Yes, otherwise it couldn't have received coinsWe'll never know wether or not it's valid
It almost certainly is valid. In theory, there are approx. 2^96 private keys that would fit.
So far RaTTuS seems to have set the bar for complexity with his public address. Even though the prefix is only "1" + 6-characters, it's a 33-character address, and is much less common than a 34-character "1" + 7-character prefix. To beat it, one would need to show:
- An address containing a 7-character or longer interior sequence, case-sensitive
- A 34-character address with a "1" + 8-character prefix, case-sensitive
- A 33-character address with a "1" + 7-character prefix, case-sensitive
Draw
Is that a valid bitcoin address?
Here's mine: 1Chocobogtn77Fw56kQvZmTVbkziCK4L24 (I go by Chocobo in other forums)
Another draw.
Valid for Namecoin and testnets though
The checksum matches?
Yes, otherwise it couldn't have received coinsWe'll never know wether or not it's valid
It almost certainly is valid. In theory, there are approx. 2^96 private keys that would fit.
So far RaTTuS seems to have set the bar for complexity with his public address. Even though the prefix is only "1" + 6-characters, it's a 33-character address, and is much less common than a 34-character "1" + 7-character prefix. To beat it, one would need to show:
- An address containing a 7-character or longer interior sequence, case-sensitive
- A 34-character address with a "1" + 8-character prefix, case-sensitive
- A 33-character address with a "1" + 7-character prefix, case-sensitive
Draw
Is that a valid bitcoin address?
Here's mine: 1Chocobogtn77Fw56kQvZmTVbkziCK4L24 (I go by Chocobo in other forums)
Another draw.
The checksum matches?
Yes, otherwise it couldn't have received coinsWe'll never know wether or not it's valid
It almost certainly is valid. In theory, there are approx. 2^96 private keys that would fit.
So far RaTTuS seems to have set the bar for complexity with his public address. Even though the prefix is only "1" + 6-characters, it's a 33-character address, and is much less common than a 34-character "1" + 7-character prefix. To beat it, one would need to show:
- An address containing a 7-character or longer interior sequence, case-sensitive
- A 34-character address with a "1" + 8-character prefix, case-sensitive
- A 33-character address with a "1" + 7-character prefix, case-sensitive
Draw
We'll never know wether or not it's valid
It almost certainly is valid. In theory, there are approx. 2^96 private keys that would fit.
So far RaTTuS seems to have set the bar for complexity with his public address. Even though the prefix is only "1" + 6-characters, it's a 33-character address, and is much less common than a 34-character "1" + 7-character prefix. To beat it, one would need to show:
- An address containing a 7-character or longer interior sequence, case-sensitive
- A 34-character address with a "1" + 8-character prefix, case-sensitive
- A 33-character address with a "1" + 7-character prefix, case-sensitive
The checksum matches?
It is valid
We'll just never find the private key
We'll just never find the private key
I think he meant valid vanity addresses, i don't think that one passes more strict validation
We'll never know wether or not it's valid
I've generated a 7 letter one that I may use....
but ones associated with my forum name will stay on the forums
I think he meant valid vanity addresses, i don't think that one passes more strict validation
Jump to: