Gotta be honest, I had zero clue minikeys were even a thing until pretty recently. Stumbled onto them by accident and started poking around, so here's what I found out.
Quick rundown for anyone who hasn't heard of this format: the whole point was that physical Bitcoin items (coins, cards, etc.) don't have much space, so fitting a standard WIF private key on them was a problem. WIF is 50+ characters long, which is just too much. So people came up with a shorter format. Early minikeys were 22 chars, then they bumped it up to 30. Like WIF, minikeys use Base58 characters, meaning anything that could be visually confused gets dropped, so no lowercase 'l', no '0' (zero), no uppercase 'O'. On top of that, '1' got cut too, so technically it's more of a "base57" thing. Oh and minikeys always start with the letter "S".
The big difference from WIF is how you actually get the private key out of it. WIF literally encodes the private key directly, so you just base58-decode it and you're done (there's also a built-in check to confirm you decoded the right thing). Minikeys work more like a brainwallet phrase, the private key isn't stored directly, you have to hash the minikey to derive it, same basic idea as brainwallets.
One more thing worth knowing: minikeys have a built-in validity check, because not every possible combination of characters is actually a valid minikey...
Yes it does but is it really useful?
If someone wrote down their minikey wrong is it going to be easy for them to correct the error just knowing that the extended minikey doesn't start with "00" ? I doubt it.
If anything I would kind of tend to the belief that restricting extended minikeys to start with 00 just reduces the security level by a factor of 256...but as you seem to want to imply through your calculations, it's still secure enough.
if you know your minikey's bitcoin address you'll know if there was an error typing in your minikey. so you dont need error detection in that case. if you dont know your bitcoin address then you might be in trouble. even with this "error detection"
and 30-character ones are just as secure as a full bitcoin private key.
If the random mode reduces performance by more than 90%, could you improve this by testing (for instance) 100 sequential keys after each random key?
Considering there are thousands of funded addresses, you'll find the first match long before testing even 1% of the key space. So testing duplicates shouldn't happen often.
Now let's build a dedicated ASIC device that does 0.5% of the Bitcoin hash rate for testing keys. It's an round number: 1018 keys per second. And we're not trying to crack all keys, just 1 out of every 5000 (which gives a reasonable chance to hit one of the 5000 funded addresses).
Now it only takes 58^21/10^18/5000/365/24/3600=68 million years to find a key. That makes mining Bitcoin blocks much more rewarding than cracking keys.
A few years ago I created many mini-private-keys (using a slow Python script) to search for a vanity address, but I don't have the list anymore. My search was too slow to find a meaningful vanity addy.
I do not understand that part.
In fact random mode is 9 times faster (or maybe it is better to say "more effective") than sequential (we test more valid keys), but we have no control over the work performed.
It will be easy to adapt my program to do that, but I see not reason - the only benefit would that you may keep your private key in minikey format.
It means that I am able to test 8mln mini-keys, but only 30k passed test (00) and I calculated public key + address. The benefit is that I know exactly which mini-keys were tested (so for example I may pause and resume work).
In random mode, I produce only valid mini-keys, so I receive 600k randomly generated valid mini-keys, which I test (public key + address). I do not know how many keys had to be tested to be able to produce desired bulk of valid keys, as I do not know if I do not test duplicated keys (but as you said before, the range is so big that it probably does not occur).
As we talk about misunderstanding:
Maybe I had not enough coffee today.
You calculate only hashes/s - (number of sha256 operations)? We need 1 hash always - to exclude "wrong" mini-key, then we need second hash to produce private key. (We may say we need 257 hashes to have one private key to test). And then we must find public key for our private key - this is heavy and time consuming part. Later we talk again about hash needed to verify address, but as I observed operations on secp256k1 take majority of time.
Has anyone downloaded this repository? https://github.com/PawelGorny/MinikeyCuda
it disappeared from github. If you downloaded it, send it to my email: cassiosamasr@gmail.com thanks