So I wanted a palindrome in my bitcoin address:


the 5 and 7 character palindrome is trivial, but with four or more backreferences, I get this:

---

Edited to add:

I went looking for the source to see about debugging the cre pcre problems (if only be allowing more memory or heap space or whatever... this is a known compile-time difference between real perl and PCRE library)


^grabbed source from the github, everything seems to be dated october 24th 2012...

1) I'm trying to figure out why there is no vanitygen64.exe make target in the makefile windows version of makefile, etc.

2) Wondering what the recommended toolchain for building this is... I was planning to just use msys environment mingw gcc since it's fairly standard

3) Noticed some of the hardcoded paths, specifically C:\OpenSSL-Win32, and was wondering which openssl was used... is official vanilla mainstream openssl-1.0.1c really what is being used? I'm having a bit of confusion with this more than anything, because there is no folder in the official vanilla mainstream openssl-1.0.1c source tarball named OpenSSL-Win32

oclvanityminer -u https://vanitypool.appspot.com/ -a 1XXXXXZTzBssUq6bnE27cz4rv5SJ4sr5 -d 0

There ya go hun.

Most command line applications have a "--help" flag that will show you all the flags with a short description.

when using the -P option, vanitygen wants to know the public key in hex format after the -P, and specifying only the bitcoin address is not sufficient.

Is there any way to generate the public key in hex format from the bitcoin address alone?

If not, are other methods (no vanitygen, but similar methods) known that work the same way when only the bitcoin address, but not the hex format public key is known?

I can actually find my way around a linux terminal (a tiny bit), so I put Lubuntu on another computer that I'm getting all setup for ASICs, and tried it there. Actually a little MK802, neat little toy! Bit I digress, I've just come to the conclusion that I'm totally F-ing retarded cuz the end result is that I can't get oclvanitygen64 to work in Windows 7x64 on my 7970 (without the -S flag, which I guess changes the kernel compilation parameters).

blah! delete the compiled kernels and then I can run it with the -S command... DOH!

I seem to recall on the blockchain.info thread there was discussion of an algorithm he used to find the public key from the address. Has a fancy name but I can't recall that now or else it would be easy to use search. This was some months back I believe.

You are correct. The address is a hash and a checksum, and you can't undo a hash.

This very property of addresses (being unable to recover the private key without a tx having been spent) will be useful as protection against quantum computing, provided addresses are never re-used.

More specifically, the address is:
A version byte 0 plus a RIPEMD-160 hash of the SHA256 hash of the public key, plus the first 4 bytes of a SHA-256 hash of a SHA-256 hash of a version byte plus a RIPEMD-160 hash of the SHA256 hash of the public key, all encoded in Base58.

I don't know that it's a bug, more likely that there are no possible values of raw binary Namecoin addresses that will convert into a Base58 address that starts with these characters. The underlying data of a Namecoin address must start with a network ID of 00110100 (binary) + hash. This means that the range of inputs to the Base58 converter can only go from 0011010000000000... to 0011010011111111...

You can search or explore the namecoin block explorer and likely see that there are no examples of these "nonworking" addresses, a less lazy person than me could actually do the math and describe the possible Base58 address ranges.