There have been multiple tries to crack this bit range puzzle through brute-forcing private keys, whether it’s the address itself or the public keys using Kangaroo and BSGS algorithms.
This thread explores a different method (albeit a slow one) that follows the same process as the original puzzle creation. Starting from creating the wallet, generating mnemonics, deriving the seed, compiling a list of private keys, applying masks, and finally checking for known private key collisions.
Here’s the code you can check out: https://github.com/iceland2k14/btc_words/blob/main/seed_puzzle.py
This is more of an alternative exercise, and if it works, we could potentially solve all the remaining puzzles that total around 1000 BTC in one go. I get that the chances of success are pretty much zero, but I'm curious to see how quickly we can tackle this and what obstacles we might face. Does anyone know of any existing tools and their speed for this?
I've made a few assumptions that could be right or wrong. Any thoughts would definitely help clarify things.
1. The wallet was likely new, so puzzles 1-256 should match address indexes 0-255 in the wallet. The creator seemed meticulous, so this might be a fair assumption.
2. The keys seem to be generated sequentially by masking the private keys of a deterministic wallet. Thus, if any collisions occur with 10 masked keys, that’s probably the correct seed.
3. The puzzles date back to 2015, so the entropy bits should be either 128 or at most 192, with a slim chance for 256.
4. The mnemonics used were probably English words, which seems the most likely scenario.
5. Standard B was likely used for key generation.
What evidence do you have besides just making an assumption that the puzzle challenge's private keys could be from a hierarchical deterministic wallet?
I'm not a wallet historian and thus can't recall easily at what period of time what kind of deterministic wallets were available.
To me this brute-force approach seems unfeasible for various reasons:
too many variables and assumptions creating an even vaster search space slow derivation due to PBKDF2 rounds involved in entropy-->seed-->extended private key-->further private key derivation inability to reduce variables and assumptions from already found existing private keys
This is described very clearly by the Creator itself ....
Regarding your other concerns i am aware that
Yes this is a very very slow approach. How fast can it be done. Kwords/s or Mwords/s or more ?Assumptions, think in terms of probabilities. How strong the assumptions are.The ability to use existing known privatekeys, any idea for any shortcut during the chain code generation process ?
The ability to exactly follow the same original process and ability to solve all the puzzles together is definitely an advantage, even if this can be called impractical approach.
So how did the person who claims to be a constituent managed to create the HEX address 0000000000000000000000000000000000000000000000000000000000000000000000000000000 000001?
The real private key was just bit-masked with appropriate bits. Garlo Nicon described it here: https://bitcointalk.org/index.php?topic=4453897.msg61848712#msg61848712
Of course, the real formula for making it, could be different than he described. For example: you can take the upper half, or the lower half of the key. You can use big endian, or little endian. There are many options, and even if you assume that everything would be guessed perfectly, then still, getting it right could be quite hard. However, there are 65 first private keys, which are revealed (and some more private and public keys above that), and getting the exact master private key could be possible in theory, because it seems there are enough revealed bits, to get only a single solution.
There will be 2 Problems if we do this.
Decrease in performance. Speed<1/10. As we are not stopping till privatekey but instead reaching till Address. Also we have to derive all unsolved 85 puzzles derivation path. currently we are checking collision with 11 privatkeys onlyWe have to rely on a partial collision of masked Key of some other seed with same address but exactly at the same derivation path level. First is still possible but 2nd is very improbable
It is simple script
If you know what is last key - e.g. '910ed3ab5775b97da1a33e38b72eba94f90addff7051f276c9d6c538c369632b'
Python script as an example
result
But no one knows the exact formula from the last private key to 1.
I even think he used logarithms and polynomials as steps between private keys..
So it ends up looking like there is no pattern.
But it's not random either according to the polynomial analysis.
https://bitcointalk.org/index.php?topic=1306983.msg63730770#msg63730770
There is an exact math formula for making this puzzle with some script, errors = ZERO.
With high decimal precision (mp.dps = 20 at least)
And the formula is in the creator's mind.
Simple Math is, Please Never ever mix the Integer modulo calculation with fraction, decimal, float, double or whatever 20 precision. They will never go along. Treat them as modulo Maths only.
log2 is just giving you the bit representation. Everone knows the Puzzle 66 is between the range 2**65 to -1+2**66 which is exactly between the bit 65 to 66. Same is for all the Puzzles. So off course there will be a straight regression line if you fit the log2 of known puzzle key values with puzzle number.
Hey Iceland,
I hope you are keeping well. I really like your scripting work for Pollard Rho's kangaroo algo.
I was wondering if you are willing to share the Kangaroo_CPU.dll or .so source code so that I can further develop it. I am happy to share it with you once I complete my developments.
Thanks!