<<  >> (p.153)
    Author Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it  (Read 324767 times)

    • james5000
    Jr. Member
    *
    Offline Offline

    Activity: 69
    Merit: 2


    View Profile
    August 07, 2023, 02:54:53 PM
     #3041
    Quote from: frozenen on August 07, 2023, 02:37:04 PM
    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
    Jr. Member
    *
    Offline Offline

    Activity: 61
    Merit: 6


    View Profile
    August 07, 2023, 03:09:49 PM
     #3042
    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
    Jr. Member
    *
    Offline Offline

    Activity: 69
    Merit: 2


    View Profile
    August 07, 2023, 03:13:40 PM
     #3043
    Quote from: 7isce on August 07, 2023, 03:09:49 PM
    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
    Jr. Member
    *
    Offline Offline

    Activity: 69
    Merit: 2


    View Profile
    August 07, 2023, 03:45:54 PM
     #3044
    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
    Member
    **
    Offline Offline

    Activity: 329
    Merit: 24

    the right steps towerds the goal


    View Profile
    August 07, 2023, 03:53:19 PM
     #3045
    Quote from: james5000 on August 07, 2023, 01:56:55 PM
    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 👍 👍
    1BGvwggxfCaHGykKrVXX7fk8GYaLQpeixA

  • zahid888
    Member
    **
    Offline Offline

    Activity: 329
    Merit: 24

    the right steps towerds the goal


    View Profile
    August 07, 2023, 04:29:58 PM
     #3046
    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..
    1BGvwggxfCaHGykKrVXX7fk8GYaLQpeixA

  • james5000
    Jr. Member
    *
    Offline Offline

    Activity: 69
    Merit: 2


    View Profile
    August 07, 2023, 04:59:22 PM
     #3047
    Yes, as I mentioned, it's going to get interesting.  Wink

    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 Cheesy), 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
    Jr. Member
    *
    Offline Offline

    Activity: 69
    Merit: 2


    View Profile
    August 07, 2023, 05:17:15 PM
    Merited by citb0in (1)
     #3048
    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
    Jr. Member
    *
    Offline Offline

    Activity: 69
    Merit: 2


    View Profile
    August 07, 2023, 05:56:00 PM
     #3049
    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
    Copper Member
    Jr. Member
    *
    Offline Offline

    Activity: 205
    Merit: 1


    View Profile
    August 07, 2023, 06:37:51 PM
     #3050
    Quote from: james5000 on August 07, 2023, 05:17:15 PM
    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
    Jr. Member
    *
    Offline Offline

    Activity: 69
    Merit: 2


    View Profile
    August 07, 2023, 07:04:20 PM
    Last edit: August 07, 2023, 07:30:23 PM by james5000
     #3051
    Quote from: sssergy2705 on August 07, 2023, 06:37:51 PM
    Quote from: james5000 on August 07, 2023, 05:17:15 PM
    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
    Jr. Member
    *
    Offline Offline

    Activity: 69
    Merit: 2


    View Profile
    August 07, 2023, 07:22:03 PM
     #3052
    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
    Newbie
    *
    Offline Offline

    Activity: 8
    Merit: 0


    View Profile
    August 07, 2023, 08:24:42 PM
     #3053
    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
    Jr. Member
    *
    Offline Offline

    Activity: 69
    Merit: 2


    View Profile
    August 07, 2023, 08:30:20 PM
     #3054
    Quote from: vsv68 on August 07, 2023, 08:24:42 PM
    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  Grin

    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
    Newbie
    *
    Offline Offline

    Activity: 43
    Merit: 0


    View Profile
    August 07, 2023, 08:32:51 PM
     #3055
    Is your script supposed to show the speed while running for #30? how long should it take to find?

  • james5000
    Jr. Member
    *
    Offline Offline

    Activity: 69
    Merit: 2


    View Profile
    August 07, 2023, 08:35:04 PM
    Last edit: August 07, 2023, 09:34:56 PM by james5000
     #3056
    Quote from: frozenen on August 07, 2023, 08:32:51 PM
    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
    Hero Member
    *****
    Offline Offline

    Activity: 1120
    Merit: 718



    View Profile
    August 07, 2023, 10:39:20 PM
    Last edit: August 07, 2023, 10:56:14 PM by albert0bsd
     #3057
    Quote from: james5000 on August 07, 2023, 08:30:20 PM
    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..

    Quote from: james5000 on August 03, 2023, 02:23:39 PM
    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
    Jr. Member
    *
    Offline Offline

    Activity: 69
    Merit: 2


    View Profile
    August 08, 2023, 12:15:39 AM
     #3058
    Quote from: albert0bsd on August 07, 2023, 10:39:20 PM
    Quote from: james5000 on August 07, 2023, 08:30:20 PM
    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..

    Quote from: james5000 on August 03, 2023, 02:23:39 PM
    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
    Newbie
    *
    Offline Offline

    Activity: 10
    Merit: 0


    View Profile
    August 08, 2023, 01:31:07 AM
     #3059
    Quote from: james5000 on August 07, 2023, 01:56:55 PM

    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
    Newbie
    *
    Offline Offline

    Activity: 8
    Merit: 0


    View Profile
    August 08, 2023, 02:56:24 AM
     #3060
    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....
    Pages: « 1 ... 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 [153] 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 ... 568 »
      Print  
Page 152
Viewing Page: 153

IRLBTC™ © 2025 IRLBTC.com