Bitcoin puzzle transaction ~32 BTC prize to who solves it

[james5000]

james5000 Your reduction method makes sense and I agree the private key will conform to the similar ratio of 1 and 0 in binary but what I don't understand is how your app searches, is your app reducing the ranges then search every address in that? or does it only search keys that conform to the binary ratio? For example can you put a start and end range and then it skips keys that don't conform? When are you planning to release your app even just the CPU version?

I'm dedicating today to organizing everything into a cleaner project and making it available on GitHub so that they can use and/or contribute.

[7isce]

The method is good as idea but you will lose significant amount of speed because you need to do scalar multiplication for each key, the secp256k1 sequential tricks will not work here.

So the new question will be arises, Is it worth to lose that much of speed to avoid that amount of keys?

[james5000]

The method is good as idea but you will lose significant amount of speed because you need to do scalar multiplication for each key, the secp256k1 sequential tricks will not work here.

So the new question will be arises, Is it worth to lose that much of speed to avoid that amount of keys?

I also faced this issue, so I played the data analyst role and analyzed the data haha (sorry for the joke).

The answer is no, we don't need to perform scalar multiplication for all the keys. This part is a bit more complex and was the most challenging, but everyone will understand.

I apologize a million times. I didn't mention that the goal is not to find the private key directly, but to find the public key through point addition and subtraction on the curve, as we know that working this way is faster.

[james5000]

Understanding the concept of the idea, let's move on to the code. This algorithm magically skips all combinations that don't meet the rules without needing to be verified or even "seen".

As an example, let's use puzzle 30 because it's smaller.
Only keys with 16 bits set to 1 and 14 bits set to 0 will be processed.

Code:

def getArray(ones, zeros):
    # the first bit is always 1.
    string = '1'
    array = list(string)

    while len(array) < (zeros + ones):
        if array.count("0") < zeros:
            array.append("0")
        elif array.count("1") < ones:
            array.append("1")

    return array

key_size = 30
ones = 16

# init a key in array of bits with 16 ones and 14 zeros
startKey = getArray(ones, key_size - ones)

while True:
    print("".join(startKey))

    i = key_size - 2
    while i >= 0 and startKey[i] >= startKey[i + 1]:
        i -= 1

    if i < 0:
        break

    j = key_size - 1
    while j > i and startKey[j] <= startKey[i]:
        j -= 1

    temp = startKey[i]
    startKey[i] = startKey[j]
    startKey[j] = temp

    left = i + 1
    right = key_size - 1
    while left < right:
        temp = startKey[left]
        startKey[left] = startKey[right]
        startKey[right] = temp
        left += 1
        right -= 1

The keys will be:

Code:

