Bitcoin puzzle transaction ~32 BTC prize to who solves it

[modma]

Nothing going on around these wood

We'd better start practicing crystal ball gazing to guess what the correct range of Puzzle 66 is

first sensible thought in last 10+ pages

[citb0in]

[...]
You can use import secp256k1 as ice
https://github.com/iceland2k14/secp256k1
(You must have this function in the same folder where the command is executed for it to work.)

here's a fix I wrote months ago and requested a pull for that allows you to run icelands' library from any folder.

[digaran]

Nothing going on around these wood

We play with  numbers with at least 20 decimal places here.
If you could make one Giga (10^9) guesses per second, it would take:

10^20 / 10^9 = 10^11 seconds

This is equivalent to roughly 3.2 million years. So, even with an incredibly fast computer making a Giga guesses per second, it would take millions of years to guess a 20-decimal-place number.

We'd better start practicing crystal ball gazing to guess what the correct range of Puzzle 66 is

According to my crystal ball, we'd only need 2339 years to completely scan the entire 66 bit range. Note that my crystal ball is uneducated and generates insensible results.😉

[nomachine]

[...]
You can use import secp256k1 as ice
https://github.com/iceland2k14/secp256k1
(You must have this function in the same folder where the command is executed for it to work.)

here's a fix I wrote months ago and requested a pull for that allows you to run icelands' library from any folder.

Thanks for the update.  

[ing1996]

Hi, so  i found 2 address similar 11 digits of hash160 in extraction of bit 130 that means if you scan on this range and have the private key of those one of two addresses we will split the 13 BTC ,

1st

1AoNf67iZUmz1Ck9eefUfTzWQJMN5pgcPG
02113ba90a97c020ade0f3d8d0369981a723fe2bc4352815df22dd3eafae13c5a5
6b7e582a29a549cc60b591279a963f02eff02f99

pk:00000000000000000000000000000000000de4cfcadfc034c963dd053d719e88

address to search in :116 bit range
1AoNf67iZrwMSYPTDbk3Sh1yXJCARQbD7a
039d0a0241abe2411f64b4f6d29f2e1b6c837b26b6bdded577c3fc93574d3d735c
6b7e582a29a7601b79761f9f153c300c3d988231
range: 804cfcadfc034c963dd053d719e88:fffffcadfc034c963dd053d719e88


2nd
1PtStkm2bWKryHVduVjciPUxVx9UeDcCXG
02dc52ba09b16bc5cbd25aca7c82dd924f81cd31ecf29ecb264fa2cc45393728b9
fb0d9859584e68c24c1698eea4d05d2822fe4b70
pk: ad0f6ba584b355089cf6ce9cc9774

address to search in 116 bit range
1PtStkm2bLM7EK7g1rnTLBxu6aLouVuULV
03ef06cec3b3e35f68ba78618e5a5cf8663cc1a3b685dcfd197c1c0030530b1293
fb0d9859584d782df3fe652d2da5a21c30f137f9
range: 804cfcadfc034c963dd053d719e88:fffffcadfc034c963dd053d719e88




if the pk found of one of those address we will split the prize.
they have the same 11 digits of hash160 that means maybe 90 pourcent is in that range

up, anyone interessing its same 11 digits hash160 so who can scan this range 116 and split the 13 btc ?

Hello! Can you find out how you get addresses with the same initial prefixes in which you say are in the same range ?!, what you do, subtract or add, can you explain! I saw your last post where you also found the same starting address prefixes which are both in the #66 range.
Even if they don't matter, just show how you calculate similar addresses and get their private key as well, show here!

1 - Convert the private key from hex to bytes
00000000000000000000000000000000000000000000000354d62e5f7a0d2eb2
b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03T\xd6._z\r.\xb2'

2 - Create a signing key from the private key bytes using the SECP256k1 elliptic curve
<ecdsa.keys.SigningKey object at 0x000002D447E14400>

3 - Get the corresponding public key
02b21a6b1590b145841a0dabbe71ea01e29ed60f0e468cff36445a9c92eb3a6375
VerifyingKey.from_string(b'\x02\xb2\x1ak\x15\x90\xb1E\x84\x1a\r\xab\xbeq\xea\x01\xe2\x9e\xd6\x0f\x0eF\x8c\xff6DZ\x9c\x92\xeb:cu', SECP256k1, sha1)

4 - Serialize the public key in compressed format (33 bytes)
b'\x02\xb2\x1ak\x15\x90\xb1E\x84\x1a\r\xab\xbeq\xea\x01\xe2\x9e\xd6\x0f\x0eF\x8c\xff6DZ\x9c\x92\xeb:cu'
02b21a6b1590b145841a0dabbe71ea01e29ed60f0e468cff36445a9c92eb3a6375

5 - Calculate the SHA-256 hash of the public key
b'\t\xb4\x87?D\'I\xef>\x86\xc7\x1d\x92\x86\xb1"\xa9\xdd\xf9v%\xa0\x03X\x88\xfb\x96%F\x0e\'\x16'
09b4873f442749ef3e86c71d9286b122a9ddf97625a0035888fb9625460e2716

6 - Calculate the RIPEMD-160 hash of the SHA-256 hash
<ripemd160 HASH object @ 0x000002D4477BF690>
b' \xd4Zjv%3BR\xc81\x8a\x87\xed053\xc1\xc7\xbb'
20d45a6a7625334252c8318a87ed303533c1c7bb

7 - Add the version byte (0x00 for mainnet) to the RIPEMD-160 hash
b'\x00'

8 - Extended RIPEMD-160 Hash
b'\x00 \xd4Zjv%3BR\xc81\x8a\x87\xed053\xc1\xc7\xbb'
0020d45a6a7625334252c8318a87ed303533c1c7bb

9 - Calculate the double SHA-256 checksum
b'\x01\x02l\xf90\xf6N\x8f\xeb\xca\xc8\xc2\x15\xd9Q\xb8i))\xb0\xce:\xb1\xba\x9e\xa4\xa1\x07_\x05\xe2\xa2'
b'\x01\x02l\xf9'

10 - Checksum: 01026cf9

11 - Append the checksum to the extended RIPEMD-160 hash
b'\x00 \xd4Zjv%3BR\xc81\x8a\x87\xed053\xc1\xc7\xbb\x01\x02l\xf9'
0020d45a6a7625334252c8318a87ed303533c1c7bb01026cf9

12 - Address (with checksum)
0020d45a6a7625334252c8318a87ed303533c1c7bb01026cf9

13 - Convert the bytes to a base58-encoded Bitcoin address
13zb1hQbWVnN3ag9GNS2vCraT8PQJDjVdr
provide an alternative, more straightforward method, if available instead of this ?

