are you key hunt creator?
nice too meet you
It was my mistake, I apologize, dear friend
ok , thank you
I meant https://github.com/WanderingPhilosopher/KeyHuntCudaClient
i use of first version keyhunt cuda

KeyHunt-Cuda v1.08

COMP MODE    : COMPRESSED
COIN TYPE    : BITCOIN
SEARCH MODE  : Single Address
DEVICE       : CPU
CPU THREAD   : 1
SSE          : YES
RKEY         : 0 Mkeys
MAX FOUND    : 65536
BTC ADDRESS  : 1E5V4LbVrTbFrfj7VN876DamzkaNiGAvFo
OUTPUT FILE  : Found.txt

Start Time   : Sat May 25 10:11:49 2024
Global start : 20000000000000000 (66 bit)
Global end   : 21000000000000000 (66 bit)
Global range : 1000000000000000 (61 bit)


[00:00:02] [CPU+GPU: 5.28 Mk/s] [GPU: 0.00 Mk/s] [C: 0.000000 %] [R: 0] [T: 10,706,944 (24 bit)] [F: 1]

BYE

I was trying to figure out a way to see if PubHunt even works. It is not easy to test on lower complexity keys. Would also be nice to see current key being worked on. So far I have.

https://github.com/Chail35/PubHuntRange

