http://blockexplorer.com/address/1BitcoinEaterAddressDontSendf59kuE
this one ?
Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 177. (Read 1153383 times)
what is the most interesting vanity address created so far? anybody care to share?
How to get this running on OSX
This might help a bit. You have to install PCRE also, see http://pcre.org/
https://bitcointalksearch.org/topic/m.424122
How to get this running on OSX
The security afforded by this scheme comes at the cost of not being able to pool together the patterns desired by different clients into a single list, which would be dramatically more efficient. Every work unit executed by the service would end up being specific to a single client. If there were some way around this, it would make the service much more practical.
If we had a trusted pool server, it could supply each "miner" with a list of patterns and a public key which only the server knows the public key of. When a match occurs, it's controlled by the server and if it is correct, the miner get's another public key and server sends the vanity key and corresponding private key to the requesting user. We do have to trust the server to not steal the public keys, I don't know if this is a big issue. 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.
I think the issue may be something else now. Then again, maybe it DID work back when I had 0.16, and something changed between then? Damn. I hate debugging things. Sorry :/
A lot changed between them. It would be interesting to know for sure whether 0.16 in safe mode works for a simpler pattern, one that should take a minute or two instead of three days. If you're interested in trying this and need old binaries, you can get them here.
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.
I think the issue may be something else now. Then again, maybe it DID work back when I had 0.16, and something changed between then? Damn. I hate debugging things. Sorry :/
A lot changed between them. It would be interesting to know for sure whether 0.16 in safe mode works for a simpler pattern, one that should take a minute or two instead of three days. If you're interested in trying this and need old binaries, you can get them here.
Quote
I was thinking I could do something like step through it line by line to see where it SHOULD actually find a match and see what happens when it skips it and keeps going. I code in VB for Excel for work, and used to write in some other languages. There's no compiler out there that would allow me to execute the code line by line? Or is the stuff in the background too complicated to monitor?
AMD does offer this. I'm not convinced that the OpenCL debugger component actually runs on the GPU, and I'll give the problem here 99/100 odds of being a bug in the GPU compiler. But, if you really want to try it out, I can send you an oclvanitygen binary with debugging symbols.
Yet another debugging possibility -- if you run:
Code:
set GPU_DUMP_DEVICE_KERNEL=3
del *.oclbin
oclvanitygen 1
(or better parameters to oclvanitygen for your setup)
it should recompile the kernel, and in the process, create four .il files and four .isa files. These are output from different stages of the GPU compiler. If you can post them somewhere, I can look over them them and try compiling/assembling them for my own setup.
Hmm, if I knew C I would code a switch where you use an existing pub-key as seed, and vanitygen tries new keys by adding to that key. That would make it safe to help people find a key, without you having a way to fraud him.
This could be pretty cool.
I know this has been discussed elsewhere. To reiterate, the scheme involves a client/service relationship, where the client:
- Comes up with a list of address patterns that they want.
- Generates a pool of EC private keys, at least one per pattern.
- Submits the public keys of the key pool and the patterns to the address generation service.
The service tests a whole bunch of public key addresses, finds a match, and reports back:
- The matched pattern.
- The base public key Kb from which the match was derived.
- The increment of the matching public key n from the base, where the matching vanity public key Kv = Kb + nG
The client could then compute the private key by finding the private key in their pool matching the base public key and adding the increment to it. Thus, the service can find vanity addresses without ever having to know their private keys.
The security afforded by this scheme comes at the cost of not being able to pool together the patterns desired by different clients into a single list, which would be dramatically more efficient. Every work unit executed by the service would end up being specific to a single client. If there were some way around this, it would make the service much more practical.
No, safe mode doesn't help.
So, the last version worked in safe mode, but crashed otherwise, and the current version doesn't work at all in either mode?
And, just to verify, the key search rate is still ~3Mkey/s in safe mode?
I may have jumped the gun on this one. The old one has the same problem of not actually finding anything in safe mode, either (the one I was looking for would've taken an estimated 3 days to find it in safe mode, so it never finished)
This is a very interesting result. In the current version, safe mode does not completely disable loop unrolling, just the long ones. The shorter loops used in the bignum arithmetic functions are still unrolled by the preprocessor. There were changes beside this, but it could be a good place to start poking. I can send you replacement kernel code that disables all preprocessor unrolling if you want to try.
I think the issue may be something else now. Then again, maybe it DID work back when I had 0.16, and something changed between then? Damn. I hate debugging things. Sorry :/Quote
What code is this written in? Or rather, what compiler (for Windows) should I get? Maybe I can step through the thing to see where it fails (I at least know that much about programming >.< )
The language is OpenCL-C, and you should already have the code: take a look at calc_addrs.cl. Unfortunately, I don't have any tips to offer on how to use a device-side debugger, or whether it's even possible using AMD's SDK.
The kernels keep a couple of large temporary value buffers in GPU memory, usually never touched by the CPU. Their contents could be very informative for diagnosing problems, and all the test suite will do is check the correctness.
I was thinking I could do something like step through it line by line to see where it SHOULD actually find a match and see what happens when it skips it and keeps going. I code in VB for Excel for work, and used to write in some other languages. There's no compiler out there that would allow me to execute the code line by line? Or is the stuff in the background too complicated to monitor?
No, safe mode doesn't help.
So, the last version worked in safe mode, but crashed otherwise, and the current version doesn't work at all in either mode?
And, just to verify, the key search rate is still ~3Mkey/s in safe mode?
This is a very interesting result. In the current version, safe mode does not completely disable loop unrolling, just the long ones. The shorter loops used in the bignum arithmetic functions are still unrolled by the preprocessor. There were changes beside this, but it could be a good place to start poking. I can send you replacement kernel code that disables all preprocessor unrolling if you want to try.
Quote
What code is this written in? Or rather, what compiler (for Windows) should I get? Maybe I can step through the thing to see where it fails (I at least know that much about programming >.< )
The language is OpenCL-C, and you should already have the code: take a look at calc_addrs.cl. Unfortunately, I don't have any tips to offer on how to use a device-side debugger, or whether it's even possible using AMD's SDK.
The kernels keep a couple of large temporary value buffers in GPU memory, usually never touched by the CPU. Their contents could be very informative for diagnosing problems, and all the test suite will do is check the correctness.
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?
I haven't forgotten about you! To really get to the bottom of this problem, a device-side kernel test suite will be required. I'm working on this. All of my testing to date has been done using a host program, and in all cases so far except yours, the code has behaved identically on the device, or caused a nice, clean crash.
In the mean time, does it generate addresses correctly in safe mode, i.e. does not take more than a few seconds to find a match to 1Boat or such?
No, safe mode doesn't help.
What code is this written in? Or rather, what compiler (for Windows) should I get? Maybe I can step through the thing to see where it fails (I at least know that much about programming >.< )
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?
I haven't forgotten about you! To really get to the bottom of this problem, a device-side kernel test suite will be required. I'm working on this. All of my testing to date has been done using a host program, and in all cases so far except yours, the code has behaved identically on the device, or caused a nice, clean crash.
In the mean time, does it generate addresses correctly in safe mode, i.e. does not take more than a few seconds to find a match to 1Boat or such?
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?
Hmm, if I knew C I would code a switch where you use an existing pub-key as seed, and vanitygen tries new keys by adding to that key. That would make it safe to help people find a key, without you having a way to fraud him.
I have found a bitcoin address, can I use it just for "receive" coins even if I didn't added it on my wallet/client? ( I'll add it later ... )
Yes but keep the priv key somewhere 
I have found a bitcoin address, can I use it just for "receive" coins even if I didn't added it on my wallet/client? ( I'll add it later ... )
test with like .001 bitcoins before you do anything major. make sure you are able to reclaim the coins you put in
I have found a bitcoin address, can I use it just for "receive" coins even if I didn't added it on my wallet/client? ( I'll add it later ... )
Thanks and +1
Will check them out when I have some free time .... [yeah right !]
Will check them out when I have some free time .... [yeah right !]
pipped to the post ... 
1 Btc sent for your usefulness!
Regards,
Jonathan
p.s. don't forget to play a game at Bitcoinduit
and take a look a the 'new game' coming down the pipe, called '1Bounty' Jump to: