Vanitygen: Vanity bitcoin address generator/miner [v0.22]

[nimda]

Can't the compressed key be derived from WIF?

Nope they hash out to different bitcoin addresses

Learn something new every day

[christop]

Can the latest version (v0.22) make compressed keys? The ones that start with Letters and not 5 for the private key part. Sure I can convert it, but I'd want to generate a few hundred compressed keys (offline) for cold storage.

I'm curious why you want compressed keys (or what the purpose of a compressed key is, really). A compressed key is actually longer than an uncompressed key (52 characters vs 51 characters) so it won't save you any storage space.

That's just 1 byte more for the human readable public key. This isn't an issue. The compressed key is half the size of the uncompressed key in transactions and in the block chain. That saves a lot of space, which also translates into lower transaction fees in the long term.

Can't the compressed key be derived from WIF?

Nope they hash out to different bitcoin addresses

A private key is a private key. A "compressed" private key is just one of a few different representations or "formats" of a private key. You can convert between the different representations easily with a tool like https://www.bitaddress.org. Try it out and see the various formats.

The private key is also never stored in the actual Bitcoin transaction, so its size plays no part there.

[Dabs]

uh, no. Compressed keys (private) are smaller. 33 bytes compared to 65 bytes. If you try sending coins to the different public keys (compressed and uncompressed) ... well, I haven't tried it, but someone said they don't go to the same address.

The advantage is clear: their public keys are smaller, resulting in smaller transactions on the network, saving block chain size for everyone.

http://bitcoin.stackexchange.com/questions/5952/why-does-bitcoin-support-both-compressed-and-uncompressed-keys-addresses

[Blowfeld]

christop:  +1

Dabs:  -1

The 51-character *private* key that starts with a '5' and the 52-character *private* key that starts with a 'K' or an 'L' are equivalent to each other and can be converted back and forth between each other.  They are the same private key.

Either of the private keys (since they are one and the same) will allow you to derive the (uncompressed) *public* key, which is 65 binary octets in length OR the compressed *public* key, which is 33 binary octets in length.  For transactions where the public key is stored in the blockchain, obviously, the compressed *public* key saves some space.  However, most transactions do not contain a *public* key.  And no transaction ever contains a *private* key.

The hash of the (uncompressed) *public* key yields the standard bitcoin address.  The hash of the compressed *public* key yields an alternate bitcoin address.  Both bitcoin addresses are the same size.

The two forms of bitcoin address cannot be converted from one to the other without knowledge of the private key.  [Remember, there is only 1 private key, whether it is compressed or not.]

It is possible some wallets may not know the two forms of private key are one and the same.  It is possible some wallets may assume compressed public keys go with compressed private keys and that uncompressed public keys go with uncompressed private keys.  If that is the case, the wallet is deficient.  The mathematics are as I stated above.

Or there is something new that hasn't made it into the official Bitcoin specifications.  

[Lethos]

Is it still true that, Vanitygen won't work with the latest Catalyst drivers?
Is the best advice still to go back to an older version of Catalyst, or is a modification of VanityGen being worked on to work?

I generated a decent amount of address' a few months ago, but got the bug to do a few more again, but found it not working now.

[deepceleron]

However, most transactions do not contain a *public* key.

Fixed.

https://en.bitcoin.it/wiki/Transactions

A Bitcoin address is only a hash, so the sender can't provide a full public key in scriptPubKey. When redeeming coins that have been sent to a Bitcoin address, the recipient provides both the signature and the public key.

Is it still true that, Vanitygen won't work with the latest Catalyst drivers?
Is the best advice still to go back to an older version of Catalyst, or is a modification of VanityGen being worked on to work?

Still true as of the beta v13 driver from a month ago, and not likely to change. Vanitygen is open source, so it can be fixed by anybody, although it will be about 1000x easier to install a different driver version than to learn OpenCL programming and discover what changes need to be made. Samr is known for popping back into existence with a new version of vanitygen with new features though.

[Lethos]

Thanks DeepCeleron.

I'll probably just revert back temporarily. If It goes unfixed for a while, I might be tempted to give it a go in fixing it myself.
I've dabbled in quiet a few languages over the years. But I admit I wouldn't know where to start to fix this one.

[pc]