bro, how did you get the private key with the address 13ZB1HQBWNN3AG9GNS2VCRAT8PQJDJVDR, or did you happen to have it?If you compare it with the address #66 of the puzzle, then they have the same prefixes at the beginning of the address, also in the hash160. If you compare by range that this one and that one, both are in the #66 range. Maybe kalos15btc is right about something?!.

1 - Convert the private key from hex to bytes
00000000000000000000000000000000000000000000000354d62e5f7a0d2eb2
b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x03T\xd6._z\r.\xb2'

2 - Create a signing key from the private key bytes using the SECP256k1 elliptic curve
<ecdsa.keys.SigningKey object at 0x000002D447E14400>

3 - Get the corresponding public key
02b21a6b1590b145841a0dabbe71ea01e29ed60f0e468cff36445a9c92eb3a6375
VerifyingKey.from_string(b'\x02\xb2\x1ak\x15\x90\xb1E\x84\x1a\r\xab\xbeq\xea\x01\xe2\x9e\xd6\x0f\x0eF\x8c\xff6DZ\x9c\x92\xeb:cu', SECP256k1, sha1)

4 - Serialize the public key in compressed format (33 bytes)
b'\x02\xb2\x1ak\x15\x90\xb1E\x84\x1a\r\xab\xbeq\xea\x01\xe2\x9e\xd6\x0f\x0eF\x8c\xff6DZ\x9c\x92\xeb:cu'
02b21a6b1590b145841a0dabbe71ea01e29ed60f0e468cff36445a9c92eb3a6375

5 - Calculate the SHA-256 hash of the public key
b'\t\xb4\x87?D\'I\xef>\x86\xc7\x1d\x92\x86\xb1"\xa9\xdd\xf9v%\xa0\x03X\x88\xfb\x96%F\x0e\'\x16'
09b4873f442749ef3e86c71d9286b122a9ddf97625a0035888fb9625460e2716

6 - Calculate the RIPEMD-160 hash of the SHA-256 hash
<ripemd160 HASH object @ 0x000002D4477BF690>
b' \xd4Zjv%3BR\xc81\x8a\x87\xed053\xc1\xc7\xbb'
20d45a6a7625334252c8318a87ed303533c1c7bb

7 - Add the version byte (0x00 for mainnet) to the RIPEMD-160 hash
b'\x00'

8 - Extended RIPEMD-160 Hash
b'\x00 \xd4Zjv%3BR\xc81\x8a\x87\xed053\xc1\xc7\xbb'
0020d45a6a7625334252c8318a87ed303533c1c7bb

9 - Calculate the double SHA-256 checksum
b'\x01\x02l\xf90\xf6N\x8f\xeb\xca\xc8\xc2\x15\xd9Q\xb8i))\xb0\xce:\xb1\xba\x9e\xa4\xa1\x07_\x05\xe2\xa2'
b'\x01\x02l\xf9'

10 - Checksum: 01026cf9

11 - Append the checksum to the extended RIPEMD-160 hash
b'\x00 \xd4Zjv%3BR\xc81\x8a\x87\xed053\xc1\xc7\xbb\x01\x02l\xf9'
0020d45a6a7625334252c8318a87ed303533c1c7bb01026cf9

12 - Address (with checksum)
0020d45a6a7625334252c8318a87ed303533c1c7bb01026cf9

13 - Convert the bytes to a base58-encoded Bitcoin address
13zb1hQbWVnN3ag9GNS2vCraT8PQJDjVdr
provide an alternative, more straightforward method, if available instead of this ?

bro, how did you get the private key with the address 13ZB1HQBWNN3AG9GNS2VCRAT8PQJDJVDR, or did you happen to have it?If you compare it with the address #66 of the puzzle, then they have the same prefixes at the beginning of the address, also in the hash160. If you compare by range that this one and that one, both are in the #66 range. Maybe kalos15btc is right about something?!.

I understand how it works, you don't have to answer.

[tptkimikaze]

Anybody here familiar with Kangaroo? I have 1 stupid question. If let's say I put 1 million public address to search for private key and there's only 1 valid public address that fit the range. Will it take much more longer time to find the valid public key to get the private key? I tried just now with 100,000 public address, but the average time to solve shown unchanged.

I tried to put 1001 key with 1000 false public key and 1 puzzle 35 key. Why kangaroo can't solve it? Does that mean we can only put 1 public key at a time?

Looks like those who is searching for #66 are at 354d range, even myself also search at the same range. If my research correct, #66 range should be in between 354df - 358ae. Even this range will take ages to scan. LoL.

[vneos]

Looks like those who is searching for #66 are at 354d range, even myself also search at the same range. If my research correct, #66 range should be in between 354df - 358ae. Even this range will take ages to scan. LoL.

How did you come to this conclusion?

[digaran]

Anybody here familiar with Kangaroo? I have 1 stupid question. If let's say I put 1 million public address to search for private key and there's only 1 valid public address that fit the range. Will it take much more longer time to find the valid public key to get the private key? I tried just now with 100,000 public address, but the average time to solve shown unchanged.

I tried to put 1001 key with 1000 false public key and 1 puzzle 35 key. Why kangaroo can't solve it? Does that mean we can only put 1 public key at a time?

You can't find low range keys with kangaroo, 35 bit total range is less than 35 billion keys, I have tried with low ranges, my kangaroos start dying very fast, I can't even say goodbye. 🤣

I think more public keys you place in target file more you lose speed, but the speed reduction is insignificant even with few thousands less or more keys.

[tptkimikaze]

Looks like those who is searching for #66 are at 354d range, even myself also search at the same range. If my research correct, #66 range should be in between 354df - 358ae. Even this range will take ages to scan. LoL.

How did you come to this conclusion?

By breaking down bits and some bits combination. Maybe just some wild guessing and not sure if I am correct because I spots seems like some obvious pattern. I hope someone can find it on this range thought even if I don't get it. If the results were in this range, then I can use the same methods to proceed to 67. Unfortunately, the most lowest I can go is only on current range. I guess it boost some morale maybe I am right when I saw zahid8888 post PK start at 354d and have similarity on #66 Hash160.

Anybody here familiar with Kangaroo? I have 1 stupid question. If let's say I put 1 million public address to search for private key and there's only 1 valid public address that fit the range. Will it take much more longer time to find the valid public key to get the private key? I tried just now with 100,000 public address, but the average time to solve shown unchanged.

I tried to put 1001 key with 1000 false public key and 1 puzzle 35 key. Why kangaroo can't solve it? Does that mean we can only put 1 public key at a time?

You can't find low range keys with kangaroo, 35 bit total range is less than 35 billion keys, I have tried with low ranges, my kangaroos start dying very fast, I can't even say goodbye. 🤣

I think more public keys you place in target file more you lose speed, but the speed reduction is insignificant even with few thousands less or more keys.

