Ok, so, when I first found out about this puzzle and started looking into it earlier this year, I was initially working under the assumption that there would be some clues or patterns that could be found to help unlock the remaining wallets... But, of course, I now know what you all already knew: There are no clues or patterns, at least nothing included intentionally by the person who created and funded these wallets...

However, I recently revisited my pattern-finding script, looking instead for any bias(es) in the data that I might be able to find (created by the pseudo-random number generator, or by assumptions built into the wallet generator's code, etc) to at least help shrink the given search spaces as much as possible, and I think I may have (possibly, maybe) found one... The problem is that even if I'm right, I just don't have the computing power to test my theory, nor the funds to buy/rent it, and won't for the foreseeable future... So I'm just going to post it here, in the hopes that, if it is useful at all, then whoever uses this to help them open any of the remaining wallets will be generous enough to kick-back a percentage of the winnings (my BTC address is bc1qmzud9l4aedq6h73efaj3vg3fdqhgv8w4ktq0pt)

Ok, so, my theory goes like this: I initially looked at all of the known pkeys (as decimal numbers, not hex) and calculated their location within the given puzzle's search space as a percentage, like this for Puzzle #11:


Now, if that math is wrong, then I'm already screwed and you can give-up now

But after doing that for all the known pkeys, and looking at all the results, I didn't see any pattern, so I gave up and moved on to the next possible pattern I could think of... However, when I went back looking for a bias in the data instead of an outright pattern, I believe I have found that certain percentages (when just looking at the whole number... so 12% for the above example, instead of 12.8%) do (seemingly) occur more often than most...

I first grouped them by the tens (so 20 for 20-29, and 30 for 30-39, etc) and here's the results:


So, looking at it that way, you can see that it seems like the 60-69% range hits way more often than the average... But even searching 10% of any given search space is still a crap-ton of brute-forcing to do, so I kept looking and noticed that certain individual numbers show-up more often than others, so next I grouped more simply by just the whole number:


And here it appears as though the 82% range occurs way more often than any other, followed closely by 64% and 66% (which occur 3 times each)... Which could (again, theoretically) let you search only 1-3% of any given search space... But, unfortunately, that's still way too much brute-forcing for me to even attempt, given that there's no way to know which of the remaining pkeys will hit these ranges (and so you'd have to try several before finding a hit...)

...and that's assuming that this is a true bias in the data, and not just a coincidence that would even-out over time, which is the other possible way I can think of that this theory could completely fail: Maybe all the keys that could be found within the eighty-two-point-something percent range of their search space (for example) have already been found, leaving the others that have only hit once or twice so far to "catch up", statistically speaking...

Anyway, am I just an idiot, or does this make any sense to y'all...?

ok, I'm looking at getting a GPU and trying BitCrack now, but before I do I wanted to know what I can expect...

according to this post (https://bitcointalk.org/index.php?topic=4453897.msg56953547#msg56953547) then if I got an RTX 3090 I'd be looking at roughly ~1800Mh/s...

so, to search the whole range of Puzzle 67 (for example), how long would that take...? because my math says ~1300 years... is that right?

Thank you for your answers to my posts, they've been helpful I'm curious how many of these you've solved with this method of seeding the random with specific values; was it only #50?

I'd like to review all your posts (and some other users' too) but whenever I go to your profile and click either "Show the last posts of this person" or "Show the last topics started by this person" I don't get any results


This is me NGL

@nomachine after successfully proving to myself (I'm a bit behind the curve here) that anything I thought was a pattern/clue to solving this puzzle was just part of the maths inherent in the system, I'm now of the mind that this is correct... We can either try to brute-force the pkeys, and/or we can try to reverse-engineer (also by some amount of brute-force, I guess) and recreate the process by which the pkeys were created... Which is likely possible given that A) you appear to have done it at least once already for puzzle 50 above, and B) the person who claims to have created this said themselves that "It is just consecutive keys from a deterministic wallet"... That is, assuming the the words "consecutive" and "deterministic" apply accurately and weren't just used colloquially...

Anyway, I've looked through the code you posted (which I've snipped-out for brevity)... Is that python? I'm afraid IDK python... Which version are you using? 2.3 or newer, I assume? And can you explain more about what exactly is happening here:


...it looks like you start with whatever this is, a hard-coded byte string or something?


...and then you go on to read more, random bytes from some file on disk? As a Windows/C# guy, I just can't quite grok what's happening here    Any help would be much appreciated 

Ok, so, I'm really hoping someone can help me out here...

I just learned about this puzzle a few weeks ago, and have since been writing scripts to try and find as much of the "pattern" used to generate these keys as possible, because I was convinced (mainly by this post at first) that there must've been a pattern, given the seemingly perfect incremental nature of the Log2 of each known private key (if you look at the whole number part, ignoring the decimal place)... And also, I think I was influenced by the fact that this is called a puzzle, and a puzzle is supposed to have, you know, clues and things that help you solve it, or at least a logic to it that is "figure-out-able"... But I digress...

