Bitcoin puzzle transaction ~32 BTC prize to who solves it

[POD5]

P.S. I just realized that 'Akito S. M. Hosana' is an anagram or deliberate variation of 'Satoshi Nakamoto.'  

Yes, I had that tought too before...  
But no, Satoshi has dedicated himself to other things and he wouldn't even read Bitcointalk.  

[kTimesG]

What I understood is that it's not a search function,it's a feature that, when added to whatever search system you choose, boosts its success rate.

The only way to prove that prefixes don't work is to find a search method where, if you apply the same logic with prefixes, it actually makes things worse. Otherwise, it's doing something right.

1. The Scooby Doo method (the original version) boosts the success rate of the corresponding sequential order method just as good as the prefix method, without ever needing to check for any prefixes. In other words, if one would have to choose between a method that pretty much does nothing except increase the statistical variance, and the prefix method, he has a valid choice that works just as well.

2. Are you OK? The Scooby Doo: The Mystery Returns! method proved that reverse sequential search is faster than the prefix method. In other words, if one would want to choose of finding a key faster, than the Scooby Doo: The Mystery Returns! method is the one that a sane person would choose.

3. In the same way, Scooby Doo: Origins method proved that a sequential search is faster than the Tweaked Prefix Method That Beats Scooby Doo 2. In other words, if one would want to find a key faster, and he can choose between these 2 methods, the one to choose would be Scooby Doo: Origins.

QED, pretty much.

[fixedpaul]

The only way to prove that prefixes don't work is to find a search method where, if you apply the same logic with prefixes, it actually makes things worse. Otherwise, it's doing something right.

Just replace in any prefix-method script the prefix "puzzle" with any prefix, even a random One. And you will see that absolutely nothing changes, you can try it yourself.

If the prefix-method really does work, why does it perform the same way with any prefix instead of the puzzle prefix?

[fixedpaul]

The only way to prove that prefixes don't work is to find a search method where, if you apply the same logic with prefixes, it actually makes things worse. Otherwise, it's doing something right.

Just replace in any prefix-method script the prefix "puzzle" with any prefix, even a random One. And you will see that absolutely nothing changes, you can try it yourself.

If the prefix-method really does work, why does it perform the same way with any prefix instead of the puzzle prefix?

What you're talking about was already brought up here

Code:

random.randint(0, 5000) == 0:

, and it doesn't give the same results.

...

Let's just drop it, like I said, not my battle.

Try 4095 Instead of 5000. I already explained this a few posts ago. Same results

Maybe generating an hash and looking at the first 3 hex digits (12 bits) is basically the same as generating a random number between 1 and 4096?

Maybe Is all rigged

[kTimesG]

At first, I doubted it too, just like you. But after seeing the evidence, I think you haven’t really read the whole thread. Anyway, this ain’t my fight, so I’ll respect your take.

I'm afraid I haven't really seen the evidence you're referring to.

If it's about the "winnings" when compared with the same traversal order sibling method, then you are a victim of not understanding some basic statistics, and actually believing the psychedelic explanations, which lack any sort of theoretical basis or proofs whatsoever, let alone actual empirical results. It is totally irrelevant even if the so-called "better" method has 100% wins and solves stuff a billion times faster than some other method, if it only takes 5 seconds to come up with a counter-method that not only isn't so easy to beat, but it actually wins more. Isn't that something that, maybe, uhm... would make someone wonder why it happens? Perhaps because there was a linkage between how the methods were compared, when such a linkage should never exist?

All the tests / experiments / results / scripts so far that the troller claims to "not have proven anything" have all demonstrated that a uniform distribution doesn't give a shit about what strategy you use to attack it. It's retarded to ever think that if some whatever search method can be completely obliterated by 3 lines of code, that it somehow broke cryptography. The only thing broken about it is common sense.

[Bram24732]

I’m no mathematician

Then maybe just maybe trust what mathematicians have to say and not a random dude who likely has zero math background ? (Happy to be corrected on that if McD has any math credentials, which I really doubt)

[fixedpaul]

Try 4095 Instead of 5000. I already explained this a few posts ago. Same results

o.k, i'll check.

edt:

Interesting results. Looks like when you tweak the parameters like you said, both methods end up working similar. But you're kinda proving mcd right here, even though you're not directly hunting for a single prefix, you're still using a prefix-based strategy with that 4095 pick. You're just not targeting something specific. So this doesn't wreck his theory... if anything, it backs it up.
.
.
I’m just going by what each side posts here. not trying to mess with anyone’s opinions. I’m no mathematician, so I can’t be sure of anything.