Exactly. It dead kangaroo almost immediately when I start. I am just trying to figure out if Kangaroo able to search lots of fake key with 1 valid key at once because I have some idea to lower #130 bits down but need to do a lot of manual works.

Anybody here familiar with Kangaroo? I have 1 stupid question. If let's say I put 1 million public address to search for private key and there's only 1 valid public address that fit the range. Will it take much more longer time to find the valid public key to get the private key? I tried just now with 100,000 public address, but the average time to solve shown unchanged.

I tried to put 1001 key with 1000 false public key and 1 puzzle 35 key. Why kangaroo can't solve it? Does that mean we can only put 1 public key at a time?

You can't find low range keys with kangaroo, 35 bit total range is less than 35 billion keys, I have tried with low ranges, my kangaroos start dying very fast, I can't even say goodbye. 🤣

I think more public keys you place in target file more you lose speed, but the speed reduction is insignificant even with few thousands less or more keys.

I think it's quite significant but I haven't try till it solve. Will try later. For example I try with on #65 keys, it solve in less than 3 minutes. But when I put it with 100 fake keys and 1 real key, I run for 20 mins just now and it still didn't solve. I will try later to see how long it takes with 100 and 1000 keys with only 1 real key. Furthermore, I try with #64 keys while the range I set it on #65, it seems like kangaroo unable to solve it.

Update on 64. When I try to solve 64 Public Key but range setting at 65, it spends almost 5 times more with a correct range provided to search.

Update:
I don't think Kangaroo able to solve multiple address. Now I am trying to merge save file and see if it able to resolve.

[kalos15btc]

Looks like those who is searching for #66 are at 354d range, even myself also search at the same range. If my research correct, #66 range should be in between 354df - 358ae. Even this range will take ages to scan. LoL.

How did you come to this conclusion?

By breaking down bits and some bits combination. Maybe just some wild guessing and not sure if I am correct because I spots seems like some obvious pattern. I hope someone can find it on this range thought even if I don't get it. If the results were in this range, then I can use the same methods to proceed to 67. Unfortunately, the most lowest I can go is only on current range. I guess it boost some morale maybe I am right when I saw zahid8888 post PK start at 354d and have similarity on #66 Hash160.

thats what i said exactly, im substracting from 130 lower bit range and i get those address that start with same 14 digits of hash160 that means that address in that range of 90 or even 80 bit range

So any update on the progress of finding this key?
 First offset = 03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710
Half of above =
0291001b0dc6e5a2628cb4698eb00a6fb7dbd276dc2b214795f2fe52e61243aa9b
Half of 130?
0337374e00a32eaf009e9946035c0e69085627b60a844637d2b958dd83bcfa4383
The following is the subtracted key from #130
Second offset =
03d99bb89e8db75d20b882f13f8086fb39221858fa211de0346c926a93ae259b3a
Half of above?
03a3dc00bf5f7e7eec691569c7f67a15d3cdbb3a9994c9a5ec1430cffdb622cf9f

Now subtract half of first offset from half of #130 to get half of second offset.

Second offset is known, we need to work on first offset's half, use -1 divide by 2 script to reduce 18 bits from it, you'll have millions of new offsets and one of them is the target, now divide the #130 range by 2, subtract 18 bits from it and use the new range as your search range, input those millions offset keys and search the range.

Don't just try blind searching.😉

its not blind searching

03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710
hash160
3aaccf438388c4aeb0b433c7b778f25cb6ab244c


hash160
3aaccf438388c31f14410f489939d3d5eac88f19
pk: 48ea48b7a25627365cff38d

13 same hash160 digits, and its two substraction of 130 its not one substraction, 13 digits means its 80 pourcent in that range like puzzle 66

03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710 + 2786b52d106d22524ed9cf8a87d2
031ed6283a43d439eace1ee2815118cb6f16f475be60fa5ccc8598372d8c5f1995 # target

031ed6283a43d439eace1ee2815118cb6f16f475be60fa5ccc8598372d8c5f1995 # + 3.........................................
03633cbe3ec02b9401c5effa144c5b4d22f87940259634858fc7e59b1c09937852 # target

[mcdouglasx]

Looks like those who is searching for #66 are at 354d range, even myself also search at the same range. If my research correct, #66 range should be in between 354df - 358ae. Even this range will take ages to scan. LoL.

How did you come to this conclusion?

By breaking down bits and some bits combination. Maybe just some wild guessing and not sure if I am correct because I spots seems like some obvious pattern. I hope someone can find it on this range thought even if I don't get it. If the results were in this range, then I can use the same methods to proceed to 67. Unfortunately, the most lowest I can go is only on current range. I guess it boost some morale maybe I am right when I saw zahid8888 post PK start at 354d and have similarity on #66 Hash160.

thats what i said exactly, im substracting from 130 lower bit range and i get those address that start with same 14 digits of hash160 that means that address in that range of 90 or even 80 bit range

So any update on the progress of finding this key?
 First offset = 03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710
Half of above =
0291001b0dc6e5a2628cb4698eb00a6fb7dbd276dc2b214795f2fe52e61243aa9b
Half of 130?
0337374e00a32eaf009e9946035c0e69085627b60a844637d2b958dd83bcfa4383
The following is the subtracted key from #130
Second offset =
03d99bb89e8db75d20b882f13f8086fb39221858fa211de0346c926a93ae259b3a
Half of above?
03a3dc00bf5f7e7eec691569c7f67a15d3cdbb3a9994c9a5ec1430cffdb622cf9f

Now subtract half of first offset from half of #130 to get half of second offset.

Second offset is known, we need to work on first offset's half, use -1 divide by 2 script to reduce 18 bits from it, you'll have millions of new offsets and one of them is the target, now divide the #130 range by 2, subtract 18 bits from it and use the new range as your search range, input those millions offset keys and search the range.

Don't just try blind searching.😉

its not blind searching

03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710
hash160
3aaccf438388c4aeb0b433c7b778f25cb6ab244c


hash160
3aaccf438388c31f14410f489939d3d5eac88f19
pk: 48ea48b7a25627365cff38d

13 same hash160 digits, and its two substraction of 130 its not one substraction, 13 digits means its 80 pourcent in that range like puzzle 66

03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710 + 2786b52d106d22524ed9cf8a87d2
031ed6283a43d439eace1ee2815118cb6f16f475be60fa5ccc8598372d8c5f1995 # target

031ed6283a43d439eace1ee2815118cb6f16f475be60fa5ccc8598372d8c5f1995 # + 3.........................................
03633cbe3ec02b9401c5effa144c5b4d22f87940259634858fc7e59b1c09937852 # target

What you are doing is believing in an illusion, if you search in any range you will find the same matches, so in all honesty you are wasting your time comparing hash160 with the sequence of the curve.

[tptkimikaze]