I think one of the problems is that the term "compressed private key" is used colloquially to mean "private key marked with a flag to indicate that the wallet should use the compressed version of the public key when generating an address", and no compression is actually ever done on the private key.

[Herodes]

The files, after you've booted can be found in /lib/live/mount/medium/vanitygen if you used WinISO (On Windows 7) to put it in the root of the iso-image.

To prepare the USB disk (make it bootable and add iso), I used Universal USB Installer 1.9.3.0. (On windows 7)
..

Consider:
-Your windows machine is completely PwnD, making any code that touched it untrustable and/or

It was a fresh install - with a minimum amounts of programs on it. So I don't see the reason to worry.......... It's not like a malware program would attack the computer that was freshly formatted, fresh w7 install and done all windows update + service pack 1. + firewall AND then insert malicious code in the iso-image that i manipulated, and then putting said iso image on an usb disk that i connected to another computer, and I had already retrieved the vanitigen binaries from a hardened down debian server on my local network and put these in the iso. Then i boot this usb image with the vanitygen program, generate the address/privkey par and then proceed to shut down that computer. Nothing is saved on the usb disk, and the computer in question is turned off, when it's back on, it doesn't even knew there was key-generating going on minutes ago, no way for anyone to get that info. Also the pc i booted from was off the network. There's not a chance that the private key can be compromised. If you know or think otherwise, please let me know - but your post reeks of those chest pugging know-it-all attitude that some geeks have.

-Your adversary can remotely access or physically steal the USB device and recover anything you've deleted or had in RAM (swap file).

They can steal the USB device - fine - no private key there. Remote access, what good would it do when there's no private key there to be found ? Also this iso image will never have network contact once written to the usb-drive.. RAM - swap file ? Off the network, shut off - rebooted with normal OS. Yeah - big risk there...

Better still would be to disconnect all hard drives and storage media on the target machine, and only boot and run off a live CD with a compile environment. You then only have to figure out how to get vanitygen code to the machine securely (removable non-writable media), and how to get the address/privkeys off the machine securely (print, burn CD) without creating any persistent digital copy whatsoever.

If you don't actually need vanity addresses, easier is just to use the bitaddress HTML/JavaScript generator code offline.

You're frankly talking completely out of your ass Sir. Even if my vanity gen compile somehow got compromised, it would be no help as it never would be online, and thus could never send any information anywhere.


For the record, the info was noted down on paper - by hand. I already mentioned that I did not make a photo with my cell or just a printer, exactly not to create persistent digital copies...

Your post was total bollocks.

[wizkid057]

1 BTC bounty for a fix for 13.x catalyst + vanitygen patch working, with source and builds for Linux, Windows, etc.

[phelix]

Is it correct that it is virtually impossible to create an address that consists of only upper case letters and numbers?

[jackjack]

Is it correct that it is virtually impossible to create an address that consists of only upper case letters and numbers?

No

When you restrain ONE character to be a precise letter, the odds are (1/62)
When you restrain TWO characters to be a precise letter, the odds are (1/62)^2
etc...
When you restrain ONE character to be an upper case letter or number, the odds are (26upper case+10digits)/(62)=36/62
When you restrain TWO characters to be an upper case letter or number, the odds are [ (26upper case+10digits)/(62) ] ^ 2 = (36/62)^2

Addresses with 6 fixed characters are pretty common (K1773R owns 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y), the odds are ~1/57billions
The odds of having an address with only upper case letters and digits is (36/62)^34 ~ 1/17billions
It's about 4 times quicker to find such an address than an address with 6 fixed characters. Far from impossible.

[The00Dustin]

Addresses with 6 fixed characters are pretty common (K1773R owns 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y), the odds are ~1/57billions
The odds of having an address with only upper case letters and digits is (36/62)^34 ~ 1/17billions
It's about 4 times quicker to find such an address than an address with 6 fixed characters. Far from impossible.

But the last characters are checksum.  Just because you can get all uppercase in what you go for vane doesn't mean you can get an all uppercase checksum as well.  Since a checksum is a hash, I doubt you can even calculate the odds on that...  Given the random nature of a hash, though, I doubt it can be proven impossible either.

[phelix]

Is it correct that it is virtually impossible to create an address that consists of only upper case letters and numbers?

No