Exactly, I'm replicating what the mcd code does, which is stopping/pausing the range search, on average, every 4096 (16^3 prefix combination) keys. Nothing more, and it doesn't provide any advantage compared to a sequential or random search. It's just a way to show that the analysis claiming more "wins" is actually flawed.

Anyway, you don't need to be a math expert to understand the concept of uniform distribution and independent events. Just a bit of common sense and logic is enough.

[WanderingPhilospher]

SCOOBY SCOOBY DOO! LOL

Search is on auto pilot, and all dirt has been moved to its new home, so I had some time.

Looking at all the test variants out there, and seeing this Scooby Doo method being used recently and tweaked by both sides, I thought I would look at it and do a little "tweaking". First, to me, there are flaws on both sides.

I know we agreed a few weeks back, the only reason you would not start at the beginning of a range and just go sequentially, is because the "competition" would know where/what you have already searched...even though Bram's search status is not publicly known. We still agree on that, that straight sequential versus random subrange + sequential both still average out to 50% find average, correct?

So in these tests being ran and tweaked, 100,000 seems to be the default total size and then a block size/sub-range size of 5,000. For whatever reason, brevity maybe? But ok, we can still go with that. But it is crazy to compare that size to say a size we are actually looking in, such as now, a 2^68 range size. So I tweaked the tests to just create a total size of 2^17, closest to the 100,000 qty mostly used on these tests. But, I changed it to where it is only 1 block/1 range. And if we all agree on (straight sequential versus random subrange + sequential both still average out to 50% find average) then w start both methods at key 1 and search sequentially til key 2^17. Anything wrong with that so far? I do not like the shuffle method, unless for each sub test, the shuffle is the same for both methods; if not, then really it is which random shuffle got the other method to the actual subrange, quicker, which is just dumb and not what we should be testing here. That is basically luck of the draw IF we shuffle the sub ranges differently for both methods.

Ok, so any flaws yet in my tweaks?

To summarize my tweaks:

1 range
Both methods start at key 1 and work sequentially.

Any issues? I will continue if no one objects to the tweaks so far. (Bare with me here)

Edit: these comments crack me up lol:

Exactly, I'm replicating what the mcd code does, which is stopping/pausing the range search, on average, every 4096 (16^3 prefix combination) keys. Nothing more, and it doesn't provide any advantage compared to a sequential or random search. It's just a way to show that the analysis claiming more "wins" is actually flawed.

Anyway, you don't need to be a math expert to understand the concept of uniform distribution and independent events. Just a bit of common sense and logic is enough.

Then maybe just maybe trust what mathematicians have to say and not a random dude who likely has zero math background ? (Happy to be corrected on that if McD has any math credentials, which I really doubt)

If you really think about x y and z you would see something...and the "math" would talk to you lol.

[WanderingPhilospher]

Any issues? I will continue if no one objects to the tweaks so far. (Bare with me here)

No one will answer lol?!

That's cool. No one wants to be "wrong" or even partially wrong.

SO I have told the flaws with the one side's view. The other side's flaw is the skip window and the skip window % (skip_count = int(skip_window * skip_percentage)). Maybe not a flaw, but I am not sure any tests with data results were ran, or at least, not enough data/tests collected. The ones I have seen in the tests are way too large for the small range size and prefix length.

With our 2^17 range size, it is easy and quick, to run 1,000 tests and collect the data from that; regarding how often 3 prefixes occur, the average distance apart, and what is a good skip count number that really skips some keys to try and speed up the search, but not too large where you are constantly skipping over the key you are looking for. SO you run those numbers and come up with a skip count threshold that you are comfortable with, risk versus reward. The lower the skip count, the more times prefix search will win versus sequential. It's just basic math, and no, I am not a math expert. The larger the skip count, the more the results will start to shift back to a 50/50.


500 tests each:
smaller skip count:

Code:

=== FINAL RESULTS (Sequential, Full Range) ===
Wins:
Scooby_Doo: 2
Prefix: 486
Ties: 12

Total Checks:

Scooby_Doo: 33938958
Prefix: 33952675
Total Time:

Larger skip count:

Code:

=== FINAL RESULTS (Sequential, Full Range) ===
Wins:
Scooby_Doo: 22
Prefix: 466
Ties: 12

Total Checks:

Scooby_Doo: 33938958
Prefix: 34341946
Total Time:

The only time the prefix would lose, is if the skip count was larger than a found prefix and the actual key/prefix we were looking for. That is why running tests and analyzing the data for the skip count, based off of range size and prefix length is the most critical aspect, IMO.

[kTimesG]