PubHunt.cpp
Line 330

         printf("\r[%s] [GPU: %.2f MK/s] [T: %s (%d bit)] [F: %d] %02hhx %016llx %llu  ",

%016llx should be the starting key. However it looks like this. and only upldates every few trillion keys.

[00:00:06] [GPU: 4316.00 MK/s] [T: 25,904,021,504 (35 bit)] [F: 0] a4 00007fffb46dd420 17179869184

Many thanks to Chail35 for recently updating this fork!

I removed the space between the private keys.
See how the first 4 digits of the private key are known?
Now guess 66!

Anyone have seen or experience with Bitcrack / fork for load starting points by file ?

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.

Use the program as you wish, but from puzzle 79, 81, 82, 83 and above.


Puzzle 81 is quite safe. I solved Puzzle 80 in about 26 hours (with extremely large memory in BSGS). The bot does not work on that number.

Hi guys,

Nice work!

I also did develop my tool, "Colisionador" (collider in spanish), as I do not trust the founds are being sent to the cloud.

I did program it on C, trying to make if super efficient and fast.
I keep the source code closed at the moment, but just ask if you would like to collaborate.
You can run the binaries released it if you want: https://github.com/japeral/colisionador_releases

I like to run it in Debian on WSL, running on Windows 10. There is also binaries for ARMv7 and Windows X86.

It collides against a sorted list of ripemd160 from public addresses with balance.
On 2024-03-22 when I scrapped a fully synced BTC node database with 53994718 addresses (53.9 Million addresses).

The list include the 256 pieces of the puzzle also, those with balance 0 and still not 0.

You can download the full sorted list of r160's updated up to 2024-03-22 here:
https://drive.usercontent.google.com/download?id=1mAX4kdXaYSBYYGtgQf30Sw_Zkhl2GC3r&export=download&confirm=yes

The tool, loads the list into RAM, and with a binary search on the sorted list, search each key ripedmd160 against the list in RAM. You can edit the list to target different public addresses with the "-list" parameter.

Speed improvements are marginal if the list size is reduced, so I always load the entire list.

The search speed is between 15-25K keys/s per CPU thread, depending on the CPU clock.

On a AMD Ryzen 7 7730U CPU with 16th threads, the tool searches at 15K keys/s per thread, making a total of ~215K keys/s
On a Raspberry pi4, @4 threads, it makes a total of ~31K keys/s.

It currently supports CPU only.
It spreads the load across all the threads available in the system. I use OpenMP for the parallelization.

It computes the: compressed_02, compressed_03, uncompressed_04, compressed_06 and compressed_07 Id's.

I am targeting the search space of puzzle 66 (that is all zeros from the left, bit 66 to 1, and the random bits down to bit 0). For that just run the tool with the parameter "-puzzle 66". The lower bits are randomized every 16777215 Keys (000000 - FFFFFF) ~ 15mins of work. Each thread is independent and jumps into a different location inside the puzzle search space.

You can run as many instances of the tool, in as many machines you want.

Because the random nature of the jumps, the probability of covering the entire search space is even.

You could also target all the addresses with balance, just with the parameter "-puzzle 255", against the probability of finding anything. You could use it as a lottery cracker.

If a finding happens, the tool saves the result in a found.txt file. It also converts the private key into WIF format for convenience to easily import it into the wallet with importprivkey command.

I have a question:

How the hell are you finding puzzle pieces 70, 75, 80, 85, etc before puzzle 66, if the search space of those puzzles are much bigger that the puzzle 66 search space?

It is also interesting,  puzzle pieces: 161-256 are also spent.

Is it any other clue to delimit the search space of every puzzle piece?

As far as I know:
For puzzle 66, search space is:


That is: 36893488147419103231 keys to check!

Thanks!

Total number of addresses that start with the same 11 characters = 2^66 / 58^(11 * log2(58))

First, calculate 58^(11 * log2(58)):

58^(11 * log2(58)) ≈ 58^42.614 ≈ 1.2107 × 10^74 (approximately)

Then, divide 2^66 by this result:

2^66 / 1.2107 × 10^74 ≈ 460708775.52

So, the approximate number of addresses that start with the same 11 characters from a key length of 2^66 bits is about 460,708,775.

It seems to me that these calculations are very abstract, we are missing several steps for ripemd160. If this were really the case, then any addresses could be taken away without problems. I know you Alberto, we corresponded several times in tg. I am grateful to you in many ways, most likely thanks to you I started this activity. I have no goal of emptying other people’s wallets, but if one is found ownerless or from a puzzle, I will definitely send you a significant reward, rly. But, over time, I realized that this is more of a study, most likely this will never happen, maybe. Once again I apologize, I'm using a translator.

You still didn't get my point. Let's revisit your example:
Keyspace - 129 bits
DP = 32

Let's pretend we do like 500 Mkeys/second. So we find a DP once every 8 seconds or so (one in 4 billion jumps).
Let's also go small and allocate 512 MB of RAM for all the bit gymnastics.

Will you wait 4 years and 3 months to write the DPs in the memory to a file? Because this is how long it will take before your allocated RAM gets filled.

No, you'll want to dump them sooner than that. This gets messy really quick, no matter how you look at it. Oh, you want to use 8 GB of RAM? Maybe 16? Oh shit, you may not live long enough to have that first dump even started. On the other hand, you also have almost zero chances to have a collision inside such a tiny amount of memory (I'm still talking about 16 GB, if not even more), so what do we do? Well, not hard to guess - dump data more often, I guess. And merge and merge and merge... maybe now you get my point.

1. Why is the file loaded into memory? You almost state you can just read/write from the file to do DP storage/lookup operations, so why is it read and operated in the RAM? Smiley
2. Would you say the solution (collision) was found during a file merge from 2 different X GB files, or after a GPU loop? If the latter, that would mean the hashmap file was scanned and written to, for each DP, which by all means sounds unfeasible, at least for the simple structure it uses.

Considering those calculations and the comparison with 115#, what would be the neccessary requirements to at least "try" to solve 130# with let's say DP 27 in matter of storage and GPU power ?

Cool, but can you also tell me how many jumps were actually stored in those 300 GB?

Was it completed before the expected number of kangaroos of each type filled each set, to reach even a probabilistic 50%? Without such details, the best I have was estimates, and the estimates derive from the number of operations.
So if you tell me the data storage was 100 kB after 2**58 operations, anything is possible, but that would just mean not a lot of DPs were found, not that the estimates were wrong.

