Err, no. I indeed got the calculation wrong... I since rewrote some of the code and got some real speed/s figures this time. I also added Java-side verification of Privkey->Address. Slows down Single address generation, but well worth to ensure that what you see is what you get. The main change is that I use the PCRE library which further increased the size, however it's also native code so should be faster than Java side.
And no, address generation is DEFINITELY not rigged. The only problem I saw however was that Android might not have /dev/random or /dev/urandom sources of entropy where OpenSSL got it's seed from on Desktop Unix/Unix-like systems, but I've asked on Stackoverflow and they've assured me it exists and is being used(no real way to verify other than to use the cryptographically strong entropy from Java side and pass it onto JNI).
Anyway, I haven't had much time to work on it seeing as it was barely "popular". My goal was to add apart from Multi-chain setups,but also Mini private keys(I already wrote the java implementation myself) and other features you'd see today in Desktop applications. I plan to release the source code when I am confident it doesn't suck as much
![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif)
.
Looking at the casascius client, there are very good features concerning encrypted private keys(passphrases) and whatnot.
Ah yes, trust me or not..it's using ludicrous amounts of RAM. The per-process limit is 16-24 megabytes, and mine is already using well over 11. I cannot find the problem, the emulator is fine though... My only guess is the UI elements.
EDIT:Currently, on my SGSII I get about ~7500 keys per second. The pattern 1abc(anywhere in the address) took about 45 seconds. Give or take a few since I had to count myself. Another took around 20 seconds(lucky). Timer needs to be fixed..fffuuu.
And if you have time, do analyze the memory dump
http://www.filedropper.com/work_3...I am dying to know what's causing the insane amount of RAM usage.