Topic: Simple Vanity Address Generator [v0.4] (Read 18038 times)

Yes, but it will take until the heat death of the universe to match all 32 characters.
Or it could happen in 1 minute....with good luck.

so your saying if I simply go to bitcoinrich list, then copy and paste the #1 bitcoin address in there, it'll find me a private key?   

I really like your software. Would it be hard to implement Minikey for private key and other cryptocurrency (Litecoin, Namecoin, Novacoin, Feathercoin) ?

I would be willing to give a donation for it.

Good work, thanks.

I try this but very slow and I have broken 3 times now waiting for some fast work from this Vanity

Nice java app.

Keep up the good work!

You can calculate this yourself. The address is written in base58 which means that you would have to go through on average W=1/2*(58)^n addresses where n is the number of characters in your vanity string before finding your vanity address. For n=4 this means W=5.7m addresses. I can only calculate s=20-30 a second so this calculation would take me t=W/s=63 hours which is more than two days...

The algorithm can probably be speeded up and it should also be much much faster to calculate this on an ASIC since you are basically doing a lot of the same work as when calculating hashes for bitcoin mining.

Couldn't it be significantly sped up? I think other generators are at about 300 @ second.

If the kernel can run out of entropy, there is something seriously wrong about how it is generating random numbers.

It's a common misconception to think that generating large amounts of cryptographic quality random data requires large amounts of hardware randomness. The crypto community that actually understands this stuff - as opposed to the uninformed and those trying to sell products - have realized for decades that the right approach to generating random numbers for crypto is to use a random pool in conjunction with a cryptographic quality pseudo-random number generator. (PRNG) Bruce Shneier and Niels Ferguson's Fortuna algorithm is a good example of a very well thought out version of this approach, but the basic idea is really simple: maintain a pool of random bits, use a cryptographically secure pseudo-random number generator to generate pseudo-random data from that pool in whatever amount is required, and as truly random data is generated in the system, mix it into that pool. The volume of truly random, and unknown to the attacker, bits required is small because the entropy of the pool never decreases. Even on a virtual machine generating 128bits of random data from network packet timings isn't too hard and can be done relatively quickly - hardware random number generators simply make that process faster and should be fed through a random pool + PRNG anyway to protect you if the hardware generator fails.

Smartcards are actually a very interesting example of this philosophy: to generate random numbers they sometimes have as little as a random seed built into the hardware at the factory and a counter guaranteed to always increment. To generate a random number the counter is incremented, verified to have incremented properly, and then something like SHA256(seed + counter) is computed to generate the number.  Less daring designs still collect environmental entropy and mix it into the pool with XOR, but in an application where compromise of the smart-card compromises the whole system anyway this seemingly insecure approach is still not the weak link in the system.

Get yourself a copy of Shneier's Cryptography Engineering and read it carefully. Frankly I'm kinda surprised, and a bit worried, to see you have such a basic misunderstanding of cryptography given you maintain bitcoinj.

I think it doesn't change anything, but I didn't run twice, the app paused itself when the  address was found, I copied it then hit the start button again.
The netbook wasn't unattended, I'm a bit ill, so I spend too very much time doing various things on it on the couch (often I fall asleep with the PC over my belly). Even the mouse usually doesn't stay still by itself, lol, I'm using a wacom tablet on a very unstable position.

While we're on the topic of RNGs. I've got a gen 2 i7 CPU which is supposed to have a true RNG baked into the die.  I haven't been able to find a straight answer on the web whether recent linux kernels are taking advantage of this yet. Is this piped into /dev/(u)random etc?

I know Jeff Garzik has been involved in this area as I saw some tools he wrote to enable the rng, but the process was fiddly and I assumed we'd see this in stock kernels pretty soon? I just can't seem to find out if I was right anywhere.

Anyone know? Thanks.

ECKey uses SecureRandom and always has. That's provided by Java, it's not a part of any library that's used. You can see the implementation used on Unix systems here:

http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/provider/NativePRNG.java?av=f

If you run the app twice and it generates the same vanity address, that rather implies that your kernel has completely run out of entropy and is feeding apps repeated data, so the PRNG on top is looping. I think it is maybe expected to happen if you try and generate vanity addresses - one reason to not do it, frankly. I'm not sure you can generate really huge quantities of cryptographically random numbers on a regular PC if left unattended, it has to get entropy from somewhere and without any user interaction the best it can manage is consuming its own interrupt timings. That's why GPG and friends tell you to mash the keyboard and wave the mouse around when making keys, which obviously you aren't doing in this case.

As far as I know companies or organisations that need enormous streams of crypto-strong random numbers use a hardware RNG that measures Johnson–Nyquist noise. Alternatively HAVAGE (http://www.irisa.fr/caps/projects/hipsor/) may work well if you need random numbers on servers, but I haven't tried it for myself.

I know there's some kind of gut appeal to having a vanity address, but seriously guys, I wouldn't go there. Not only do you open yourselves up to questions of whether your random numbers are good enough, but you leak private data left right and center. There's a good reason why Bitcoin-Qt generates new addresses for you all the time.

Thanks.
If it can be helpful I can try to find those "double keys" or try to remember the "vanity words" (I'll PM you in the case). By the way, now I'm using vanitygen under wine and command line. It is way faster.

I'm glad you find the interface to be cute, and the app easy to use.

Randomly reproducing an address/key is remarkable - almost inconceivable - so thanks for reporting it. The current version (v0.4) is based on bitcoinj v0.5.2 (rather old). The way it makes keys is to call new ECKey() - that's it (plan to open source next version). Beneath bitcoinj-0.5.2 is bouncycastle (replaced by spongycastle in newer versions of bitcoinj). I haven't investigated the particular random generation, but it should be impossible to produce the results you've observed; therefore it's certainly worth looking into whether bitcoinj could have such a weakness.

I'll bring this up with the bitcoinj folks to see if anyone can offer any further insight.

It happened to me. Three weeks ago I was interested in creating some "serial" vanity addresses. Looking around to find an offline generator, I found Simple Vanity, I knew it was slow (on my netbook it really crawled), but it didn't need compiling to work under Linux, it had a cute GUI, and I just wished to try out with some very short vanity word (mostly acronyms from 2 to 3, maybe 4 characters, excluding the 1).
Used it very occasionally for 3/4 days, then, after it found the nth address I was looking for, I saved it, restarted and after a minute or so it found another one, to my surprise the address was identical to another previous generated one! I stopped using it, and I am afraid it is better to never use that bunch of addresses.

Yep - as advertised! Thanks for trying it out.

it's nice, but really...too slow !
vanitygen is much faster

Although I recognize the theoretical possibility of a collision, I believe the concept that this vanity generator created a collision or has a weakness making collision even remotely possible (to any realistic degree) is baseless speculation. Nonetheless, here is my post on the thread in question. I will follow up in a couple days. Happy holidays.

I don't think anyone knows for sure what's up yet. I spoke to TheButterZone on IRC and he said it was this tool.

Can you elaborate? Is the risk lack of entropy in the RNG? the other thread doesn't mention this tool explicitly...