Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
I use even more approaches than these, in my experimental solver I simply try algorithmically manipulate chances, moving chances of finding a solution to my side, and skipping non-interesting candidates that are very unlikely without any hashing to balance the risk of skipping the right solution and to balance out this way a low count of GPUs I have. As ruling out key candidates like this results in hardware computational speed-ups that are tens, hundreds, or even thousands multiples of the original speed of the device when searching whole/given range, but naturally depending on parameters greatly increase the risk of skipping the right solution.
Anyway, if I solve some low-bit BTC puzzle with my version and finally the price will arrive to my BTC wallet without being robbed during cashing-out by a bot run by a thief, I will publish my version of Bitcrack, including source code, so anyone can have fun with it then.
Anyway, if I solve some low-bit BTC puzzle with my version and finally the price will arrive to my BTC wallet without being robbed during cashing-out by a bot run by a thief, I will publish my version of Bitcrack, including source code, so anyone can have fun with it then.
Your experimental Bitcrack sounds like a mix between a turbocharged race car and a wandering philosopher pondering randomness.
A truly random 66-bit sequence doesn’t have intrinsic “strangeness”, it only appears odd because our pattern-seeking brains demand order in chaos. By defining arbitrary rules like skipping keys with "too many letters" or "too many numbers," you're essentially projecting human biases onto randomness. This is akin to looking at clouds and swearing you see a unicorn, then deciding to search only for dragon-shaped clouds.
From an entropy perspective, eliminating "unlikely" candidates assumes that randomness obeys your intuition. But randomness doesn’t care. If a 66-bit sequence consisting solely of numbers (or letters) bothers you, consider that each sequence, however "weird," has an equal probability of occurring.
Also, rejecting keys based on patterns risks skipping the correct solution entirely.
Your argument about pre-selecting hexadecimal candidates is clever but flawed. If you switched to a different numeral system (e.g., base-7 or base-12), would your rules still apply? Likely not. Randomness transcends such superficial constructs, it’s unbiased by our alphabets or cultural biases.
The promise of skipping unlikely keys sounds appealing, but at what computational cost? Verifying each candidate against arbitrary rules before hashing adds overhead. Imagine a treasure hunt where you ignore maps with "ugly handwriting", you might end up missing the actual treasure! Statistically, your forced exclusions might eliminate enough keys to make computation faster, but the cost is an increased chance of never finding the right key.
Finally, the "fun" element is subjective. Sure, tuning parameters for forced patterns might feel rewarding, but in the cold, unforgiving realm of cryptography, fun doesn’t find private keys = > efficiency does.