Looks like those who is searching for #66 are at 354d range, even myself also search at the same range. If my research correct, #66 range should be in between 354df - 358ae. Even this range will take ages to scan. LoL.

How did you come to this conclusion?

By breaking down bits and some bits combination. Maybe just some wild guessing and not sure if I am correct because I spots seems like some obvious pattern. I hope someone can find it on this range thought even if I don't get it. If the results were in this range, then I can use the same methods to proceed to 67. Unfortunately, the most lowest I can go is only on current range. I guess it boost some morale maybe I am right when I saw zahid8888 post PK start at 354d and have similarity on #66 Hash160.

thats what i said exactly, im substracting from 130 lower bit range and i get those address that start with same 14 digits of hash160 that means that address in that range of 90 or even 80 bit range

So any update on the progress of finding this key?
 First offset = 03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710
Half of above =
0291001b0dc6e5a2628cb4698eb00a6fb7dbd276dc2b214795f2fe52e61243aa9b
Half of 130?
0337374e00a32eaf009e9946035c0e69085627b60a844637d2b958dd83bcfa4383
The following is the subtracted key from #130
Second offset =
03d99bb89e8db75d20b882f13f8086fb39221858fa211de0346c926a93ae259b3a
Half of above?
03a3dc00bf5f7e7eec691569c7f67a15d3cdbb3a9994c9a5ec1430cffdb622cf9f

Now subtract half of first offset from half of #130 to get half of second offset.

Second offset is known, we need to work on first offset's half, use -1 divide by 2 script to reduce 18 bits from it, you'll have millions of new offsets and one of them is the target, now divide the #130 range by 2, subtract 18 bits from it and use the new range as your search range, input those millions offset keys and search the range.

Don't just try blind searching.😉

its not blind searching

03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710
hash160
3aaccf438388c4aeb0b433c7b778f25cb6ab244c


hash160
3aaccf438388c31f14410f489939d3d5eac88f19
pk: 48ea48b7a25627365cff38d

13 same hash160 digits, and its two substraction of 130 its not one substraction, 13 digits means its 80 pourcent in that range like puzzle 66

03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710 + 2786b52d106d22524ed9cf8a87d2
031ed6283a43d439eace1ee2815118cb6f16f475be60fa5ccc8598372d8c5f1995 # target

031ed6283a43d439eace1ee2815118cb6f16f475be60fa5ccc8598372d8c5f1995 # + 3.........................................
03633cbe3ec02b9401c5effa144c5b4d22f87940259634858fc7e59b1c09937852 # target

What you are doing is believing in an illusion, if you search in any range you will find the same matches, so in all honesty you are wasting your time comparing hash160 with the sequence of the curve.

Human being needs dream big, hopes, keep trying and determination to continue. Nobody will know whether the dreams will come true or not. If relies only on bruteforcing, how long it will take for #66? It took everyone 3 years to bruteforcing #64, how long it takes for #66? 150 years by bruteforcing? If only bruteforcing without trying any new idea, then why don't just give up because it's less likely to break until the day I die.

[mcdouglasx]

Looks like those who is searching for #66 are at 354d range, even myself also search at the same range. If my research correct, #66 range should be in between 354df - 358ae. Even this range will take ages to scan. LoL.

How did you come to this conclusion?

By breaking down bits and some bits combination. Maybe just some wild guessing and not sure if I am correct because I spots seems like some obvious pattern. I hope someone can find it on this range thought even if I don't get it. If the results were in this range, then I can use the same methods to proceed to 67. Unfortunately, the most lowest I can go is only on current range. I guess it boost some morale maybe I am right when I saw zahid8888 post PK start at 354d and have similarity on #66 Hash160.

thats what i said exactly, im substracting from 130 lower bit range and i get those address that start with same 14 digits of hash160 that means that address in that range of 90 or even 80 bit range

So any update on the progress of finding this key?
 First offset = 03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710
Half of above =
0291001b0dc6e5a2628cb4698eb00a6fb7dbd276dc2b214795f2fe52e61243aa9b
Half of 130?
0337374e00a32eaf009e9946035c0e69085627b60a844637d2b958dd83bcfa4383
The following is the subtracted key from #130
Second offset =
03d99bb89e8db75d20b882f13f8086fb39221858fa211de0346c926a93ae259b3a
Half of above?
03a3dc00bf5f7e7eec691569c7f67a15d3cdbb3a9994c9a5ec1430cffdb622cf9f

Now subtract half of first offset from half of #130 to get half of second offset.

Second offset is known, we need to work on first offset's half, use -1 divide by 2 script to reduce 18 bits from it, you'll have millions of new offsets and one of them is the target, now divide the #130 range by 2, subtract 18 bits from it and use the new range as your search range, input those millions offset keys and search the range.

Don't just try blind searching.😉

its not blind searching

03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710
hash160
3aaccf438388c4aeb0b433c7b778f25cb6ab244c


hash160
3aaccf438388c31f14410f489939d3d5eac88f19
pk: 48ea48b7a25627365cff38d

13 same hash160 digits, and its two substraction of 130 its not one substraction, 13 digits means its 80 pourcent in that range like puzzle 66

03982a5a42895a5cfe4b9b98e49f9389ebf9b3bf91c2289f1c5db3d944f46ec710 + 2786b52d106d22524ed9cf8a87d2
031ed6283a43d439eace1ee2815118cb6f16f475be60fa5ccc8598372d8c5f1995 # target

031ed6283a43d439eace1ee2815118cb6f16f475be60fa5ccc8598372d8c5f1995 # + 3.........................................
03633cbe3ec02b9401c5effa144c5b4d22f87940259634858fc7e59b1c09937852 # target

What you are doing is believing in an illusion, if you search in any range you will find the same matches, so in all honesty you are wasting your time comparing hash160 with the sequence of the curve.

Human being needs dream big, hopes, keep trying and determination to continue. Nobody will know whether the dreams will come true or not. If relies only on bruteforcing, how long it will take for #66? It took everyone 3 years to bruteforcing #64, how long it takes for #66? 150 years by bruteforcing? If only bruteforcing without trying any new idea, then why don't just give up because it's less likely to break until the day I die.

You are right, but if you dream of things with coherence, compare hash160 with ECC, it has no coherence at all, there is no relationship, sequence, that is what hashes are for, each hash is similar to randomizing each result.

Edit:
The best test to refute this is to choose a starting point

5df3abf

and search the entire range 2**256

You will see that you will find random matches along the way that start at 5df3abf

[artistk]

I've tried keyhunt random on CPU very slow.
And cubitcrack counting random ranges I give it time to time gave me about 10x speed of keyhunt, but without the random option, I don't like it.

I've tried to find any relation or pattern between the previous puzzles and got absolutely nothing!

I'd like to have that random option on GPU! is there any tool for that please?

