Factorizing Puzzles

So, about the BTC Puzzle, there's this link where you can check it out. I'm thinking we could simplify things by using some kind of probabilistic method. When we start looking at the Keys that have already been found, it's clear that a lot of them aren't prime numbers at all. Instead of just brute-forcing through everything, why not find the maximum likelihood range? Sure, this might not apply to every puzzle out there, but if we take a broad view of them, there seems to be a strategy that could work for quite a few. Private keys as composite numbers have multiple factors, and we're more interested in all possible factors rather than just the prime ones. Once we find a factor of the private key, the difficulty of working with that key decreases a lot. But first, let's look into this idea using the Keys we've already found. There's some interesting stuff to notice. Some keys have almost no factors and aren't worth much, while others are packed with potential, having factors for nearly every bit. If we check every ten keys, there's usually at least one of those promising keys in the mix. Another thing to keep in mind is that we're on the lookout for factors that are neither too small nor overly large. Little factors don't really help much because the rest of the key still needs brute-forcing at a similar difficulty, and finding bigger factors can be a real pain. Ideally, we want factors that are somewhere around the mid-range of the key. So, let's focus on this search with the existing keys in mind. If we target factors closer to Q1, it gives us a much tighter range to explore. The same kind of narrowing can be done with Q2 or Q3. Now, if we apply this range of -10...

So if I understood correctly since at least 1 key in a group of ~10 keys probably has factors in almost every lower bit range, we can attempt to reduce the size of the problem by carefully choosing the bit range of the stride values in relation to the keys we are targeting. We can limit the amount of possible values we need to brute force through (stride range is not too big) while still enabling the program to traverse a key space in minimal time (stride value is not too small) thus maximizing the amount of candidates being checked per time unit while drastically reducing the size of the set. We are now searching for a stride value in a much smaller bit range, albeit slower (and there could be more than one value that opens the doors for us, or none). I like it. This is my current approach: It's currently taking me 120 seconds to check two ~36 bit stride values against puzzles 66-76 using two GPUs. Does anyone know of another CUDA based program other than BitCrack that has the stride option?

Hello, i tried puzzle factoring and took for testing purposes puzzle 64. Since the private key for #64 is known, i used some websites to get its factor and did a test for puzzle 64. I used the following strides, and surprisingly i don't know the reason why it didn't catch the private key even though i subtract 1 because of the starting private key, still didn't hit.  Possible_Strides_For_Puzzle_64: None of those strides worked, so i must have did a mistake? Would be nice having your opinions.

don't know if this would work but have you tried turning them into hex form by that i mean consider those strides as decimal and not hex

It's kinda hard to identify the prime numbers, as in computing only the non-prime numbers at runtime though, because there is still a huge amount of numbers in Z(2^256) that are not prime. So you could be multiplying by two, or by three, or by five, or seven, or a combination thereof, but you don't really have anything more efficient than that using this method. Plus if you are just searching these sequences in that order, or even some other order, then you are more likely to miss the actual key (in addition to the risk that the key is prime). Not to mention that multiplication by anything that isn't two is inefficient.

Yes, i converted them to Hexadecimal, subtracted 1 because of starting private key, actually no chances i'm not sure what i am doing wrong, i gotta test it more deeply when i get enough time

what do you mean by "all the possible factors"? this is what i found by factorizing the priv keys i don't understand how you found the "special" pattern you highlight on your graphics

For Example for Puzzle 65

Ok thanks. I generated 400 randoms privkeys in the range of puzzle 64-65. I obtain that with all factors of every key: the specific pattern you noticed occurs around 1/10 times (as you found before) so i don't think this a way to say that the priv key of the puzzle was not generated randomly and we can find a trick to speed up the search

It is not about how the privatekey is generated. We know that process already. The creator himself told that. It is about the way of searching most relevant range first thinking about the 84 remaining puzzles. As clearly mentioned in Note 1 and 2.

How this factors correlate with difference in quantity of 0 and  quantity of 1 in privkey in bin format? Difference is has, most probably key and not, for ex with  quantity of  zero -   quantity of ones = 6 more probably , or  =2 less probably , or  =0 les less probably, etc not need generate all privkeys.

By the Way, Puzzle 66 was juicy too.