I downloaded the latest version and compiled it for OSX but I can't seem to specify a public address when I use ./oclvanitygen (or the miner) instead of ./vanitygen however the topic start of mentions it's both possible. What am I missing? -P doesn't seem to be an option for oclvanitygen.

Hey guys. I was wondering if it was possible to make a 1 click set up/app or a step by step guide for setting this up on Mac. I would really like to be able to make some vanity address but I do not know how to build from source or any of that kinda stuff...

Hey guys. I was wondering if it was possible to make a 1 click set up/app or a step by step guide for setting this up on Mac. I would really like to be able to make some vanity address but I do not know how to build from source or any of that kinda stuff...

Thanks-Desertbeagles

Aren't there binaries for osx for vanitygen? In any case it's not too hard to build from source, I use GNU/Linux but as OSX is also unix based, I suppose the steps would be pretty similar:

Hey guys. I was wondering if it was possible to make a 1 click set up/app or a step by step guide for setting this up on Mac. I would really like to be able to make some vanity address but I do not know how to build from source or any of that kinda stuff...

I do think the way it's set up might be problematic. For one thing, I'm not seeing a field for a customer to provide their split key part. That means that the service could (not saying they are, but they could) be holding on to the keys for the generated vanity addresses. Even if they don't, they could still get hacked and the hackers get access to keys from there (this has happened before with another service).

I certainly caution against this service's use until they implement split key generation.

Best to stick to one of the other services that do offer split key generation;

I do think the way it's set up might be problematic. For one thing, I'm not seeing a field for a customer to provide their split key part. That means that the service could (not saying they are, but they could) be holding on to the keys for the generated vanity addresses. Even if they don't, they could still get hacked and the hackers get access to keys from there (this has happened before with another service).

I certainly caution against this service's use until they implement split key generation.

Best to stick to one of the other services that do offer split key generation;

Yep. Hopefully its proprietor (Velkro? If not, I'd be happy to drop them a line at the e-mail address) can add split key generation, as aside from that it is fairly well-setup with concise instructions on how to import the keys, offering a paper wallet to print out, etc. VAMP ( http://vanityamp.com/ ) was almost like that, with a very polished interface, and based more on outsourced vanity mining (ala vanitypool) - that's still under reconstruction, though.

Just as been done with (SHA256 and Scrypt) mining software, I've been trying to port the Vanitygen code for CPU to make use of the SIDM functionality.By running the SHA256 and RMD160 4 times parallel (AVX1) I got a rough speed increase of about 25-30%.It seems that the actual EC_key generation is the big time consumer.Any idea how to speed this up? Is it possible/faster to only calculate only a X-coordinate, hash the compressed key, and try to find a (valid) key-pair after a confirmationa wanted prefix in the bitcoin address is found? You might run into false positives I guess, but this could be a trade off to faster hashing.....

Does anyone know if this means that doge and litecoin split keys are not possible with this? or do I have to read through the entire codebase?

Correct - it always attempts to spit out a Bitcoin address. I only had a cursory glance at some of the forks, but it doesn't look like anybody actually touched keyconv to support altcoin addresses. BAU also doesn't support it, nor does bitaddress.org's code (though that's javascript, shouldn't be terrible to modify).

Does anyone know if this means that doge and litecoin split keys are not possible with this? or do I have to read through the entire codebase?

I checked the source code of the keyconv, it only combines two private keys an generates a new key.For the address verification it assumes the prefix that is related to bitcoin, for some reason the -X option is not here for various address confirmations.For combining the private keys it is actually not needed.

Inserting this private key in a Dogecoin wallet should give the prefix DLR I guess.....If the hashing is the same..the generated code:DLRk2hNcMccjKrPYiDBrbjX6C1j7r1Pnkgis not 100% equal to the actual codeDLRk2hNcMccjKrPYiDBrbjX6C1j7tgjDpX

Thats because the SHA hash checksum is not calculated in prefix mode to gain time, this effect is only at the end of the address.