100000000000000111111111111111 0x20007fff
100000000000001011111111111111 0x2000bfff
100000000000001101111111111111 0x2000dfff
100000000000001110111111111111 0x2000efff
100000000000001111011111111111 0x2000f7ff
100000000000001111101111111111 0x2000fbff
100000000000001111110111111111 0x2000fdff
100000000000001111111011111111 0x2000feff
100000000000001111111101111111 0x2000ff7f
100000000000001111111110111111 0x2000ffbf
100000000000001111111111011111 0x2000ffdf
100000000000001111111111101111 0x2000ffef
100000000000001111111111110111 0x2000fff7
100000000000001111111111111011 0x2000fffb
100000000000001111111111111101 0x2000fffd
100000000000001111111111111110 0x2000fffe
100000000000010011111111111111 0x20013fff
100000000000010101111111111111 0x20015fff
100000000000010110111111111111 0x20016fff
100000000000010111011111111111 0x200177ff
100000000000010111101111111111 0x20017bff
100000000000010111110111111111 0x20017dff
100000000000010111111011111111 0x20017eff
100000000000010111111101111111 0x20017f7f
100000000000010111111110111111 0x20017fbf
100000000000010111111111011111 0x20017fdf
100000000000010111111111101111 0x20017fef
100000000000010111111111110111 0x20017ff7
100000000000010111111111111011 0x20017ffb
100000000000010111111111111101 0x20017ffd
100000000000010111111111111110 0x20017ffe
100000000000011001111111111111 0x20019fff
100000000000011010111111111111 0x2001afff
100000000000011011011111111111 0x2001b7ff
100000000000011011101111111111 0x2001bbff
100000000000011011110111111111 0x2001bdff
100000000000011011111011111111 0x2001beff
100000000000011011111101111111 0x2001bf7f
100000000000011011111110111111 0x2001bfbf
100000000000011011111111011111 0x2001bfdf
100000000000011011111111101111 0x2001bfef
100000000000011011111111110111 0x2001bff7
100000000000011011111111111011 0x2001bffb
100000000000011011111111111101 0x2001bffd
100000000000011011111111111110 0x2001bffe
100000000000011100111111111111 0x2001cfff
100000000000011101011111111111 0x2001d7ff
100000000000011101101111111111 0x2001dbff
100000000000011101110111111111 0x2001ddff
100000000000011101111011111111 0x2001deff
100000000000011101111101111111 0x2001df7f
100000000000011101111110111111 0x2001dfbf
100000000000011101111111011111 0x2001dfdf
100000000000011101111111101111 0x2001dfef
100000000000011101111111110111 0x2001dff7
100000000000011101111111111011 0x2001dffb
100000000000011101111111111101 0x2001dffd
100000000000011101111111111110 0x2001dffe
100000000000011110011111111111 0x2001e7ff
100000000000011110101111111111 0x2001ebff
100000000000011110110111111111 0x2001edff
100000000000011110111011111111 0x2001eeff
100000000000011110111101111111 0x2001ef7f
100000000000011110111110111111 0x2001efbf
100000000000011110111111011111 0x2001efdf
100000000000011110111111101111 0x2001efef
100000000000011110111111110111 0x2001eff7
100000000000011110111111111011 0x2001effb
100000000000011110111111111101 0x2001effd
100000000000011110111111111110 0x2001effe
100000000000011111001111111111 0x2001f3ff
100000000000011111010111111111 0x2001f5ff
100000000000011111011011111111 0x2001f6ff
100000000000011111011101111111 0x2001f77f
100000000000011111011110111111 0x2001f7bf
100000000000011111011111011111 0x2001f7df
100000000000011111011111101111 0x2001f7ef
100000000000011111011111110111 0x2001f7f7
100000000000011111011111111011 0x2001f7fb
100000000000011111011111111101 0x2001f7fd
100000000000011111011111111110 0x2001f7fe
100000000000011111100111111111 0x2001f9ff
100000000000011111101011111111 0x2001faff
100000000000011111101101111111 0x2001fb7f
100000000000011111101110111111 0x2001fbbf
100000000000011111101111011111 0x2001fbdf
100000000000011111101111101111 0x2001fbef
100000000000011111101111110111 0x2001fbf7
100000000000011111101111111011 0x2001fbfb
100000000000011111101111111101 0x2001fbfd
100000000000011111101111111110 0x2001fbfe
100000000000011111110011111111 0x2001fcff
100000000000011111110101111111 0x2001fd7f
100000000000011111110110111111 0x2001fdbf
100000000000011111110111011111 0x2001fddf
100000000000011111110111101111 0x2001fdef
100000000000011111110111110111 0x2001fdf7
100000000000011111110111111011 0x2001fdfb
100000000000011111110111111101 0x2001fdfd
100000000000011111110111111110 0x2001fdfe
.....
.....
.....

This way, we can visualize the jumps from one key to another.

As mentioned by the friend above, using this approach would require performing scalar multiplication for each key. However, let's continue because (believe me) it's going to get interesting!

[zahid888]

The problem isn't guessing a random number, it's narrowing down the search range to more probable keys. Thank you for posting the percentages; this way we can see that after 54, none have fewer than 40% of bits as 1 or 0, nor more than 60%. I believe we can accept this as a fact.

This means that perhaps you have gained some benefit from my post, which is why the saying "knowledge increases by sharing" is mentioned. Well, if you hold this viewpoint and it might indeed be true, in a 66-bit key, if we allocate zeros between 40 to 60 % and ones also between 40 to 60 % , we can significantly reduce the boundary of the search space. Yes, this statement holds a considerable amount of credibility 👍 👍