Good thing I've learned some Python and found it's actually slow  
I started to learn C++ and CUDA hopefully to create a better tool, is there any libraries you can recommend to work with?

Looking at the puzzles that are still unsolved and how big those ranges are! there's no way in our life time! But it's fun to play!

[digaran]

For keys with no available public key, the only possible solution is an especial hardware like an ASIC miner to grind sha256 and rmd160 hashes at a rate of trillions/s for the cheapest ASIC and thousands of T/s for advanced ASICs. Then you could wait 10 years and see if development can increase the hash per second for your ASIC or not.

So, other than engineers, a factory with billions in equipment and a few million to spend on prototypes, what else we don't have?

Oh and that's just for keys from 66 up to 80.
However if you know the public key, there is at least a chance that you could work out things mathematically.

Regarding unexposed keys, of course there is a mathematical solution which is finding hash 160 and then hash 256 collisions, but I haven't seen any tool doing that, and it's not discussed here at all.

Ps, I have some ideas about finding collisions, it is related to sha256 checksum operation, if I could change the checksum requirement from 8 first characters of the second hash, by making it 32 character, I could work on finding collisions, in fact if we could replace sha256 with rmd160 and code something to extract rmd160 double hash checksum by using the first 20 characters of either first or second hash, again we could start working on collisions.

But that's all just an idea, I don't know if it works or not.

[bestie1549]

I've tried keyhunt random on CPU very slow.
And cubitcrack counting random ranges I give it time to time gave me about 10x speed of keyhunt, but without the random option, I don't like it.

I've tried to find any relation or pattern between the previous puzzles and got absolutely nothing!

I'd like to have that random option on GPU! is there any tool for that please?

Good thing I've learned some Python and found it's actually slow  
I started to learn C++ and CUDA hopefully to create a better tool, is there any libraries you can recommend to work with?

Looking at the puzzles that are still unsolved and how big those ranges are! there's no way in our life time! But it's fun to play!

vanbitcracken2 or KeyHuntCuda

but mind you, random option resets your chance to 100 times the initial time to find the key you are looking for withing the specified 66 bit range
for example
If it'd take you 300 years to scan the range
expect 30,000 years on a random search and you will still not stand the chance either, except you're able to program the random to note the range it had already scanned which is impossible because why would it be called random then?

rrandom option is the least thought anyone should be thinking about right now

only except you'd want to scan a specific 50 bit range randomly which you'd have to not down just like the puzzle 66 pool.
so if you want to consent to Random search for the puzzle 66
It's best to resort to the specific bit range search where you'd have to note every defeated range in order for you not to multiscan the range you've already scanned

For keys with no available public key, the only possible solution is an especial hardware like an ASIC miner to grind sha256 and rmd160 hashes at a rate of trillions/s for the cheapest ASIC and thousands of T/s for advanced ASICs. Then you could wait 10 years and see if development can increase the hash per second for your ASIC or not.

So, other than engineers, a factory with billions in equipment and a few million to spend on prototypes, what else we don't have?

Oh and that's just for keys from 66 up to 80.
However if you know the public key, there is at least a chance that you could work out things mathematically.

Regarding unexposed keys, of course there is a mathematical solution which is finding hash 160 and then hash 256 collisions, but I haven't seen any tool doing that, and it's not discussed here at all.

Ps, I have some ideas about finding collisions, it is related to sha256 checksum operation, if I could change the checksum requirement from 8 first characters of the second hash, by making it 32 character, I could work on finding collisions, in fact if we could replace sha256 with rmd160 and code something to extract rmd160 double hash checksum by using the first 20 characters of either first or second hash, again we could start working on collisions.

But that's all just an idea, I don't know if it works or not.

quote "that's the idea that has been running through my mind all along"

I have been trying to code some kind of collision where it'd only workout sha256 and rmd 160 while retaining the pubkey
But even if it worked out as I've been trying we'd only be stuck with probably 118 if we can successfully extract the pubkey from sha256 rmd collisions

but that'd definitely still give us an edge over the current situation where puzzle 66 is grinding the hell out of me

[digaran]

So after some research, I have found a new and yet useless solution, is there a script which could divide a point by a set range?

Like dividing target public key by 1000, 999, 998, 997 etc, we select start and end range for division and it should divide the target as many times as we specify.

For educational purposes only.😉

[nomachine]

Looks like those who is searching for #66 are at 354d range, even myself also search at the same range. If my research correct, #66 range should be in between 354df - 358ae. Even this range will take ages to scan. LoL.

How did you come to this conclusion?

By breaking down bits and some bits combination. Maybe just some wild guessing and not sure if I am correct because I spots seems like some obvious pattern. I hope someone can find it on this range thought even if I don't get it. If the results were in this range, then I can use the same methods to proceed to 67. Unfortunately, the most lowest I can go is only on current range. I guess it boost some morale maybe I am right when I saw zahid8888 post PK start at 354d and have similarity on #66 Hash160.

Anybody here familiar with Kangaroo? I have 1 stupid question. If let's say I put 1 million public address to search for private key and there's only 1 valid public address that fit the range. Will it take much more longer time to find the valid public key to get the private key? I tried just now with 100,000 public address, but the average time to solve shown unchanged.

I tried to put 1001 key with 1000 false public key and 1 puzzle 35 key. Why kangaroo can't solve it? Does that mean we can only put 1 public key at a time?

You can't find low range keys with kangaroo, 35 bit total range is less than 35 billion keys, I have tried with low ranges, my kangaroos start dying very fast, I can't even say goodbye. 🤣

I think more public keys you place in target file more you lose speed, but the speed reduction is insignificant even with few thousands less or more keys.

Exactly. It dead kangaroo almost immediately when I start. I am just trying to figure out if Kangaroo able to search lots of fake key with 1 valid key at once because I have some idea to lower #130 bits down but need to do a lot of manual works.

Anybody here familiar with Kangaroo? I have 1 stupid question. If let's say I put 1 million public address to search for private key and there's only 1 valid public address that fit the range. Will it take much more longer time to find the valid public key to get the private key? I tried just now with 100,000 public address, but the average time to solve shown unchanged.

I tried to put 1001 key with 1000 false public key and 1 puzzle 35 key. Why kangaroo can't solve it? Does that mean we can only put 1 public key at a time?

You can't find low range keys with kangaroo, 35 bit total range is less than 35 billion keys, I have tried with low ranges, my kangaroos start dying very fast, I can't even say goodbye. 🤣

I think more public keys you place in target file more you lose speed, but the speed reduction is insignificant even with few thousands less or more keys.

I think it's quite significant but I haven't try till it solve. Will try later. For example I try with on #65 keys, it solve in less than 3 minutes. But when I put it with 100 fake keys and 1 real key, I run for 20 mins just now and it still didn't solve. I will try later to see how long it takes with 100 and 1000 keys with only 1 real key. Furthermore, I try with #64 keys while the range I set it on #65, it seems like kangaroo unable to solve it.