When you restrain ONE character to be a precise letter, the odds are (1/62)
When you restrain TWO characters to be a precise letter, the odds are (1/62)^2
etc...
When you restrain ONE character to be an upper case letter or number, the odds are (26upper case+10digits)/(62)=36/62
When you restrain TWO characters to be an upper case letter or number, the odds are [ (26upper case+10digits)/(62) ] ^ 2 = (36/62)^2

Addresses with 6 fixed characters are pretty common (K1773R owns 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y), the odds are ~1/57billions
The odds of having an address with only upper case letters and digits is (36/62)^34 ~ 1/17billions
It's about 4 times quicker to find such an address than an address with 6 fixed characters. Far from impossible.

I had got it wrong, thanks.

Addresses with 6 fixed characters are pretty common (K1773R owns 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y), the odds are ~1/57billions
The odds of having an address with only upper case letters and digits is (36/62)^34 ~ 1/17billions
It's about 4 times quicker to find such an address than an address with 6 fixed characters. Far from impossible.

But the last characters are checksum.  Just because you can get all uppercase in what you go for vane doesn't mean you can get an all uppercase checksum as well.  Since a checksum is a hash, I doubt you can even calculate the odds on that...  Given the random nature of a hash, though, I doubt it can be proven impossible either.

Guess I will have to give it a try then

[jackjack]

Addresses with 6 fixed characters are pretty common (K1773R owns 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y), the odds are ~1/57billions
The odds of having an address with only upper case letters and digits is (36/62)^34 ~ 1/17billions
It's about 4 times quicker to find such an address than an address with 6 fixed characters. Far from impossible.

But the last characters are checksum.  Just because you can get all uppercase in what you go for vane doesn't mean you can get an all uppercase checksum as well.  Since a checksum is a hash, I doubt you can even calculate the odds on that...  Given the random nature of a hash, though, I doubt it can be proven impossible either.

The random nature is exactly why I think we can apply odds to this

For exemple, let's take characters in "0123456789"
Addresses in that system is 6 random digit + 4 digit from hash
The condition we want is "<3"
So:
 - the odds for the 6digits part is (3/10)^6
 - about the hash part: the hash is random, so you have 3/10 odds that one character of the hash is <3
 - then the hash part has (3/10)^4 odds to be written with 4 "<3" digit

So finally, we get (3/10)^10, just like if we don't take into account the fact that last characters are from a hash
This works because a hash is random, this gives the necessary linear independance

I might be proven wrong though

[phelix]

 1P3H99S84AVNAV7UX4EY8BFUF6H4MQVFZE

 

edit: nice tool.

In case you are wondering: This allows slightly leaner QR codes.

[K1773R]

Addresses with 6 fixed characters are pretty common (K1773R owns 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y), the odds are ~1/57billions
The odds of having an address with only upper case letters and digits is (36/62)^34 ~ 1/17billions
It's about 4 times quicker to find such an address than an address with 6 fixed characters. Far from impossible.

But the last characters are checksum.  Just because you can get all uppercase in what you go for vane doesn't mean you can get an all uppercase checksum as well.  Since a checksum is a hash, I doubt you can even calculate the odds on that...  Given the random nature of a hash, though, I doubt it can be proven impossible either.

as the last poster proofed it is possible, etotheipi has a only uppercase too

[phelix]

also single (lower) case addresses are much easier to tell over the phone:

vanitygen64.exe -r "^[a-z0-9_]*$"

-->  141zuyxnimmphjtow3ckrb4y7pswn56rmo

[wtfvanity]

But you guys have numbers mixed in too.

Make it ALL lower or upper only, with just the leading one

https://bitcointalk.org/index.php?topic=90982.0

There is an all uppercase address, and I have these two

1odfsrirfbxtwjoviseqdnuixwvhsnPbJ       (longest lowercase prefix - owner: wtfvanity)
19279281759997344NJ2KMcdRZNVT5rHhq      (longest digit-only prefix  - owner: wtfvanity)

[Remember remember the 5th of November]

With 13.2 beta drivers, it's impossible to run anything that has to do with OCL, I keep getting this error during the compilation of the .CL kernel(LLVM error and so on), which is the exact same error people are having here.

I would sure hope there is some workaround ASIDE from downgrading drivers, I honestly need these new drivers.