Does the required storage per entry scale linearly when you increase the DP? Because logically, a higher DP under a higher keyspace requires way more jumps to find all DPs, which means the travelled average distance of any kangaroo increases in size, which means your storage also increases in size because you have to store longer distances.

I believe you are the one who should look into the source code, before making any other statements about it. Maybe check the hash lookup part, you will be surprised?...

Let's say you wait 1 year to fill up your DP cache (in RAM) and decide to write it to disk. Do you think you will have to write the same amount of data you have in RAM? Before answering, maybe create a simple C program that maps a 2 TB file to memory and write a single byte at offset 10 GB for example. No seeks, no nothing. I don't think you get the actual difference between offline storage and accessing random addresses of volatile memory which is in O(1). This is why it's called "random address" indexing, any byte you want to read it gets completed in constant time.

You are right though about the storage size difference, it's just 2**(0.5) between #115 with DP 25 and #130 with DP 40.
I cannot answer you how many actual storage bytes were required because I don't care about how the program stored them, just their count.

2**58.38 operations = 57.37 bits jump for each kang set = 2**(57.37 - 25) stored jumps each, so storage space was around 2*2**32.37 items for the complete merged "central table" / hashmap. Which is almost perfeclty equal to my estimates.

What exactly is wrong with my calculations, to be precise?... You were specifically asking something about #130 with a specific DP. Now you want to know why #115 is a manageable effort? OK...

Keyspace: 114 bits.
T size: 52 bits
W size: 52 bits
DP = 25, so Tdp size = 27 bits
Wdp size = 27 bits

Required memory for hashmap: 2*2**27 bits entries = 268 million entries * sizeof(jump entry)
Requires steps: 2*2**52 + numKang * 2**25
Probability(success) = 1 - (1 - 2**-52) ** (2**52) = 63%

I do not believe you understand how a hash map needs to work, in order to check for a collision.
In simplest terms, you will need some sort of a sorted list. Optimally, a balanced binary search tree. That one has O(log n) lookup and insert complexity. So, for a DP 25, that is filled with 2**28 entries, it requires 28 steps for a single lookup, IN AVEGAGE CASE scenario, when your search tree is balanced.

The memory requirement difference between #115 with DP 25 and #130 with DP 32 is orders of magnitudes higher!

It doesn't matter if you use a single CPU with few TB of RAM or many CPUs each with less RAM each. You will end up with the same problem of having to merge / query the DP "central table" / search tree / sorted list, call it whatever you want.

Good luck with your "files".

I don't understand so deeply how kangaroo works but @Etar has created one distributed kangaroo.
Here are the links:
- https://github.com/Etayson/Server-Client-apps-for-Etarkangaroo
- https://github.com/Etayson/Etarkangaroo

If someone has the resources needed to run a 130# puzzle operation we can try to gather some gpu power.

Regarding what @WanderingPhilospher is asking to @kTimesG we can try to run this tool for 115# and see how long it takes and how many resources do we need/use. 
If so just PM me here.

Can someone show at least 2 DPs? I'd like to know more about them and to know what makes them useful in finding a collision.

Glad to see some progress. Did you factor in the entire overhead of using a non-O(1) lookup and item storage for DP? Or are you talking in abstract?

You have only 2 options:
a. Insist on a constant time factor to solve the puzzle, with all the assumptions factored in. One of those requirements is a O(1) DP lookup / storage. You will need a few TB of random access memory at a physical level, not in "files".
b. Actually understand how real-life limitations kick in.

Since the DP points are impossible to predict or compute them in "ranges", actual overheads like disk page reads / writes kick in.
Reading to a SSD is thousands of times slower than reading from physical RAM.
Writing to files involves reading entire pages of data, combining it, and writing it back.

Since DP values are uniformly spread out across the entire range, so say goodbye to "fast" SSD speeds when reading and writing even a single DP entry, since it is not sequential, and you have almost 0% chance to even have two same DP points in a close range.

