Zbyszek2 sampled WIF keys and performed analysis and proved in his post earlier, that it is impossible to see such a correlation in real WIF key.
In short - you discard blob on a weak assumption that it is not random. All the data is not random and should be thus discarded, don't you agree?
If the data were perfectly random you would not be able to read it into WIF key.
.....
Guys I would like to apologize for a mistake I made in my previews analysis.
I assumed that the private WIF key is
random (private/public key pair was generated with a vanitygen like tool without modifications)
so my conclusion was that the "yellow/red", "green/blue" bit stream can not encode a private key.
Unfortunately my assumption might
not nesesery be true, in fact there only needs to be about
length("FLAMEN6")*6bits= 7*6bits = 42bits random bits in a stream to generate a public key with "1FLAMEN6" prefix,
so not only the "yellow/red", "green/blue" stream may contain a valid private key, but also only the "short/long" stream is enough to create a valid private key with a "1FLAMEN6" prefix.
Even more, it's probably possible to modify the original vanitygen source code so, that the time it would take to find such a private key is the same as now (on my laptop the estimation is ~5 days). The only change would be to feed vanitygen not with random numbers but with a desired bit pattern + the 42 random bits.
If this is the case in this puzzle, you have to decide for yourself.
Exactly. I did research that as well for itod:
Like you said, when dealing with chaos, to receive X bits of your choice, you may very likely only have to change X bits in the input, regardless of the intermediate steps. In my research it's a loop of SHA256. The Private->public key computation serves just as well, hence the private key could be like 200 zeros followed by 56 or less bits of actual random data. It could be also Bacon26-encoded 10 random words from the English dictionary, whatever meets the entropic-I/O-shift requirements.