Fast forward to yesterday, when I stumbled across the above post... If we assume this person is telling the truth, that they are "the creator" of this puzzle^[1], and that "there is no pattern", and that they simply used "a deterministic wallet" to generate "consecutive keys"... Well, then, I'm stumped...

I mean, first of all, what kind of wallet software can you use to "randomly" generate 256 keys that are all perfectly spaced apart, with Log2 values that just happen to be exactly incremental by one each...? Unless it's a total coincidence that, so far, all the solved keys just happen to have incremental Log2 values, and we'll eventually solve a key that doesn't...? (one which is either a duplicate of the previous one, or skips one whole number entirely, etc)

And then there's the fact that all of the hex values (as strings, minus the leading zeros) all appear to be grouped into groups of 4 by character length...? (e.g. the first 4 hexes are all 1 character long, the next 4 are all 2 characters long, etc...)

I mean, am I wrong that it doesn't seem to me like math with no pattern whatsoever would just happen to work-out that way? Are these "patterns" that I think I'm seeing really more coincidental (and not purposeful) as I imagine them to be? Or is this actually all an artifact of the cryptographic process and the math that powers Bitcoin...? That for Bitcoin to work properly, there is, in fact, some amount of pattern in the chaos?

I'm much more likely to believe that these keys were actually generated by a script (or some process of some sort) written/designed by the person who created this, and that even if they didn't intend for there to be a pattern, there is one^[2], and so maybe there's more to it that can still be discovered, to help lower the search space of each key even more that we already have... But maybe I only think that because I want there to be a way to solve a puzzle that doesn't actually contain any clues, or have any internal logic, and must simply be brute-forced, a feat that even the LBC has struggled to make very much progress towards...

So, help me out here, what do you think? Are these "patterns" that seem to be "clues" really either just coincidence, or artifacts of the formula and algorithms powering the system...? Or are they real patterns injected by the human who created this puzzle (intentionally or not), and could there be something else in the data that we just haven't noticed yet?

And maybe more importantly, what does a process for generating a puzzle like this even look like? Can you really ask a wallet software for 256 random but evenly spaced private keys, or would you have to script some amount of the process? I feel like if I can reverse engineer the creation process from the currently known data/results, it could help me figure-out if there's more to the pattern, or no pattern at all...



[1] A claim seemingly verified by the fact that the funds did actually move from the higher wallets to the lower unsolved wallets a few months later... Though of course that doesn't prove that they're the person who actually moved them, but then why would the real creator give this person credibility by doing for them what they promised us they'd do...?

[2] If only because people are known to be inherently bad at creating real randomness, and often inject patterns into things they make...

Hi Legends_Never_Die -- Thx for the reply!


Ah, I see. I'm afraid I've never heard of a "master private key" before...

Do you know how would I generate a... well, now I don't know what to call it... but a "regular" private key from a hex? I just need to give NBitcoin that hex and then get the expected address from it, and I was using this StackOverflow as an example, which is using `ExtPubKey` to generate a public key from some kind of hash, so I "extrapolated" (aka assumed) that `ExtKey` would be the private key version of that... But I guess that was wrong Although one of the overrides for `new ExtKey()` does take a `hex` param, so I really thought I was on the right track...

And I checked out that link to csharp.hotexamples.com you posted (thank you for that) but I can't seem to navigate that site very well to get to any other pages that might be helpful (I tried the search, but almost everything I tried gave me a 404)...

I do see this on that page:


...and I'm guessing that could be mean I just need to use a `Key()` instead of a `ExtKey()`...? but `Key()` doesn't seem to take a hex value at all... and `Key.Parse()` takes a WIF, but I'm not sure how to generate a WIF from a private key hex either, so, yeah, I'm still stumped...


If you mean use an existing puzzle solver, well A) to learn all this stuff, but also B) I really don't know where to find existing ones...? And the code I've seen posted here all looks like C or C++ that I'm not very familiar with, so I wouldn't know how to modify any of it to do what I want...

Thanks again for the response, and let me know if you can help me get from a private key (in either decimal or hexadecimal form) to the funded address using C# ... doesn't even have to be with NBitcoin, that just seems to be the most popular Bitcoin lib for .NET

---

Did it! Thanks to this SO post I finally found:

https://stackoverflow.com/questions/74753526/get-private-key-from-a-biginteger-in-nbitcoin

So I can use the decimal version of that hex, 2683, and do this:


...which returns the expected (previously funded) address of "1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot", and the added bonus is that I don't have to convert the BigInteger numbers I already had into HEX strings after all 

[moderator's note: consecutive posts merged]

Hi -- Is anyone here familiar with NBitcoin for .NET? I basically only know C# so I'm hoping someone can help me with this one step I'm stuck on...

I'm testing with puzzle #12 just to see if I can generate the right address from the now-known private key... Private key and funded address are listed as:


However, the following code keeps giving me a different address:


Thanks in advance... I was making really solid progress all morning, then hit this inability to generate an address I can reliably use to match against the known-funded addresses of the remaining puzzles, and without that I'm basically dead in the water... I can guess all the private key hashes I want, within the range I want (for puzzle #66 currently), but who cares if I can't verify whether I hit the right one?!