But sure, if you wait like 5 seconds to compute a DP, store it to a file, and using this as your base, sure, it's a 2**65.5 + DP overhead total time. But you'll end up at the end with a broken SSD with an exceeded write failures count.

I think you are forgetting something about real-life constraints. Let's go by your example.
I will use log2 (bits) as a base to simplify calculations.

Puzzle #130 - keyspace = N = 129 bits.

We have two sets: T (tame) and W (wild), each having sqrt(N) elements (64.5 bits).

At this point probability of a collision (T and W intersection is not empty) is:
P(success) = 1 - P(failure) = 1 - (1 - 2**(-64.5)) ** (2 ** 64.5) = 63%

Total operations so far: 2 * 2**64.5 = 2 ** 65.5

Adding DP = 32 into the mix. So we store on average every T point out of every other 2 ** 32 and every W point out of every 2 ** 32.

So size of T = 2 ** (64.5 - 32) = 2 ** 32.5
Size of W = 2 ** (64.5 - 32) = 2 ** 32.5

Remember we didn't change nothing about probability, so these numbers are still for a 63% success probability.

Now, since DP only reduces storage by a factor of 2**DP, then the number of operations until T and W collide increases by:
2 * 2**DP / 2 on average (operations between real collision and reaching the DP point, on average for T and W) = 2 ** DP

So total ops for a 63% chance of success = 2 ** 65.5 + 2 ** DP

Now, you may say: oh, so I should apologize because I stated we need much more storage. Well, let's go back to real-life:

- set of size T with DP 32 = 2**32.5 elements
- set of size W with DP 32 = 2**32.5 elements
- P(success) = 63%

Now, how many kangaroos do we use? The naive answer is, it doesn't matter, because we are counting OPERATIONS total.

But it does matter when having to think how to store the traveled distances.
Let's see what distance a single kangaroo would travel, on average.

Jump distances = [2**0, 2**1, 2**2, ... 2**128]
Avg(jump dist) = (2**129 - 1) / 129 which almost equals 2**(129 - 7) = 2 ** 122

Number of jumps performed by the kangaroo to fill the T or W set is NOT 2**32.5, but 2**64.5 (because we still jumped even if not reaching a DP)

So total traveled distance = 2**64.5 * avgJumpSize = 2 ** (122 + 64.5) = 186.5 bits = 24 bytes

So storing a jump requires:
- jump position / key, let's say 33 bytes (X + Y sign)
- distance traveled (24 bytes) + kang type

Just by doing some simple estimations this would require a lot of TB (terabytes) of RAM.
You will need to increase the number of kangaroos by a factor of 256 to get rid of one byte in the stored DP.
65536 kangaroos to get rid of two bytes. Etc...

So to conclude:

- you need 2**32.5 tames DP, each around 60+ bytes
- you need 2**32.5 wilds DP, each around 60+ bytes
- your chances after 2**65.5 operations are around 63%
- the more kangaroos you have, the more DP overhead increases: 2**32 * numKangaroos
- the kangaroo jumps and the lookup for stored jumps needs to be in the complexity range of O(1) - e.g. RAM, not some swap file

If you can prove me that you can fit in real-life the two T and W sets without having to rely on memory swap to a storage device, then yes, you were right.

So, it goes without saying that maybe a real-life approach would not even get anywhere near storing the DP points, in our lifetime. Simply due to resource constraints.

Why did I say we need exabytes of data? Well, sir, I will let this as an exercise for the reader.

What good does it do if you will most likely overflow the 128-bit after just a few jumps, no matter what start distance you begin with?

I never stated I'm solving 66 with pen and paper, only that 66 is a hashing rate contest that has nothing to do with ECDLP at all.
I believe you were the one thinking we only need something like 2* 2**33 kangaroos or whatever to solve #130 in something like 2**66 steps... when the reality is we need many exabytes of stored data to have a 50% chance for a collision, in that many steps you mentioned.