Update on 64. When I try to solve 64 Public Key but range setting at 65, it spends almost 5 times more with a correct range provided to search.

Update:
I don't think Kangaroo able to solve multiple address. Now I am trying to merge save file and see if it able to resolve.

He is joking.

Sat Sep  9 11:51:57 2023
P-table prepared
tame and wild herds is being prepared
Using 12 CPU cores for parallel search.
Public key: 02f6a8148a62320e149cb15c544fe8a25ab483a0095d2280d03b8a00a7feada13d time: 2.66 sec


For 2 seconds. 

Code:

import time
import os
import sys
import random
import gmpy2
from gmpy2 import mpz
from functools import lru_cache
from multiprocessing import Pool, cpu_count

modulo = gmpy2.mpz(115792089237316195423570985008687907853269984665640564039457584007908834671663)
order = gmpy2.mpz(115792089237316195423570985008687907852837564279074904382605163141518161494337)
Gx = gmpy2.mpz(55066263022277343669578718895168534326250603453777594175500187360389116729240)
Gy = gmpy2.mpz(32670510020758816978083085130507043184471273380659243275938904335757337482424)

class Point:
    def __init__(self, x=0, y=0):
        self.x = x
        self.y = y

PG = Point(Gx, Gy)
Z = Point(0, 0)  # zero-point, infinite in real x,y-plane

def mul2(P, p=modulo):
    c = (3 * P.x * P.x * pow(2 * P.y, -1, p)) % p
    R = Point()
    R.x = (c * c - 2 * P.x) % p
    R.y = (c * (P.x - R.x) - P.y) % p
    return R

def add(P, Q, p=modulo):
    dx = Q.x - P.x
    dy = Q.y - P.y
    c = dy * gmpy2.invert(dx, p) % p
    R = Point()
    R.x = (c * c - P.x - Q.x) % p
    R.y = (c * (P.x - R.x) - P.y) % p
    return R

@lru_cache(maxsize=None)
def X2Y(X, y_parity, p=modulo):
    Y = 3
    tmp = 1
    while Y:
        if Y & 1:
            tmp = tmp * X % p
        Y >>= 1
        X = X * X % p

    X = (tmp + 7) % p

    Y = (p + 1) // 4
    tmp = 1
    while Y:
        if Y & 1:
            tmp = tmp * X % p
        Y >>= 1
        X = X * X % p

    Y = tmp

    if Y % 2 != y_parity:
        Y = -Y % p

    return Y

def compute_P_table():
    P = [PG]
    for k in range(255):
        P.append(mul2(P[k]))
    return P

P = compute_P_table()

os.system('clear')
t = time.ctime()
sys.stdout.write("\033[01;33m")
sys.stdout.write(t + "\n")
sys.stdout.write("P-table prepared" + "\n")
sys.stdout.write("tame and wild herds is being prepared" + "\n")
sys.stdout.flush()

def comparator(A, Ak, B, Bk):
    result = set(A).intersection(set(B))
    if result:
        sol_kt = A.index(next(iter(result)))
        sol_kw = B.index(next(iter(result)))
        print('total time: %.2f sec' % (time.time() - starttime))
        difference = Ak[sol_kt] - Bk[sol_kw]
        HEX = "%064x" % difference  # Convert to a hexadecimal string
        t = time.ctime()
        print('SOLVED:', t, difference)
        with open("KEYFOUNDKEYFOUND.txt", 'a') as file:
            file.write('\n\nSOLVED ' + t)
            file.write('\nPrivate Key (decimal): ' + str(difference))
            file.write('\nPrivate Key (hex): ' + HEX)
            file.write('\n-------------------------------------------------------------------------------------------------------------------------------------\n')
        return True
    else:
        return False

def check(P, Pindex, DP_rarity, file2save, A, Ak, B, Bk):
    if P.x % DP_rarity == 0:
        A.append(P.x)
        Ak.append(Pindex)
        with open(file2save, 'a') as file:
            file.write(('%064x %d' % (P.x, Pindex)) + "\n")
        # Print the public key
        message = "\rPublic key: {:064x}".format(P.x)
        sys.stdout.write("\033[01;33m")
        sys.stdout.write(message)
        sys.stdout.flush()
        return comparator(A, Ak, B, Bk)
    else:
        return False

# Memoization for ecmultiply
ecmultiply_memo = {}