[zahid888]

Enter the number of bits you want to search: 66
Enter the percentage of zeros you want: 43.5
Enter the percentage of ones you want: 56.5

Binary Key: 100000000000000000000000000000111111111111111111111111111111111111 Hex Key: 20000000fffffffff
Binary Key: 100000000000000000000000000001011111111111111111111111111111111111 Hex Key: 200000017ffffffff
Binary Key: 100000000000000000000000000001101111111111111111111111111111111111 Hex Key: 20000001bffffffff
Binary Key: 100000000000000000000000000001110111111111111111111111111111111111 Hex Key: 20000001dffffffff
Binary Key: 100000000000000000000000000001111011111111111111111111111111111111 Hex Key: 20000001effffffff
Binary Key: 100000000000000000000000000001111101111111111111111111111111111111 Hex Key: 20000001f7fffffff
Binary Key: 100000000000000000000000000001111110111111111111111111111111111111 Hex Key: 20000001fbfffffff
Binary Key: 100000000000000000000000000001111111011111111111111111111111111111 Hex Key: 20000001fdfffffff

Jump is working, but we need a significant amount of computational power for it. For instance, as I input a combination of 43.5% and 56.5%, we will have to try numerous such combinations. In addition to these combinations, we will also need to try the inverse combinations of all those. Completing just one combination can take up a substantial amount of time. In short, this is also a highly time-consuming process. but still considerable..

[james5000]

Yes, as I mentioned, it's going to get interesting.  

Knowing that each point on the secp256k1 curve has its value, let's speed up a bit and jump to the 'magic formula' of powers. For example:

The generator point is the private key 2^0, which is 1.
The next point is 2^1, which is 2.
2^2 = 4
2^3 = 8
...
...

And so on, right?

If you have a private key A and add a private key B, you get a private key C. Similarly, if you have a point A and add a point B, you get a point C.

If we analyze the difference between one key and another, we obtain the beautiful pattern below:

Code:

16384
8192
4096
2048
1024
512
256
128
64
32
16
8
4
2
1
16385
8192
4096
2048
1024
512
256
128
64
32
16
8
4
2
1
8193
4096
2048
1024
512
256
128
64
32
16
8
4
2
1
4097
2048
1024
512
256
128
64
32
16
8
4
2
1
2049
1024
512
256
128
64
32
16
8
4
2
1
1025
512
256
128
64
32
16
8
4
2
1
513
256
128
64
32
16
8
4
2
1
257
128
64
32
16
8
4
2
1

