Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
so you were going to prove that I was wrong, someday?
The arrogance is astounding.
You probably have to chage 20 or so lines of code to accomodate the script to your theory and run it by yourself, but you wont.
If this does not change your mind, nothing will and I wish you all the best.
20 lines, lol, I just want to make it clear that you shouldn't criticize without knowing. I don't criticize anyone's ideas here, so why would you come and criticize mine? If it's 20 lines, why didn't you do it? That was your main purpose, wasn't it?
I did not do it because it will never be good enough to convince you. I realize that now.
If it shows no improvement over random, you'll say it's because its numbers and not private keys..
if I change it to be private keys and your method, you'll find another way to dismiss it, and so on.
To be honest I'm quite sure you didn't bother reading it or running it. So well, you win this argument
Enjoy !You have just exposed yourself. First, it makes no sense with any of the methods discussed here. Second, where are the hashes in your test? You skipped the fundamental part of the theories here: uniform distribution of the hashes. Without hashes, there is no uniform distribution, so your script is meaningless. Lol.
I will have to think about all of what has been said and look at Bram's script and how it was used, before I can give a quality answer on it all. However, my initial thoughts with prefix padding then searching (random then sequential) versus random then sequential are a wash. Can one find lightning in a bottle by using prefixes (in whatever way, skipping keys, padding, etc.), YES.
Could Bram find the key in the first random block he/his program chooses to search, YES! But for both, the averages, tell us a different story...50% on average. So yes, both could find the key within the first minute of searching, and sometimes it may be the last possible range to search...but the averages, smooth out over x amount of tests.
Now, I say this, about the averages, but I also believe it to be true about h160 matching characters (bits) as I have seen in running numerous tests. People should not talk about averages in one way, but neglect to mention them/think about them in another way. Sometimes, I forget about one side or the other as well, so yes, I am at fault too.
However too (lol), in doing this and that and testing this and that, I feel like I have a better method for identifying "more than likely" ranges and the whole work distribution, than I had in the past. Instead of just taking a range and dividing it by x, and then searching one of those ranges, I like the way I am doing it now, based off of h160 matches and averages. Will it solver faster? Only if I one can narrow down the paddings...narrow, may not be the right word...more like, create the largest "gap" in between found found h160 matches, without going over...maybe I should call it the H160 Matching Showcase Showdown, method...LOL. So in summary, I think ktimeG, Bram, Bibli, and McDouglas are all correct, just in different things lol.
Back to dirt and mulch...
P.S. If my bot says I found the key, reach out to me...LOL
P.S.S Still a lot of openings in the Beat Bram donations/crowdsourcing
From a mathematical perspective, Bram's comparison script doesn't make sense for any of the prefix ideas. The hashes are replaced by Math.floor and Math.random() to emulate. he use o a pseudo-random number generator that is not cryptographically secure. The process is 100% invalid.
Ktimesg knows this but
... showing a double standard in their words. In my opinion, this only demonstrates that their arguments are biased, and ironically, they dare to talk about bias. Lol.