SCOOBY SCOOBY DOO! LOL

If you really think about x y and z you would see something...and the "math" would talk to you lol.

The problem with a uniform probability distribution is that you never know whether you'll get lucky, or get really unlucky, or hit the expectations, or pretty much anything in regards to any guarantees, no matter how likely or unlikely the confidence levels might look. Especially when trying to analyze all the atoms in the Universe using a microscope that zooms into a protein.

Is H160 rigged? No one knows really. Is it biased? Anyone's guess. Do we live in a simulation? Well, no one can prove the contrary. Proofs about any of these? Zero. Can we catch a dozen 48 bits prefixes in 5 minutes instead of waiting a week? Sure, why not. Can we maybe not find a 56 bit key after hundreds of thousands of trillions of scanned keys? Unfortunately, yes. Just because the chances are below 0.1% doesn't mean the math's broken, it just means you might have a bad day. Especially when you only scanned 0.001% of all the keys of interest.

TL;DR - Eagerly waiting for something tangible. We can all do philosophy.

Any issues? I will continue if no one objects to the tweaks so far. (Bare with me here)

No one will answer lol?!

That's cool. No one wants to be "wrong" or even partially wrong.

I have a strong hunch that you'll get the same behavior if you replace the prefix logic with the Scooby Doo method. Because the main point is that the "wins" were caused by increasing the statistical variance, not because the prefix matched. Now my question: how does winning matter? What counts is the average number of ops, not a kindergarten-type sports betting metric.

[WanderingPhilospher]

Eagerly waiting for something tangible. We can all do philosophy.

Already given...

I have a strong hunch that you'll get the same behavior if you replace the prefix logic with the Scooby Doo method. Because the main point is that the "wins" were caused by increasing the statistical variance, not because the prefix matched.

You lost me there. If I change prefix to scooby doo, they would all be ties lol. Maybe I am misunderstanding you. And maybe you miss how my scooby doo script works, too.

Now my question: how does winning matter? What counts is the average number of ops, not a kindergarten-type sports betting metric.

That is kind of a kindergarten question, TBH. We are looking at a small, very small, test range. 2^17 lol. Nothing, nada.

If I we were to run this over the entire 69 bit range, I would guarantee the prefix would win, if the key was in the last region, total searched keys, by at least 2^52 keys and a significant amount of time, depending on how much hardware you are using.

[hoanghuy2912]

Puzzle 69:  

19vkiEajfhuZ8bs8Zu2jgmC6oqZbWqhxhG
 
Start Hex : 176DAEDFC76AE2EE58
End Hex: 17733BF5A8E10AEE69

why

[kTimesG]

You lost me there. If I change prefix to scooby doo, they would all be ties lol. Maybe I am misunderstanding you. And maybe you miss how my scooby doo script works, too.

IDK which version of Scooby Doo you are using!

