Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 142. (Read 1153691 times)

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

I had got it wrong, thanks.

Guess I will have to give it a try then

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.

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.

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

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

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.


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...


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.

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.

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.

Fixed.

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

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.

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.

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.  

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

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.

Learn something new every day

Nope they hash out to different bitcoin addresses

Can't the compressed key be derived from WIF?

Done 

Copyright 2000,2001 Jeff Garzik

Some rand generators use this method to obtain entropy data, but that doesn't do anything by itself.

Vanitygen uses OpenSSL to generate it's random private keys, which is pretty well vetted. If you have concerns that the startup state may be deterministic, you can use something like gpg key generator which does use random keyboard input to increase entropy, and then feed the gpg key data into vanitygen as a random seed.

There are rare hardware platforms that include a real hardware random number generator, notably VIA C3 processors and Intel 840 chipsets. These can feed urandom true hardware randomness with a kernel patch.

extra credit: spot the bitcoin developer
https://www.kernel.org/doc/Documentation/hw_random.txt

If generating keys using an airgapped live-cd-booted computer (with any software, not just vanitygen), you want to make sure that your system's randomness pool has enough entropy before you start using it. When you start eliminating all outside forces on your computer, you can end up also making it much harder for your computer to generate the random numbers used for private keys. I would guess that for most systems just bashing on the keyboard and moving the mouse a bit before you start generating is sufficient, but I wouldn't take my word for that.