Probabilistic Prefix Search vs Random and Sequential Methods Part II

So in the last discussion, we figured out that there wasn't really any statistical edge between prefix and sequential searches. But honestly, I think we can dig a bit deeper into this topic and explore what else could be done. I'm not trying to prove one method is definitively better than the other in this round. Just want to shine a light on the benefits of using the prefix method over sequential searching. Let’s break it down into two parts: First part There could be some improvements, but they might not be super significant. Second part It's a tool to boost the odds of hitting the target, but we shouldn't expect a guaranteed outcome (it’s still gonna rely on luck). Now, jumping into the first part: I've come up with a second phase for prefix detection that gives a slight upgrade to the method we talked about before. Just to recap, last time we split the scan range into blocks based on the likelihood of encountering a 3-character hexadecimal prefix in a dataset, which was 1/4096. So, we made these blocks equal or close in size. Once we found a 3-character prefix, we would skip the rest of that block and save it for later. Now, here’s the new bit: we’ll stick to the same idea, but instead of skipping the remaining blocks, we’ll look for prefixes with 2 hexadecimal characters in the following keys, which is one less than our chosen block size. This way, we can leverage the combined probability and reduce the chance of missing the target.

result At this point, you might think I'm being unfair to the sequential method, since it only compares the number of times the prefix wins 1:1. But that's not what I want to reflect. What I want to highlight here is that when the prefix method wins (which happens in most cases), it does so in a big way, and it's ideal for searches where the goal isn't to find a 100% final result.

Say for puzzle 71 you started searching for the prefix 1PWo3JeB9jr.  There are ~ 3150 prefixes in the keyspace that start with 1PWo3JeB9jr and let's say you starting searching in the middle and found the first 1PWo3JeB9jr around 50%. Break up the 71 keyspace into 3,150 blocks each with 750 Quadrillion keys each. What if you made approximately 1570 (+750 quadrillion) jump points going up from the prefix 1PWo3JeB9jr and 1570 (-750 quadrillion) jump points going down from the prefix 1PWo3JeB9jr and then searched all those points simultaneously from the midpoints outwards?

what I would do is divide the search range into 3150 blocks of subranges, organize them randomly, and look for h160 prefixes equivalent to the prefix in question (the hash160 that produces the address with the prefix "1PWo3JeB9jr"), I search the blocks sequentially and each time I find the match of the prefix I save the remaining range of the block in a txt, and discard said block, in 60:80% of the cases, you will not need to review the . txt, in the worst case (when your target is in the same block where statistically there should only be 1 "1PWo3JeB9jr" and that coincidentally is after the first "1PWo3JeB9jr" which is not the target within the same block, you will have to go to the TXT (as you will see a series of unlikely things must happen for you to need the txt). Therefore, the probability of finding it with less effort than traditional sequential brute force is higher. but the effort you would make if the worst case scenario happened as a consequence would be equal to searching the entire range in the traditional way.

Added a script that simulates a real-life Bitcoin environment in a low bit range. This is complemented by real-life probabilities, since the range size doesn't matter; the statistics will remain the same as long as the following rule is used: test 1 test 2 test 3 test 4 The Iceland module is required. https://github.com/iceland2k14/secp256k1 The Iceland files must be in the same location where you saved this script. Some operating systems require Visual Studio Redistributables to be installed for it to work. You can adjust the number of tests by setting total_runs = 100. Increasing the number of tests will give the same consistency to the results, since the statistics remain the same.