Invalid private key generated 63 hex instead of 64??

[brianleect]

Got 63 bytes.

Generated using openssl ecparam -genkey -name secp256k1 -text -noout -outform DER | xxd -p -c 1000 | sed 's/41534e31204f49443a20736563703235366b310a30740201010420/Private Key: /' | sed 's/a00706052b8104000aa144034200/\'$'\nPublic Key: /'

Private Key: 0bc657b0af28b743c7f0d49c4de78efd47a5c8923dabfdef051fff5cdc7c30e7
Public Key: 045fcdcd81547df7052123426fd25958f843c5a94f9b3fa5fa17dee627334a19bcf44f48f4e8a37f33c14d363217e925f3c7c8f3ef5bd806c86a918fd246314339

Running profanity2

Time: 1s Score: 2 Private: 0x0000f8ba428990fca1e618a252ac3614f5de19b20ff00c2ded57bfb6933830aa Address: 0xdead42cbaa61c2f442ebf8648408f766ece982c4
^Ctal: 522.240 MH/s - GPU0: 522.240 MH/s

Attempting to use python3 method to calculate private key

[brianleect]

Suspect it might be related to be use of RTX 3090?

johguse#27

^ Not sure if issue related.

Or am I doing something wrong? Think I followed the steps properly though

[brianleect]

Nvm my bad lol turns out hex just truncates leading 0 thus resulting in missing 1 hex.

Importing 0bc7506af1b2484069d6ed3ea093c5123d83e2444d9c0a1cf277bf136fb46191 works to give 0xdeaD42cBAa61c2f442ebF8648408F766Ece982C4

[brianleect]

Reopening as think this information should be added to the README?

Not sure if it was a coincidence that the first few keys I generated had a leading 0 for the private key addition causing the issue faced.

[brianleect]

On a closer look it appears that it is mainly due to leading 0's for both PRIVATE_KEY_A & PRIVATE_KEY_B will result in the sum not including leading 0s due to integer representation conventions.

Attempting to use the terminal method to calculate results in the same problem.

Seems that this is not limited to just 63 hex string outputs just that its not the most common. 62 hex string would require first 2 leading hex strings to be 0 which while still possible is less likely to occur.