Quote from: mcdouglasx on Today at 02:17:16 PM

Quote from: WanderingPhilospher on March 19, 2025, 05:35:09 PM

Quote from: mcdouglasx on March 19, 2025, 05:12:12 PM

Quote from: kTimesG on March 19, 2025, 04:19:03 PM

snip

snip

McD, ktimesg and Bram, you all are arguing over doing the same thing in different ways lol.

McD has changed the way his script, or at least his thought process of how the script should work, versus his initial draft.

There could be the possibility that a 10 matching h160 is right next to another one, but of all the data I have sifted through, it never has happened. It's easy to run a decent sized range, say 2^48, where on average, you would find, 256 10 leading h160 matches, but none of them will be right beside each other. Or you can sift through Bram's PoWs and you will find, none of them are right beside each other either.

So there is nothing wrong with what McD is suggesting. You find x amount prefix, pad it by y amount on both sides (+/-) and keep on trucking until z amount of range is filled up. If key is not found, you shrink all of your previously stored padded ranges by x amount, and search again. The key would eventually be found, just as if you did large range searches, randomly or sequentially, throughout the whole range. Brute forcing an entire range says the magic key will be found on avg, at or around 50% of total range keys searched. That's an average, could be at 1% or 99.99%. The last 2 keys were found between 51-57% via large range searches, selected randomly. There is no way of knowing which is better/faster, as it depends on which key was found and padded, close to the actual key we are searching for.

For me, I would and have tweaked the way McD script/plan works. Instead of just finding random prefixes 100% of the time, you swap over to filling the gaps, with 100% of keys. So if one padded range ends with 0x...12345, then I brute force keys starting at 0x...12346 to however large a range size you want to chew up. I have the padded ranges and the complete search ranges marked differently in the db, so if I need to shrink the padded ranges, I will only shrink those and not the 100% searched ranges.

Now, for what Bibli is doing, I am not 100% sure. I know he finds a prefix and with some calculations, makes a jump and searches for the next. But in this manner you could skip over the actual key. But I am not sure how you would go back and check the gaps you skipped unless you tracked start and end ranges and jump sizes, and then go back in and have to manually fill in those gaps if key isn't found. My issue with this, is you could find a 14 h160 match in 0xF range and spend a lot of time in that range when the actual key could be in the 0x8 range. But I do not know all of the ends and outs of his plan/thought process so I can't speak on it 100%.

I don’t understand why they insist on declaring as false something that has all the logic of mathematics behind it, even when all the failure points of these methods have easy solutions that have already been discussed previously. What they do is focus on the worst-case scenario. It's like if I told Bram that his method fails because it could leave the winning block as random at the end; obviously, that’s something that could happen, but it’s absurd to say so because the probabilities would be too low to consider it a real problem. I think this happens when someone wants to maintain a position at all costs, even when it’s wrong.

They focus exclusively on the worst cases, which reminds me of the fallacy of composition assuming that because one part can fail under specific circumstances, the whole is defective.

I’ll clarify then. Of course your method works, you’re checking all keys eventually.
I’m saying there is no speed boost doing it this way instead of doing it in sequence, only drawbacks because of gap management.Those drawbacks are also minimal if the ranges are big enough, but then you’re only adding complexity to the brute force process for no good reason.