Closed jedahan closed 4 years ago
I started working on a rust version but the p192 curve is really not popular, or its hard to search for.
Either way, my version is getting different key lengths than 'elliptic', but it is generating and testing keys over 10,000x faster than this one on a single thread. Can't wait to fix the key generation and enable threading :)
This is great! I'm happy to merge and integrate this node implementation into the chattervox cli. That is, unless you think that the performance differential between the node version and the rust implementation makes the former nearly moot?
I started working on a rust version but the p192 curve is really not popular, or its hard to search for.
This has been my experience as well. I originally picked the p192 curve as it produced the shortest key pairs out of all of the curves in the "elliptic" library. Small keys are great at 1200 baud, but the rest of the world seems to have sort of abandoned this curve...
it is generating and testing keys over 10,000x faster than this one on a single thread. Can't wait to fix the key generation and enable threading :)
Holy smaaack! This is gunna rip with multi-threading. Given how performant the rust implementation is, my inclination is to point people towards chattervan, once it's ready, instead of integrating the genvanity
subcommand here. What do you think?
Also, this has me thinking that it would be cool if we supported storage/transfer of chattervox keys in base64 encoding in addition to hex encoding, so that vanity keys can use more than just 16 characters!
This is great work! Thanks for your time and energy in this direction. Let's schedule some time next month to hack on this stuff side-by-side.
Just to clarify because I'm pretty new with hashes and signatures - it looks like the public keys generated by ed25519 are shorter than p192, but do you mean that the p192 signatures are shorter than the ed25519 signatures?
It would be pretty great if we used base58 for encoding and ed25519 for pub/privkey, if it is of comparable length.
it looks like the public keys generated by ed25519 are shorter than p192, but do you mean that the p192 signatures are shorter than the ed25519 signatures
Yep, that's exactly what I meant (s/key pairs/signatures/
). Sorry about that confusion.
Base58 is nice in theory, except I think i'd vote Base64 for two reasons:
Compared to Base64, [in Base58] the following similar-looking letters are omitted: 0 (zero), O (capital o), I (capital i) and l (lower case L) as well as the non-alphanumeric characters + (plus) and / (slash).
That said, there's no reason we couldn't add support for both encodings so long as we have a way of delineating between the two. That said, that might introduce confusion, as they are so similar.
Any movement on the rust vanity key generator? I'm really excited for this!
The rust vanity generator is just barely working now https://github.com/jedahan/chattervan - it only searches for a prefix (after prepending 04), and only accepts hex, but we can build on top of it later if we decide to encode in a different base, and add suffix features.
If you could test and comment we can try linking to it.
First hacky version it is not documented the args can kinda trample each other and honestly, I probably want to rewrite it in rust to be multithreaded but I haven't figured out what crates to use
It takes about 1 minute to find a four letter word in a public key twice
genvanity --needle dead --min 2
on my 2012 13" rMBP.