Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
But instead of scanning linearly one key after the next, jump around according to mcdouglasx/bibilgin strategies (trade off precision with probabilities).
No one can easily 'jump around' elliptic curve (EC) coordinates because they carry critical information about the point's location.
I recall that McDouglasX used a 'jumping' method by hardcoding the prefix to 03 (or 0x03 in hexadecimal) in python. This approach eliminates the need to check whether the y-coordinate is even or odd, as it always uses 03 as the prefix.
For example:
Code:
static inline std::string pointToCompressedHex(const Point &point) {
return "03" + intXToHex64(point.x); // Always use "03" as the prefix
}
static inline void pointToCompressedBin(const Point &point, uint8_t outCompressed[33]) {
outCompressed[0] = 0x03; // Always use 0x03 as the prefix
Int temp;
temp.Set((Int*)&point.x);
for (int i = 0; i < 32; i++) {
outCompressed[1 + i] = (uint8_t)temp.GetByte(31 - i);
}
}
return "03" + intXToHex64(point.x); // Always use "03" as the prefix
}
static inline void pointToCompressedBin(const Point &point, uint8_t outCompressed[33]) {
outCompressed[0] = 0x03; // Always use 0x03 as the prefix
Int temp;
temp.Set((Int*)&point.x);
for (int i = 0; i < 32; i++) {
outCompressed[1 + i] = (uint8_t)temp.GetByte(31 - i);
}
}
This method removes the need for the isEven check, but the performance gain is minimal because the check is already very fast. The original code uses a conditional statement (isEven(point.y) ? "02" : "03") to determine the prefix.
This approach has a trade-off: you may need to generate twice as many keys to achieve the same number of valid keys as the original code, since the hardcoded prefix does not account for the y-coordinate's parity.