def ecmultiply(k, P=PG, p=modulo):
    if k == 0:
        return Z
    elif k == 1:
        return P
    elif k % 2 == 0:
        if k in ecmultiply_memo:
            return ecmultiply_memo[k]
        else:
            result = ecmultiply(k // 2, mul2(P, p), p)
            ecmultiply_memo[k] = result
            return result
    else:
        return add(P, ecmultiply((k - 1) // 2, mul2(P, p), p))

def mulk(k, P=PG, p=modulo):
    if k == 0:
        return Z
    elif k == 1:
        return P
    elif k % 2 == 0:
        return mulk(k // 2, mul2(P, p), p)
    else:
        return add(P, mulk((k - 1) // 2, mul2(P, p), p))

def search(Nt, Nw, puzzle, kangoo_power, starttime):
    DP_rarity = 1 << ((puzzle - 2 * kangoo_power) // 2 - 2)
    hop_modulo = ((puzzle - 1) // 2) + kangoo_power
    T, t, dt = [], [], []
    W, w, dw = [], [], []
    for k in range(Nt):
        t.append((3 << (puzzle - 2)) + random.randint(1, (1 << (puzzle - 1))))
        T.append(mulk(t[k]))
        dt.append(0)
    for k in range(Nw):
        w.append(random.randint(1, (1 << (puzzle - 1))))
        W.append(add(W0, mulk(w[k])))
        dw.append(0)
    oldtime = time.time()
    Hops, Hops_old = 0, 0
    t0 = time.time()
    oldtime = time.time()
    starttime = oldtime
    while True:
        for k in range(Nt):
            Hops += 1
            pw = T[k].x % hop_modulo
            dt[k] = 1 << pw
            solved = check(T[k], t[k], DP_rarity, "tame.txt", T, t, W, w)
            if solved:
                return 'sol. time: %.2f sec' % (time.time() - starttime)
            t[k] += dt[k]
            T[k] = add(P[pw], T[k])
        for k in range(Nw):
            Hops += 1
            pw = W[k].x % hop_modulo
            dw[k] = 1 << pw
            solved = check(W[k], w[k], DP_rarity, "wild.txt", W, w, T, t)
            if solved:
                return 'sol. time: %.2f sec' % (time.time() - starttime)
            w[k] += dw[k]
            W[k] = add(P[pw], W[k])

puzzle = 35
compressed_public_key = "02f6a8148a62320e149cb15c544fe8a25ab483a0095d2280d03b8a00a7feada13d"  # Puzzle 35
kangoo_power = 9 #For Puzzle 50-56 use 9 to 11, for Puzzle 60-80 use 14 to 16 / 24 cores or above preferred
Nt = Nw = 2 ** kangoo_power
X = int(compressed_public_key, 16)
Y = X2Y(X % (2 ** 256), X >> 256)
if Y % 2 != (X >> 256) % 2:
    Y = modulo - Y
X = X % (2 ** 256)
W0 = Point(X, Y)
starttime = oldtime = time.time()

Hops = 0
random.seed()

hops_list = []
N_tests = kangoo_power

for k in range(N_tests):
    buffer_size = 1024 * 1024 * 1024  # 1024 MB in bytes
    with open("tame.txt", 'w', buffering=buffer_size) as tame_file, open("wild.txt", 'w', buffering=buffer_size) as wild_file:
        tame_file.write('')
        wild_file.write('')

def parallel_search(process_count, Nt, Nw, puzzle, kangoo_power, starttime):
    pool = Pool(process_count)
    results = pool.starmap(search, [(Nt, Nw, puzzle, kangoo_power, starttime)] * process_count)
    pool.close()
    pool.join()
    return results

if __name__ == '__main__':
    process_count = cpu_count()  # Use all available CPU cores
    print(f"Using {process_count} CPU cores for parallel search.")
    results = parallel_search(process_count, Nt, Nw, puzzle, kangoo_power, starttime)
    for result in results:
        print(result)

[tptkimikaze]

Looks like those who is searching for #66 are at 354d range, even myself also search at the same range. If my research correct, #66 range should be in between 354df - 358ae. Even this range will take ages to scan. LoL.

How did you come to this conclusion?

By breaking down bits and some bits combination. Maybe just some wild guessing and not sure if I am correct because I spots seems like some obvious pattern. I hope someone can find it on this range thought even if I don't get it. If the results were in this range, then I can use the same methods to proceed to 67. Unfortunately, the most lowest I can go is only on current range. I guess it boost some morale maybe I am right when I saw zahid8888 post PK start at 354d and have similarity on #66 Hash160.

Anybody here familiar with Kangaroo? I have 1 stupid question. If let's say I put 1 million public address to search for private key and there's only 1 valid public address that fit the range. Will it take much more longer time to find the valid public key to get the private key? I tried just now with 100,000 public address, but the average time to solve shown unchanged.

I tried to put 1001 key with 1000 false public key and 1 puzzle 35 key. Why kangaroo can't solve it? Does that mean we can only put 1 public key at a time?

You can't find low range keys with kangaroo, 35 bit total range is less than 35 billion keys, I have tried with low ranges, my kangaroos start dying very fast, I can't even say goodbye. 🤣

I think more public keys you place in target file more you lose speed, but the speed reduction is insignificant even with few thousands less or more keys.

Exactly. It dead kangaroo almost immediately when I start. I am just trying to figure out if Kangaroo able to search lots of fake key with 1 valid key at once because I have some idea to lower #130 bits down but need to do a lot of manual works.

Anybody here familiar with Kangaroo? I have 1 stupid question. If let's say I put 1 million public address to search for private key and there's only 1 valid public address that fit the range. Will it take much more longer time to find the valid public key to get the private key? I tried just now with 100,000 public address, but the average time to solve shown unchanged.

I tried to put 1001 key with 1000 false public key and 1 puzzle 35 key. Why kangaroo can't solve it? Does that mean we can only put 1 public key at a time?

You can't find low range keys with kangaroo, 35 bit total range is less than 35 billion keys, I have tried with low ranges, my kangaroos start dying very fast, I can't even say goodbye. 🤣

I think more public keys you place in target file more you lose speed, but the speed reduction is insignificant even with few thousands less or more keys.

I think it's quite significant but I haven't try till it solve. Will try later. For example I try with on #65 keys, it solve in less than 3 minutes. But when I put it with 100 fake keys and 1 real key, I run for 20 mins just now and it still didn't solve. I will try later to see how long it takes with 100 and 1000 keys with only 1 real key. Furthermore, I try with #64 keys while the range I set it on #65, it seems like kangaroo unable to solve it.

Update on 64. When I try to solve 64 Public Key but range setting at 65, it spends almost 5 times more with a correct range provided to search.

Update:
I don't think Kangaroo able to solve multiple address. Now I am trying to merge save file and see if it able to resolve.

He is joking.

Sat Sep  9 11:51:57 2023
P-table prepared
tame and wild herds is being prepared
Using 12 CPU cores for parallel search.
Public key: 02f6a8148a62320e149cb15c544fe8a25ab483a0095d2280d03b8a00a7feada13d time: 2.66 sec


For 2 seconds.  

Code:

import time
import os
import sys
import random
import gmpy2
from gmpy2 import mpz
from functools import lru_cache
from multiprocessing import Pool, cpu_count

modulo = gmpy2.mpz(115792089237316195423570985008687907853269984665640564039457584007908834671663)
order = gmpy2.mpz(115792089237316195423570985008687907852837564279074904382605163141518161494337)
Gx = gmpy2.mpz(55066263022277343669578718895168534326250603453777594175500187360389116729240)
Gy = gmpy2.mpz(32670510020758816978083085130507043184471273380659243275938904335757337482424)

class Point:
    def __init__(self, x=0, y=0):
        self.x = x
        self.y = y

PG = Point(Gx, Gy)
Z = Point(0, 0)  # zero-point, infinite in real x,y-plane

def mul2(P, p=modulo):
    c = (3 * P.x * P.x * pow(2 * P.y, -1, p)) % p
    R = Point()
    R.x = (c * c - 2 * P.x) % p
    R.y = (c * (P.x - R.x) - P.y) % p
    return R

def add(P, Q, p=modulo):
    dx = Q.x - P.x
    dy = Q.y - P.y
    c = dy * gmpy2.invert(dx, p) % p
    R = Point()
    R.x = (c * c - P.x - Q.x) % p
    R.y = (c * (P.x - R.x) - P.y) % p
    return R

@lru_cache(maxsize=None)
def X2Y(X, y_parity, p=modulo):
    Y = 3
    tmp = 1
    while Y:
        if Y & 1:
            tmp = tmp * X % p
        Y >>= 1
        X = X * X % p

    X = (tmp + 7) % p

    Y = (p + 1) // 4
    tmp = 1
    while Y:
        if Y & 1:
            tmp = tmp * X % p
        Y >>= 1
        X = X * X % p

    Y = tmp

    if Y % 2 != y_parity:
        Y = -Y % p

    return Y

def compute_P_table():
    P = [PG]
    for k in range(255):
        P.append(mul2(P[k]))
    return P

P = compute_P_table()

os.system('clear')
t = time.ctime()
sys.stdout.write("\033[01;33m")
sys.stdout.write(t + "\n")
sys.stdout.write("P-table prepared" + "\n")
sys.stdout.write("tame and wild herds is being prepared" + "\n")
sys.stdout.flush()

def comparator(A, Ak, B, Bk):
    result = set(A).intersection(set(B))
    if result:
        sol_kt = A.index(next(iter(result)))
        sol_kw = B.index(next(iter(result)))
        print('total time: %.2f sec' % (time.time() - starttime))
        difference = Ak[sol_kt] - Bk[sol_kw]
        HEX = "%064x" % difference  # Convert to a hexadecimal string
        t = time.ctime()
        print('SOLVED:', t, difference)
        with open("KEYFOUNDKEYFOUND.txt", 'a') as file:
            file.write('\n\nSOLVED ' + t)
            file.write('\nPrivate Key (decimal): ' + str(difference))
            file.write('\nPrivate Key (hex): ' + HEX)
            file.write('\n-------------------------------------------------------------------------------------------------------------------------------------\n')
        return True
    else:
        return False

def check(P, Pindex, DP_rarity, file2save, A, Ak, B, Bk):
    if P.x % DP_rarity == 0:
        A.append(P.x)
        Ak.append(Pindex)
        with open(file2save, 'a') as file:
            file.write(('%064x %d' % (P.x, Pindex)) + "\n")
        # Print the public key
        message = "\rPublic key: {:064x}".format(P.x)
        sys.stdout.write("\033[01;33m")
        sys.stdout.write(message)
        sys.stdout.flush()
        return comparator(A, Ak, B, Bk)
    else:
        return False

# Memoization for ecmultiply
ecmultiply_memo = {}

def ecmultiply(k, P=PG, p=modulo):
    if k == 0:
        return Z
    elif k == 1:
        return P
    elif k % 2 == 0:
        if k in ecmultiply_memo:
            return ecmultiply_memo[k]
        else:
            result = ecmultiply(k // 2, mul2(P, p), p)
            ecmultiply_memo[k] = result
            return result
    else:
        return add(P, ecmultiply((k - 1) // 2, mul2(P, p), p))

def mulk(k, P=PG, p=modulo):
    if k == 0:
        return Z
    elif k == 1:
        return P
    elif k % 2 == 0:
        return mulk(k // 2, mul2(P, p), p)
    else:
        return add(P, mulk((k - 1) // 2, mul2(P, p), p))

def search(Nt, Nw, puzzle, kangoo_power, starttime):
    DP_rarity = 1 << ((puzzle - 2 * kangoo_power) // 2 - 2)
    hop_modulo = ((puzzle - 1) // 2) + kangoo_power
    T, t, dt = [], [], []
    W, w, dw = [], [], []
    for k in range(Nt):
        t.append((3 << (puzzle - 2)) + random.randint(1, (1 << (puzzle - 1))))
        T.append(mulk(t[k]))
        dt.append(0)
    for k in range(Nw):
        w.append(random.randint(1, (1 << (puzzle - 1))))
        W.append(add(W0, mulk(w[k])))
        dw.append(0)
    oldtime = time.time()
    Hops, Hops_old = 0, 0
    t0 = time.time()
    oldtime = time.time()
    starttime = oldtime
    while True:
        for k in range(Nt):
            Hops += 1
            pw = T[k].x % hop_modulo
            dt[k] = 1 << pw
            solved = check(T[k], t[k], DP_rarity, "tame.txt", T, t, W, w)
            if solved:
                return 'sol. time: %.2f sec' % (time.time() - starttime)
            t[k] += dt[k]
            T[k] = add(P[pw], T[k])
        for k in range(Nw):
            Hops += 1
            pw = W[k].x % hop_modulo
            dw[k] = 1 << pw
            solved = check(W[k], w[k], DP_rarity, "wild.txt", W, w, T, t)
            if solved:
                return 'sol. time: %.2f sec' % (time.time() - starttime)
            w[k] += dw[k]
            W[k] = add(P[pw], W[k])

puzzle = 35
compressed_public_key = "02f6a8148a62320e149cb15c544fe8a25ab483a0095d2280d03b8a00a7feada13d"  # Puzzle 35
kangoo_power = 9 #For Puzzle 50-56 use 9 to 11, for Puzzle 60-80 use 14 to 16 / 24 cores or above preferred
Nt = Nw = 2 ** kangoo_power
X = int(compressed_public_key, 16)
Y = X2Y(X % (2 ** 256), X >> 256)
if Y % 2 != (X >> 256) % 2:
    Y = modulo - Y
X = X % (2 ** 256)
W0 = Point(X, Y)
starttime = oldtime = time.time()

Hops = 0
random.seed()

hops_list = []
N_tests = kangoo_power

for k in range(N_tests):
    buffer_size = 1024 * 1024 * 1024  # 1024 MB in bytes
    with open("tame.txt", 'w', buffering=buffer_size) as tame_file, open("wild.txt", 'w', buffering=buffer_size) as wild_file:
        tame_file.write('')
        wild_file.write('')

def parallel_search(process_count, Nt, Nw, puzzle, kangoo_power, starttime):
    pool = Pool(process_count)
    results = pool.starmap(search, [(Nt, Nw, puzzle, kangoo_power, starttime)] * process_count)
    pool.close()
    pool.join()
    return results

if __name__ == '__main__':
    process_count = cpu_count()  # Use all available CPU cores
    print(f"Using {process_count} CPU cores for parallel search.")
    results = parallel_search(process_count, Nt, Nw, puzzle, kangoo_power, starttime)
    for result in results:
        print(result)

There's nothing to admit it is my own stupidity also admitting I'm wrong. I now know it's pure stupidity of subtracting a bunch of public key and by the end it just doesn't work that way. How great are you than? It's still the same couldn't even solve 1 puzzle, aren't you? So why are you mocking others silly mistake while you achieve absolutely nothing. If you yourself also can't find anything, that means we're all the same here without any progressing. What makes think yourself qualify to mock at others then when you're the same group of people?

[digaran]

There's nothing to admit it is my own stupidity also admitting I'm wrong. I now know it's pure stupidity of subtracting a bunch of public key and by the end it just doesn't work that way. How great are you than? It's still the same couldn't even solve 1 puzzle, aren't you? So why are you mocking others silly mistake while you achieve absolutely nothing.

Who are you talking to, me or nomachine? I rarely use kangaroo, so I'm clueless as you were, but I guess you are doing it wrong, you said using keys from 64 bit while setting the range on 65 bit, you must at least have 1 key from 65 bit to find a collision in 65 bit range set.

I'm so clueless that a few times I changed -d and saw "expected RAM" at a few thousand TBs. Lol😉