Invalid private key generated 63 hex instead of 64?? about profanity2 HOT 4 OPEN

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

from profanity2.

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

Importing 0bc7506af1b2484069d6ed3ea093c5123d83e2444d9c0a1cf277bf136fb46191 works to give 0xdeaD42cBAa61c2f442ebF8648408F766Ece982C4

from profanity2.

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.

from profanity2.

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.

from profanity2.