-
Notifications
You must be signed in to change notification settings - Fork 632
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compressed address support #32
base: master
Are you sure you want to change the base?
Conversation
I gave OpenCL support a try at https://github.com/scintill/vanitygen/tree/compressed_opencl (includes salfter's commit.) It seems to be working for me, but I also knew nothing about OpenCL, so beware. It's a bit faster since it doesn't have to hash a second SHA-256 block. I am wondering if I could do further optimization, since the full Y coordinate is not needed for a compressed pubkey, just the low bit (even or odd.) I don't understand the EC math or Montgomery reduction well enough to reason about it, and haven't taken the time to trace through all the multiplication code to try to understand it that way. I looked through some EC implementations' serialization routines and didn't see them taking any shortcuts for deriving a compressed public key from the secret, but then again there aren't many use cases where squeezing every last clock cycle out is as useful as it is here. |
Samr7 hasn't been active with this repo. I merged this into my fork at https://github.com/WyseNynja/vanitygen. It's easy to install with my brew tap at https://github.com/WyseNynja/homebrew-bitcoin and has various other fixes |
…for Radeon HD 7xxx
move runtime location for *.oclbin to /tmp
if (nbytes < 32) | ||
memset(eckey_buf + 1, 0, 32 - nbytes); | ||
BN_bn2bin(bn, &eckey_buf[33 - nbytes]); | ||
eckey_buf[nbytes+1] = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is an older PR, but I don't think this is correct. If bn does not have 32 bytes filled, this line will end up setting the 1 in the wrong place.
An example case where this happens:
// privkey that represents the hex below
puts("KwDso3DYHrJGKGFXmmEWwrj4mkxhp9Vj7ZwYUzRxykqMnccPjLRn");
BIGNUM *bn = BN_new();
BN_hex2bn(&bn, "0015d21a7852d7a408af01c9408895108842c373e88cbff1c9abf27871144938");
EC_KEY *pkey = EC_KEY_new_by_curve_name(NID_secp256k1);
EC_KEY_set_private_key(pkey, bn);
char privkey_buf[VG_PROTKEY_MAX_B58];
vg_encode_privkey_compressed(pkey, 128, privkey_buf);
puts(privkey_buf);
Running this prints the following:
KwDso3DYHrJGKGFXmmEWwrj4mkxhp9Vj7ZwYUzRxykqMnccPjLRn
KwDso3DYHrJGKGFXmmEWwrj4mkxhp9Vj7ZwYUzRxykqMKHREknvq
While this example is outside of vanitygen, I have also been able to reproduce the behavior using it (vanitygen prints a compressed privkey that does not correlate to the matched address).
I believe the solution is setting this index to always be 33:
eckey_buf[33] = 1
@wysenynja, this may be relevant to your fork as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For what it's worth, I agree it should always be 33. Nice catch!
This contains some changes to find compressed vanity addresses. CPU-only as I know nothing about OpenCL, but it's generated valid Bitcoin, Litecoin, and Yacoin compressed addresses.
I've also added a flag for Litecoin addresses, so you can use -L instead of -X 48.
(Use -X 77 to get Yacoin addresses.)