If we observe (I believe you've already noticed ), we can see that they are powers of 2 with a slight variation in each new group (which happens when the leftmost bit advances by one digit).

Now, what happens if you generate the public key from the initial key and add the point 2^14? You will have exactly the point equivalent to the next key's point, without needing scalar multiplication. So, we can follow the decreasing pattern:
Add 2^13 to the current point
Add 2^12 to the current point
Add 2^11 to the current point
Add 2^10 to the current point
...
...

After adding the point 2^0 to the resulting point, we will reach the end of a group. The next group will start with:
Add 2^14 to the current point and add point 1 = (2^14 + 1) = 16385.

[james5000]

As promised, here is the basic outline of the project.
https://github.com/Jamerson1000/million-python.git

I am currently working with C++ for CUDA, and I will soon post it on GitHub.

[james5000]

When finishing a larger group of these groups (the group size will be the quantity of bits set to 0), the incremented value rises by a power of 2 - 1 (2^14 + 3) - (2^13 + 3) - (2^12 + 3).... (2^14 + 7) - (2^13 + 7) .... (2^14 + 15) - (2^13 + 15).

Or to simplify, when the numbers become too large, we can add the point equivalent to the power of 2 to the increment value (3 + 1 = 4 or 2^2), then subtract one point (2^2 - 1 = 3) - (2^3 - 1 = 7) - (2^4 - 1 = 15)...

In this example, it might not seem necessary, but when the increment value is 2047, we don't need to add the point 2047; instead, we add the point 2^11 and subtract one point.

This way, we only need an array of points the size of the key for use in operations.

So, at most, for each key, we will perform a maximum of 3 operations: two additions and one subtraction.

[sssergy2705]

As promised, here is the basic outline of the project.
https://github.com/Jamerson1000/million-python.git

I am currently working with C++ for CUDA, and I will soon post it on GitHub.

I tried to substitute data from lower bit ranges.
20 bits in less than a minute.
I can't find 30 bits for half an hour already.
I understand that you need to know the exact number of digits 1?

[james5000]

As promised, here is the basic outline of the project.
https://github.com/Jamerson1000/million-python.git

I am currently working with C++ for CUDA, and I will soon post it on GitHub.

I tried to substitute data from lower bit ranges.
20 bits in less than a minute.
I can't find 30 bits for half an hour already.
I understand that you need to know the exact number of digits 1?

I apologize for the mistake. In the getArray function in utils.py, it's already fixed. Please ensure that the hash160 target has been set.

This code indeed needs improvement to be faster. This is just for proof of concept.

My C++ CUDA version on a GTX 1650 4GB runs at 250,000 per second, solving puzzle 30 in 2.5 to 3 minutes.
But since I'm quite new to GPU programming, I haven't been able to harness the full power of the graphics card yet.

[james5000]

I humbly request partnership with albertobsd to use multi-threading in this method in C++. If the creator of bitcrack could assist with the CUDA version I'm developing, we could potentially achieve speeds of 200-300Mk/s.

[vsv68]

The second day I watch what james5000 writes and it's very funny to me)
 It's especially funny to see how other people support him)
 I don’t want to offend anyone, but I get the impression that you didn’t study mathematics at school, your teacher should be very ashamed.
 The method suggested by james5000 would require you to try more than 2^65 combinations to solve a 66 bit key.
 It is impossible to go through such a number of combinations in a month, or even in a year!
 Please learn to count before you write like this, you look very stupid.
 I didn't mean to offend anyone, I'm sorry if I hurt your feelings, I just had to tell you that you are doing nonsense, I wish you all success!

[james5000]

The second day I watch what james5000 writes and it's very funny to me)
 It's especially funny to see how other people support him)
 I don’t want to offend anyone, but I get the impression that you didn’t study mathematics at school, your teacher should be very ashamed.
 The method suggested by james5000 would require you to try more than 2^65 combinations to solve a 66 bit key.
 It is impossible to go through such a number of combinations in a month, or even in a year!
 Please learn to count before you write like this, you look very stupid.
 I didn't mean to offend anyone, I'm sorry if I hurt your feelings, I just had to tell you that you are doing nonsense, I wish you all success!

lmfao 

As there are more than 2^65 possibilities for 66 bits, even though I'm skipping intervals.

For example:
Between the initial key and the second key, 2^33 keys are skipped, then 2^32, 2^31, and so on...
I believe you don't even need to calculate it to see that it's less than 2^65.

[frozenen]

Is your script supposed to show the speed while running for #30? how long should it take to find?

[james5000]

Is your script supposed to show the speed while running for #30? how long should it take to find?

this python code is very slow, only to show how works the ideia.

but the cuda code run all interval bits 1 = 16 for #30 in 2 minutes.

I understand that one might think that for #31 (since it's one more bit), it would take twice the time, i.e., 4 minutes. However, in reality, it would take just over 2 minutes because it's not exponential. I'll run some tests, and since everyone has access to the code, they can confirm.

[albert0bsd]

even though I'm skipping intervals.

We know that you are skipping those ranges that are some kind of unlikely to appper in random numbers... that is clear.

Let me show you this simulation for 64 bits, with 100 Million of iterations..

Code:

3 times 10 bits in 1,  this is 0.000000
3 times 11 bits in 1,  this is 0.000000
15 times 12 bits in 1,  this is 0.000000
69 times 13 bits in 1,  this is 0.000001
241 times 14 bits in 1,  this is 0.000002
841 times 15 bits in 1,  this is 0.000008
2677 times 16 bits in 1,  this is 0.000027
7459 times 17 bits in 1,  this is 0.000075
19405 times 18 bits in 1,  this is 0.000194
47167 times 19 bits in 1,  this is 0.000472
106263 times 20 bits in 1,  this is 0.001063
222505 times 21 bits in 1,  this is 0.002225
436048 times 22 bits in 1,  this is 0.004360
795798 times 23 bits in 1,  this is 0.007958
1357354 times 24 bits in 1,  this is 0.013574
2178202 times 25 bits in 1,  this is 0.021782
3259829 times 26 bits in 1,  this is 0.032598
4588566 times 27 bits in 1,  this is 0.045886
6064588 times 28 bits in 1,  this is 0.060646
7533079 times 29 bits in 1,  this is 0.075331
8784231 times 30 bits in 1,  this is 0.087842
9628995 times 31 bits in 1,  this is 0.096290
9933958 times 32 bits in 1,  this is 0.099340
9637041 times 33 bits in 1,  this is 0.096370
8782369 times 34 bits in 1,  this is 0.087824
7530503 times 35 bits in 1,  this is 0.075305
6064379 times 36 bits in 1,  this is 0.060644
4589388 times 37 bits in 1,  this is 0.045894
3260455 times 38 bits in 1,  this is 0.032605
2175369 times 39 bits in 1,  this is 0.021754
1356442 times 40 bits in 1,  this is 0.013564
794205 times 41 bits in 1,  this is 0.007942
435134 times 42 bits in 1,  this is 0.004351
222946 times 43 bits in 1,  this is 0.002229
106671 times 44 bits in 1,  this is 0.001067
46833 times 45 bits in 1,  this is 0.000468
19545 times 46 bits in 1,  this is 0.000195
7516 times 47 bits in 1,  this is 0.000075
2705 times 48 bits in 1,  this is 0.000027
842 times 49 bits in 1,  this is 0.000008
251 times 50 bits in 1,  this is 0.000003
80 times 51 bits in 1,  this is 0.000001
23 times 52 bits in 1,  this is 0.000000
5 times 53 bits in 1,  this is 0.000000
1 times 54 bits in 1,  this is 0.000000
1 times 55 bits in 1,  this is 0.000000

What that mean? for example if you want a ratio of the 50% of the bits are in 1

Code:

9933958 times 32 bits in 1,  this is 0.099340

That is is near of ~10% of the TIME the random numbers had 32 of 64 bits in 1

Now you want to test numbers only with some ratio between 40% to 60% right?

Code:

>>> 64*0.40
25.6
>>> 64*0.60
38.4

For this example of 64 bits you need to test those numbers who have 26 to 38 bits in 1 that is from 32 +/- 6

In this example  the values have the next probabilities:

Code:

3259829 times 26 bits in 1,  this is 0.032598
4588566 times 27 bits in 1,  this is 0.045886
6064588 times 28 bits in 1,  this is 0.060646
7533079 times 29 bits in 1,  this is 0.075331
8784231 times 30 bits in 1,  this is 0.087842
9628995 times 31 bits in 1,  this is 0.096290
9933958 times 32 bits in 1,  this is 0.099340
9637041 times 33 bits in 1,  this is 0.096370
8782369 times 34 bits in 1,  this is 0.087824
7530503 times 35 bits in 1,  this is 0.075305
6064379 times 36 bits in 1,  this is 0.060644
4589388 times 37 bits in 1,  this is 0.045894
3260455 times 38 bits in 1,  this is 0.032605

That is 0.896575 or near of ~90% of all the KEYS in the whole range FIT in those % of Ratios of 1.

That is the % for a 64 bits range, but i bet that the % is very similar for a 66 bit range and others..

I guarantee that with a rate of 300 Mk/s we break the 66, 67 and 68 in one week

From you previous quote I going to asume a puzzle per week, not 3 in a week.

Code:

>>>2**65/300000000/60/60/24/52 * 0.0000365333
1.0000006458749602

That is one week and you need 0.0000365333 of the range that is 0.00365333%

Let me ask it again, because the last time you completely ignore my question.

How do you plan to reduce that 90% of the whole range to only 0.00365333%?

For many ranges that you skip, i don't believe any reduction near to the 1% of the whole range...

BTW if some one spot some miscalculation or some incoherent formula please let me know i would be happy of getting wrong.

Repeat, your Idea have a lot of logic, but the calcualtios about your expected time doesn't match...

[james5000]

even though I'm skipping intervals.

We know that you are skipping those ranges that are some kind of unlikely to appper in random numbers... that is clear.

Let me show you this simulation for 64 bits, with 100 Million of iterations..

Code:

3 times 10 bits in 1,  this is 0.000000
3 times 11 bits in 1,  this is 0.000000
15 times 12 bits in 1,  this is 0.000000
69 times 13 bits in 1,  this is 0.000001
241 times 14 bits in 1,  this is 0.000002
841 times 15 bits in 1,  this is 0.000008
2677 times 16 bits in 1,  this is 0.000027
7459 times 17 bits in 1,  this is 0.000075
19405 times 18 bits in 1,  this is 0.000194
47167 times 19 bits in 1,  this is 0.000472
106263 times 20 bits in 1,  this is 0.001063
222505 times 21 bits in 1,  this is 0.002225
436048 times 22 bits in 1,  this is 0.004360
795798 times 23 bits in 1,  this is 0.007958
1357354 times 24 bits in 1,  this is 0.013574
2178202 times 25 bits in 1,  this is 0.021782
3259829 times 26 bits in 1,  this is 0.032598
4588566 times 27 bits in 1,  this is 0.045886
6064588 times 28 bits in 1,  this is 0.060646
7533079 times 29 bits in 1,  this is 0.075331
8784231 times 30 bits in 1,  this is 0.087842
9628995 times 31 bits in 1,  this is 0.096290
9933958 times 32 bits in 1,  this is 0.099340
9637041 times 33 bits in 1,  this is 0.096370
8782369 times 34 bits in 1,  this is 0.087824
7530503 times 35 bits in 1,  this is 0.075305
6064379 times 36 bits in 1,  this is 0.060644
4589388 times 37 bits in 1,  this is 0.045894
3260455 times 38 bits in 1,  this is 0.032605
2175369 times 39 bits in 1,  this is 0.021754
1356442 times 40 bits in 1,  this is 0.013564
794205 times 41 bits in 1,  this is 0.007942
435134 times 42 bits in 1,  this is 0.004351
222946 times 43 bits in 1,  this is 0.002229
106671 times 44 bits in 1,  this is 0.001067
46833 times 45 bits in 1,  this is 0.000468
19545 times 46 bits in 1,  this is 0.000195
7516 times 47 bits in 1,  this is 0.000075
2705 times 48 bits in 1,  this is 0.000027
842 times 49 bits in 1,  this is 0.000008
251 times 50 bits in 1,  this is 0.000003
80 times 51 bits in 1,  this is 0.000001
23 times 52 bits in 1,  this is 0.000000
5 times 53 bits in 1,  this is 0.000000
1 times 54 bits in 1,  this is 0.000000
1 times 55 bits in 1,  this is 0.000000

What that mean? for example if you want a ratio of the 50% of the bits are in 1

Code:

9933958 times 32 bits in 1,  this is 0.099340

That is is near of ~10% of the TIME the random numbers had 32 of 64 bits in 1

Now you want to test numbers only with some ratio between 40% to 60% right?

Code:

>>> 64*0.40
25.6
>>> 64*0.60
38.4

For this example of 64 bits you need to test those numbers who have 26 to 38 bits in 1 that is from 32 +/- 6

In this example  the values have the next probabilities:

Code:

3259829 times 26 bits in 1,  this is 0.032598
4588566 times 27 bits in 1,  this is 0.045886
6064588 times 28 bits in 1,  this is 0.060646
7533079 times 29 bits in 1,  this is 0.075331
8784231 times 30 bits in 1,  this is 0.087842
9628995 times 31 bits in 1,  this is 0.096290
9933958 times 32 bits in 1,  this is 0.099340
9637041 times 33 bits in 1,  this is 0.096370
8782369 times 34 bits in 1,  this is 0.087824
7530503 times 35 bits in 1,  this is 0.075305
6064379 times 36 bits in 1,  this is 0.060644
4589388 times 37 bits in 1,  this is 0.045894
3260455 times 38 bits in 1,  this is 0.032605

That is 0.896575 or near of ~90% of all the KEYS in the whole range FIT in those % of Ratios of 1.

That is the % for a 64 bits range, but i bet that the % is very similar for a 66 bit range and others..

I guarantee that with a rate of 300 Mk/s we break the 66, 67 and 68 in one week

From you previous quote I going to asume a puzzle per week, not 3 in a week.

Code:

>>>2**65/300000000/60/60/24/52 * 0.0000365333
1.0000006458749602

That is one week and you need 0.0000365333 of the range that is 0.00365333%

Let me ask it again, because the last time you completely ignore my question.

How do you plan to reduce that 90% of the whole range to only 0.00365333%?

For many ranges that you skip, i don't believe any reduction near to the 1% of the whole range...

BTW if some one spot some miscalculation or some incoherent formula please let me know i would be happy of getting wrong.

Repeat, your Idea have a lot of logic, but the calcualtios about your expected time doesn't match...

First of all, thank you very much for the time you've dedicated and the painstaking calculations!

I will conduct some tests. None of the formulas I used to calculate the total intervals provided me with the correct result. I resorted to brute forcing puzzle #30 just to confirm.

Initially, I attempted using the binomial coefficient. It worked well for #10, but for #30, it didn't yield the correct result, which is around 77 million reduced from about 500 million.

If you are aware of a formula to calculate the number of combinations for a fixed-length string with 14 bits set to 0 and 16 bits set to 1, I would be grateful if you could correct my calculations.

Code:

The binomial coefficient, also known as "n choose k" or "combination," is used to calculate the number of different ways to choose k unique elements from a set of n elements, without considering the order in which they are chosen. The formula for the binomial coefficient is given by:

C(n, k) = n! / (k! * (n - k)!)

Where:

n is the size of the total set (in this case, the length of the string)
k is the number of elements you want to choose (in this case, the number of zeros or ones)
To calculate the binomial coefficient for a fixed-length string with 14 zeros and 16 ones, we have n = 30 (14 zeros + 16 ones) and k = 14 (number of zeros). Substituting these values into the formula, we get:

C(30, 14) = 30! / (14! * (30 - 14)!)

Here, 30! represents the factorial of 30 (30 * 29 * 28 * ... * 1), 14! represents the factorial of 14, and (30 - 14)! represents the factorial of 16.

Calculating these factorials and substituting them into the formula, we get the value of the binomial coefficient:

C(30, 14) = 30! / (14! * 16!) ≈ 145,422,675

Therefore, there are approximately 145,422,675 different ways to combine a fixed-length string with 14 zeros and 16 ones.

[modma]

The problem isn't guessing a random number, it's narrowing down the search range to more probable keys. Thank you for posting the percentages; this way we can see that after 54, none have fewer than 40% of bits as 1 or 0, nor more than 60%. I believe we can accept this as a fact.

with all due respect. You tried to do at least something, but you have a basic gap in the logic.
You can see - but you cannot say that this rule will work for the next puzzle..
Try to understand it.
Literally - what happened before - does not affect what happens after. What happens after has nothing to do with what happened before.
Take it as an axiom.
Narrowing the range is so non-critical - that it will not put any pressure on the puzzle

[vsv68]

james5000 you have errors in your calculations.
Use this code:

Code:

import math

KEY_SIZE = 5
ONES = 2

n = KEY_SIZE - 1
r = ONES - 1

combinations = math.factorial(n) // (math.factorial(r) * math.factorial(n-r))

print("KEY_SIZE =", KEY_SIZE)
print("ONES =", ONES)
print("Combinations:", combinations)

A simple example for KEY_SIZE = 5

ONES = 2
number of combinations 4:
10001
10010
10100
11000

ONES = 3
number of combinations 6:
10011
10101
11001
10110
11010
11100

ONES = 4
number of combinations 4:
10111
11011
11101
11110

total combinations 14

Let's say we are looking for the key 10111. You do not know how many units the key contains and to find this key by your method, you will first have to sort through all the ONES = 2, then all the ONES = 3, and only at step 11 will the desired key be found. If you search for the same key by a simple sequential search, it will be found at step 7, that is, faster than your method. Your method proved to be worse than a simple sequential search, in a 66-bit key your method will work for eternity....