This is because you have hardcoded your script to use 3 signatures. When the Leakage bits decreases below 128 you might need more and more signatures as you move up.

Check here https://github.com/iceland2k14/rsz/blob/main/LLL_nonce_leakage.py
for the generalized Matrix form reduction and also the function Minimum_Signature_Required for each Leakage bits.

Even if let's say #130 is barely possible by stretching limit and a lot of hashpower, but certainly we should start thinking of some ideas of improving further if we really have to attempt #135 plus.

Good to know that even after 12 minutes the fork coins were intact. So probably the situation is not that bad as we are anticipating

How was the Funds from Puzzle 64 transferred. There mist been a tug of war between the bots fighting each other during that time also. So how was it managed? Does someone know the story of that time. Same must have been for the Forks coin transfer of that puzzle as well. Another Tx another bot war ?

In a similar way I have a simulation script in python https://github.com/iceland2k14/rsz/blob/main/LLL_nonce_leakage.py  where some Random signatures are prepared with Leakage in 128 bits and then assuming they are are from Real Tx, they are solved using LLL reduction to print the PrivateKey.

Are these cases from an existing Tx on blockchain or it's from mathematical Tx ?

Random gifting is improbable.
Someone with that much BTC can easily change country to move to Tax heaven, rather than throwing away.
If he really inclined to gift, he would most probably give it to bitcoin active development, puzzles, widespread usage and security projects.

Your sample is 64 length so i assumed it is hex privatekey format. On this basis the start, end and stride for the key search will be....

start = 0x00000000000000000000000000000000000
end = 0xFFFFFFFF000000000000000000000000000
stride = 0x1000000000000000000000000000

I think you will modify it accordingly to fill your 0 values in start and end..but no need to change anything in stride.

Yes there are several ways.
1. When same K is used 2 times either in same or different Transaction, its trivial to calculate PVK. Its already extensively exploited.
2. When K values are closeby so that difference can be bruteforced quickly, then also PVK can be calculated.
3. When you somehow know the mathematical relationship between 2 K, like K2 =K1/2 or K2 = K1 + 1637737337373738373729826362936, whatever, then also PVK can be calculated.
4. When you have several Tx and there may be few bits common, either LSB or MSB, then also it's possible to calculate PVK through Lattice reduction. (Check minimum required Tx for Bit Leakage).
5. If the number of Tx is not sufficient for Lattice reduction but there is info about sufficient bit leakage, we could use the same Kangaroo solver approach on the Rvalue of Tx to get K.
6. We could mathematically generate Tx for known Leakage in Privatkeys and then try to bruteforce. For example Puzzle 130 is know to have a 126 bits Leakage in PVK. So several derived Tx from it can be considered for bruteforce.
7. There could be more which I am not aware of yet.

The main point is, there is no 100% sureshot method which will work on generic Tx. All different approaches either need some vulnerability or prior info or some bruteforce.

Yes this is done by using -stride option

K values used in Signature are kept secret as privatkeys. To find the relationship between 2 nonces the only possibility is to try bruteforce.
I had a sript in my rsz repo which extracts all Tx for an address and tries to solve for K and PrivatKeys if the distance between any 2 K values are small (ex. less than 2 billion).

Dear @Jean_Luc, What is your opinion about Stride in Kangaroo Algo, if probabilistically it can be shown to have lower total key space in that particular stride or stride range.

The jumptables are already defined and also the Paths of Kangaroos are deterministic based on X, so stride is possible in this algo or not?

You are the best person to mod it till 160 just in case.

Yes it seems Puzzle has gone beyond the continuous solvable limit. Perhaps some random jumper could catch the moving electron.

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.

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 only
• We 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

Not very sure about the 1:1 mapping although, previously i saw when b = 0x0, it leads to a very simplified loop which allowed to map from Pubkey to Privatekey. However I could not find any way to map b = 0x7 curve pubkey into a b = 0x0 curve pubkey.

Why Speculate.... Let's do a simulation....

Creating a Random Key in the Range of Puzzle 66

The Values obtained are

Running Kangaroo algo on this Pubkey

If you look, this has been run on Laptop with 9 year old GPU, still < 1 minute.
What will happen if someone run it on Recent Workstation GPU. It will be few seconds only.

You will have ample time to resubmit the transaction pending in current block by using your own Address having a little bit higher key.

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.

There has been several attempts to solve this bit range Puzzle https://bitcointalk.org/index.php?topic=5218972.0 through bruteforce of PrivateKey either the Address itself or the PubKeys through Kangaroo and BSGS algos.

This thread is another approach (a very slow one) which goes through the exact same procedure by which these puzzles were generated at the first hand. Creating the Wallet -> Mnemonics -> Seed -> List of Privatekeys -> Masked Privatekeys -> Check for known privatekeys collision.

Code : https://github.com/iceland2k14/btc_words/blob/main/seed_puzzle.py

This is more of an alternative exercise where if successful then all the remaining puzzles of ~ 1000 BTC will be solved all together. I know the probability of success is nearly zero. But still wanted to try to see how fast we can do it and what are the hurdles in this way. Any existing tool with what speed?

There are some assumptions which i think maybe correct/incorrect. Every opinion with logic could help in understanding more.
1. Wallet was new and puzzles 1-256 should corresponds to the Address index 0 to 255 from the wallet. Creator is very careful in making it. So this assumption maybe correct.
2. These Keys are sequentially generated by masking deterministic wallet privatekeys. So if any collision can be found with 10 masked Keys that is most likely the Correct seed.
3. The Puzzles are from year 2015 so the entropy bits could be either 128 or at max 192. Very little chance for 256.
4. Mnemonics used might have been English words, most probabilistic scenario.
5. Keys are generated using the standard BIP44 path with No Hardened Address route.

Assumption 2, 3, 4, 5 are dynamic and can be changed in the code easily. But if assumption 1 is incorrect then it is more difficult.

BTW, Just in case if the collision happens then you would see a result something like this image.

There are several possibility to find the Nonce used in RSZ. Forget the usual duplicate R value to solve for Nonce. But if you just consider R value as Xpoint, this can be tried to search using the Pubkey search algo. Where Pubkey = '02' + Xpoint

Other possibilities exists too. And feel free to develop your own.