Original: random.randint(0, X) = whatever (unless random's rigged, who knows)
The Mystery Returns: reversed sequential beats forward prefix
Origins: scan from 1 to N beats reversed prefix.

If at least one of these methods beats or matches your prefix improved method - that means it works better (or matches) and is the preferred option (or at least is a cheaper alternative). Otherwise, congratulations! You found a crack in the math, and most likely in reality as we know it.

[WanderingPhilospher]

You lost me there. If I change prefix to scooby doo, they would all be ties lol. Maybe I am misunderstanding you. And maybe you miss how my scooby doo script works, too.

IDK which version of Scooby Doo you are using!

Original: random.randint(0, X) = whatever (unless random's rigged, who knows)
The Mystery Returns: reversed sequential beats forward prefix
Origins: scan from 1 to N beats reversed prefix.

If at least one of these methods beats or matches your prefix improved method - that means it works better (or matches) and is the preferred option (or at least is a cheaper alternative). Otherwise, congratulations! You found a crack in the math, and most likely in reality as we know it.

I told you exactly what I tweaked.

It is now just one range, not broken up into subranges.

Both start at key 1 and go sequentially until key 2^17.

The prefix finds a prefix and jumps by "skip count"; the part I said was the most critical part of it all. If it does not find it because it skipped over the key, it goes back to first unchecked key and goes sequentially until it finds the key.

If I changed that to mirror scooby doo method, they both would start at key 1 until key is found and would always result in a tie.

What am I not understanding or you not understanding lol?

There is no crack in the math, just the opposite, we use math to help, on average, find the key faster. But that all comes down to skip count size. Too large = probably skip the key during the first run. Too small, not really speeding up the process, by oodles. So one has to analyze their prefix length and range size to come up with their own personal risk/reward skip count number.

And that was a flaw to me, in McD's original. Too large of a skip count, based on the tests and data I ran.

[kTimesG]

Both start at key 1 and go sequentially until key 2^17.

The prefix finds a prefix and ...

What am I not understanding or you not understanding lol?

You are creating a statistical bias; while denying the use of a different strategy (scan in reverse) that proves that the prefix version is biased (since it will lose).

Do you want the analysis of why that happens? A simple histogram is pretty straightforward, I posted it twice already. In English: when prefix loses, it loses more badly, then in the cases when it wins.

By this kind of logic, then Bubble Sort is the best sorting algorithm in existence - because it forbids the existence of other algorithms to do things differently.

And yeah, the winning dick-rate contest has no math basis at all - it completely dismisses the "loses" scenarios. The proper comparison formula is pretty simple:

averageNumOps = totalOps / totalSimulations

which is pretty much the same as multiplying "Ops / wins" by "win-rate". This last part seems forgotten in translation by McD. Because probably multiplying by the actual win-rate is not something to acknowledge, as it shows that both methods are equivalent on average.

[E36cat]

could be anywhere but if you thinking at hex 4321 you go ahead and scan it yourself

Puzzle 69:  

19vkiEajfhuZ8bs8Zu2jgmC6oqZbWqhxhG
 
Start Hex : 176DAEDFC76AE2EE58
End Hex: 17733BF5A8E10AEE69

why

I'm 70% sure the key is in this range. Try it, you'll thank me later.

[WanderingPhilospher]

Both start at key 1 and go sequentially until key 2^17.

The prefix finds a prefix and ...

What am I not understanding or you not understanding lol?

You are creating a statistical bias; while denying the use of a different strategy (scan in reverse) that proves that the prefix version is biased (since it will lose).

Do you want the analysis of why that happens? A simple histogram is pretty straightforward, I posted it twice already. In English: when prefix loses, it loses more badly, then in the cases when it wins.

By this kind of logic, then Bubble Sort is the best sorting algorithm in existence - because it forbids the existence of other algorithms to do things differently.

And yeah, the winning dick-rate contest has no math basis at all - it completely dismisses the "loses" scenarios. The proper comparison formula is pretty simple:

averageNumOps = totalOps / totalSimulations

which is pretty much the same as multiplying "Ops / wins" by "win-rate". This last part seems forgotten in translation by McD. Because probably multiplying by the actual win-rate is not something to acknowledge, as it shows that both methods are equivalent on average.

So you are saying if I start at 2^17 and work backwards, the prefix method will lose??

So if I run scooby doo against itself, one starting from end range and one starting from start range, the one starting at end range will always win? Is that what you are saying?

How? it would all depend on where the key we are searching for, was randomly generated at...it should be 50/50, no? 50 below the range/2 line and 50 above the range/2 line? Or no?


reversed, starting at end range and working backwards:

Code:

=== FINAL RESULTS (Sequential, Full Range) ===
Wins:
Scooby_Doo: 1
Prefix: 487
Ties: 12

Total Checks:

Scooby_Doo: 31597542
Prefix: 31485133

compare to starting at start range and working forward:

Code:

=== FINAL RESULTS (Sequential, Full Range) ===
Wins:
Scooby_Doo: 2
Prefix: 486
Ties: 12

Total Checks:

Scooby_Doo: 33938958
Prefix: 33952675

[kTimesG]

reversed, starting at end range and working backwards:

Code:

=== FINAL RESULTS (Sequential, Full Range) ===
Wins:
Scooby_Doo: 1
Prefix: 487
Ties: 12

Did you modify your prefix method to also go in reverse, by any chance?

[WanderingPhilospher]

reversed, starting at end range and working backwards:

Code:

=== FINAL RESULTS (Sequential, Full Range) ===
Wins:
Scooby_Doo: 1
Prefix: 487
Ties: 12

Did you modify your prefix method to also go in reverse, by any chance?

Yes, do I need to run the prefix forward and the scooby doo in reverse?

Running both in reverse, but made the block size larger, 2^20 compared to 2^17, to see some different total ops numbers.

[kTimesG]

Yes

You're just dragging along the bias.

If I bring up Scooby Doo 4.0 that does random picks, and your prefix method runs along the exact same sequence of random picks - prefix will win. But that happens because you are simply integrating the bias into the comparison, which is kind of non-rational.

It has nothing to do with RANGES or subranges or "proximity bias". I think you are getting a little fooled by a natural consequence of traversing the exact same sequence of values using two different strategies, while not acknowledging that a third one exists that beats your "winner" on that same exact dataset.

Where's the logic in that?