Topic: The Legend of Satoshi Nakamato, FINAL STEP PUBLISHED.... 4.87 BTC GRAND PRIZE! - page 19. (Read 108519 times)

It's what I noted in one of the posts above, that if "1flamen6" is a clue, and some encoding only needs 5 bits (like Bacon26) but they used 6 bits, then 6th bit will always be NULL, hence after XOR'ing with 011010, 011 pattern will prevail all throughout the stream of 152 flames. They XOR'ed this or multiplexed it with 011. Either way, it was intentional cause "no brute-force needed" rule would otherwise be broken (we wouldn't know the reading order).

PS. Keep in mind the Art has 011010 twice (ribbons and the Bishop), where in Bishops case, the first 0 is a mirror (like in the "codec" analysis in my earlier post). The 011 also exists, in the "melting" points coming from the Bishop. Interestingly, the last melting droplet points at the exact flame that is the "mirror" in the codec line.

If you define "red and long" as an irregularity, and then there are more longs than shorts, and there are 76/76 red/yellow, then red&long will show irregularity.

It may well be. But I am thinking it is there as an artifact of some other thing they did with the data. So it is not there with a purpose to show us the way to read the data, but rather it is there as the result of some other thing and we exploit it (thanks to alphabetcanary) to get the order on data. In the same way, we may find a way to exploit other regularities.

Well, I am not thinking that it did push it to 103, (Zbyszek2 provided his analysis of randomity in this regard) but you are welcome to run R or MathLab tests, which will prove definitely this or that way
EDIT: the reason I am not thinking that, is that if you match random data against fixed data you should get the random match count, don't you agree ? There is no way that fixed regularities can raise match count against random data.

The 011 pattern could be very well only left there for us to properly read the bits (cause you can only read it in 2 ways, following same order just in different directions). Next, if you do a data analysis against Heights, then I have some bad news for you - from the fact alone, that there is a constant pattern of 011 in every other bit, your analysis gets corrupted begin with. There will be 25% more long ones, and given the psuedo-randomity of other tracks, this can very well push the 76/152 to 103/152.

If you carefully read what I wrote, then you'd see that I meant its not good for a random private-key bits in plain form. I did note its entropy is low, which points towards encoded text, so we agree on that. However, it can be also a case where the Author chose those at "random", and if you know some thing or two about magic tricksillusions, humans are not really good at RNG, so the data might be skewed and show repeated patterns.

To tell you the truth, I am confused with your argumentation. You are saying that the data from you analysis is not random what proves that it is realy THE DATA, while at the same time you are saying that being not random is a "cons" against blob track being THE DATA. It is confusing. I am leaning to thinking that if something I am seeing is not random, it is an artifact resulting in how the authors "coded" the key. So any non-randomity I find, I try to exploit it searching for reasons it is there. I am actually happy to see any non-randomity in data as it gives me the way to look for WHY it is there.

I analysed the 6 bit "words" coming from the blob track (there are 25 of them, 6x25=150, + 2 bit outliers) and there are only 16 values. The chance for it is less than 0,5%. It MUST be a human creation, you see.

You're free to disagree with us, just as we are free to comment on the art however we want. It's easy to make a complicated puzzle that cannot be solved and our current educated opinion is that's the case here.

Just a small recap, the puzzle contains ambiguous "clues" that point at the following scenarios:

1) 2x QR code, version 1, ECC level L, 21x21

• it needs 152 data bits
• the Phoenix 11110 decoded as QR formatInfo results in 011 mask type and ECC level L (which gives around 16-17 bytes per QR, so enough for a 256bit key)
• previous ARGs were QR related
• there are "blocks" on the art, like in QR
• there are "patterns" in the corners

2) Code128B barcode

• we have 17 leaves and 17 repeated bits (in reverse, "mirrored" outer color stream versus inner color stream)
• Phoenix spikes 11110 in binary encode number 30 in decimal
• 30 is the number of characters for a mini private key, which YES, can be used to generate vanity address, see my post here with proof: https://bitcointalksearch.org/topic/m.27801341
• Code128B needs 330 bits to encode 30 chars, we have 380 bits, Code128B has START/END patterns which are 11 bits each and a CRC which is 11 bits. 380-11-11-11=347 . Next, 347-17 = 330

3) Bacon26 encoded string #1

• the height stream can be decoded with quite straight-forward logic to "THEFM?AURISKEYFILE" message
• bit granularity of other streams suggest similar content

4) Bacon26 encoded string #2

• The 011 bits in the height stream can be an artifact of 6-bit encoding of 5-bit-based Bacon26 string
• If we encoded some string with Bacon26 and extended each encoded character to 6 bits, 6th bit would be always null. Next, if we XOR the resulting stream with 011010, the every-other bit of the key would match 011, like (0)1(1)0(1)0
• 1flamen6, 1 bit in 6... is extra

5) Yari Shogi

• Chess pieces, however irrelevant for Yari Shogi (it uses flat ones), the names are relevant, it does have Knight and a Bishop
• The board is 7x9
• Arguably, the 011010 pattern can be read as 1A, or A1, which in some notation might match key/lock location on the board

6) Poem

• The Shakespeare's Poem tells a story about the Dove & Phoenix, saying they merge into one, also that their hearts are on fire (the flames) and that for them to be together, there must be no gap between them
• If you disregard flame pairs that have gaps in-between, you'll be left with 63 pairs, same as number of board tiles

7) Internal patterns

• The flames themselves have internal patterns like my earlier post explored. Starting point, 7 bits taken from all 3 streams, put together exist in the inner color stream AND contains the 011010 pattern on 8th bit in each track AND in the 7*3 stream as well.
• The Poem mentioned Phoenix and the Dove merging into one. Dove's tail encodes 1000 and Phoenix spikes 11110, together, with added '0' in-between, it results in 10 bit pattern 1000011110 which exists in all 3 streams. That being said, statistically only 7 bit patterns should exists in triplet of 63+139+139 bits (76-13, 152-13).
• If you remove 7 bits "codec" and the 011010 "key" from the beginning of the Heights stream, you'll be left with 63 bits
• The "codec" bits in the inner color stream are mirrored at bit 0 ("0" might refer to the Bishop's bottom that looks like a zero and seems to be a mirror/transparent), it goes like this: 00001(0)01101(1)11010(0)10111(1)11001(1)00100   (0)   11100(1)11010(1)01100(0)01101(1)11110(0)01011
• There are 17 bits repeated in inner and outer color stream, in mirrored setup
• There is also a possibility of ECC code being implemented, because if you disregard the 011 bits, and read all 3 streams flame by flame, then flame that carries 3 bits is data, and flame with 2 bits (where you removed one of the 011) encodes number of bits from the data, here is my post about it: https://bitcointalksearch.org/topic/m.26676467

8) Extra stream?

• The flames might also encode an additional 152 bits in their internal color "fat" or "skinny" look
• I've asked some friends to "decode" that track on their own, without checking my data, and it turns out about 14 of "bits" is "up to interpretation".
• Here is the dump, commonly mismatched bits are marked as "2":

9) Leaves

• There's 17 of them - is the number it self a clue?
• Some leaves point toward certain flames, some point into a gap between them, some take space on the 7x9 board
• Do they instruct where to "cut" the streams?

As you see, there are many "starting" points to begin with. And they ALL have some Pros and Cons, and yet, cannot be completely ruled out. Why? Cause we don't even know what we are looking for! It can be WIF 304 bits, WIF 296, Plain 256bits, Minikey 30 chars, Minikey 22 chars. Then, all of these can be encoded using either direct binary encoding, QR (with some mask and zigzag), Base58, Base64, Bacon26, Code128B (and other barcode formats), Morse, DNA, etc..

What I'm trying to say is, the Authors underestimated the number of valid permutations all the clues give for us, and given the ambiguity if the puzzle it self, It can be very well unsolvable without an intervention.

I do not agree with you regarding the blob data. The argument that it is less random - well, look at the height data. You are happy to remove every second bit to make it more random, but the truth is that it is very regular to begin with.

Also, the color channels are very much correlated with other channels, including height, including the regular pattern bits. For instance, red and long or yellow and short coexist in 103 cases out of 152. 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. Every segment order, every interpretation of color as 0/1, skipping every Nth bit - all those would result in perfectly probable (but incorrect, of course) private keys. It is those peculiar regularities that you discover in the cyphertext that allow you to eventually break it.

They seemed ambiguous to me at first too. I found that looking at how she painted the typical fat/skinny flames, you'll notice qualities in the more ambiguous ones that make them easy to categorise.

Welcome to the forum. Nice of you to make an account just to post that. Nobody needs a "right" to make a comment on a public forum. If you read my post, my conclusion didn't stem from my own frustration with the puzzle, but from a reasoned list of arguments. You're certainly entitled to disagree with that reasoning, that is your prerogative.

Sorry, have to disagree here. Just because you guys are salty you’ve spent loads of time on the flames and found nothing doesn’t give you the right to diss the authors here. It will go to the person who is able to solve it, due to their way of thinking.

There are several places that are not 100% readable, some users read those as skinny, some as fat - this doesnt happen w/colors or heights.

This is enough to discredit the entire idea.

I agree, the skinny/fat "blob" track does not follow the format AND seems to have a lot lower entropy, so it could be a text or an "AND" mask (given a lot of '111' occurrences). In the analysis above I ignore that track as it's not a solid/reliable data source.

Skinny/Fat Pros:

• Paint-style-wise, some flames seem to have inner color intentionally "painted over" to achieve "skinny" look
• 0/1 ratio seems to be 50%/50%

Skinny/Fat Cons:

• There are around 14 places that are not 100% readable, some users read those as skinny, some as fat - this doesnt happen w/colors or heights.
• They do not follow the format of other tracks
• They have lower entropy (less "random" data), they might be a  text track.

Moreover, the pattern as described in the analysis, where first 7 bits of 3 tracks build a pattern that later fully appears in one of the tracks, has only 0,03% chance of happening at random. Now, on top of that add the fact that following 6 bits in each track are the same AND they are actual 011010 ribbon pattern AND the fact that "connector" bits also are (0)(1)(1)(0)(1)(0), you get a chance of around 0,00004%. I don't want to bother calculating a chance of same thing but with 4th piece added (like in the "guesswork" steps).

We didn't "just look" at the bits, we carefully calculated chances of those things to happen, and they are crazily low, and yet, the pattern/logic is visible with naked eye without any computation at all.

There's absolutely no evidence that the width of the inner flame is intentional and that it is a real data track. Even if it were valid data, it doesn't mean the above patterns are invalid. If you read crax0r's analysis, he found that these patterns don't necessarily start at the beginning of the data tracks, so that could still be consistent with the "blob" data. (Even though I'm on the fence as to weather or not that's real data.)

What blob? The sequences that I pasted are 76+152+152 bits, there are no other flame-bits after removal of 011 pattern...

well, what can I say? If your point was to show that if you mess with the data long enough then you will always find something and it is not possible to tell the real leads from garbage, then you are partly right, but ...

dude, you forgot to factor in blob

yes, it is my last comment to other member

But seriously, if you factored in blob, you would immediately see that your "regularities" fail because for blob the sequence starting at the 8th bit is 000110 and thus it invalidates the first step of your analysis.

Definitely! Well as for me it looks like simple to see this puzzle but somehow it feels its difficult to solve it. Oh, maybe im not good at looking into this art yet this is impressive.
 

Yes, I really think that's the case. It's actually very difficult to design a puzzle that is challenging yet solvable. One has to take great care to ensure the solution is achievable without the benefit of having the solution to begin with.

With mistakes being made in previous puzzles, I think it's clear that the author is not very rigorous in their design. Further, at the time this puzzle was made it was worth a lot less, so there was much less incentive to do it properly. The fact that the prize money was once worth $100K USD is also a good indication that this may be unsolvable. Look at all the crazy solutions to other ARG's that are worth only a couple hundred bucks. You could imagine those solvers, as well as many more would be attracted to the larger prize of this puzzle. Lots of very brilliant people have worked on this and still nobody has even a confirmed first step.

From the authors perspective I'm sure it seems simple, but to those without the benefit of knowing the solution, it might not be solvable. This is basically the definition of hindsight bias.

Troll BS aside, here is some realnew research:

First of all, I think there are several "keys" involved here.

Some legend:

Analysis:

Step #1 - Group 3 streams line by line, separate by 7, 6, and the remaining bits, notice the "011010" Ribbon "key" is after 7th bit in each stream:

Step #2 - Mark 1st and 7th bit:

Step #3 - Re-order the streams so 1st bit matches 011 pattern (wild guess):

Step #4 - Merge first 7 bits of each stream into one pattern:

Step #5 - Find that pattern:

Mind blown? There's more...

Step #6 - Extend the pattern following the same logic, to see if there is anything extra there:

Step #7 - Guesswork#1:

Step #8 - Guesswork#2:

Step #9 - Guesswork#3:

Now, last 3 steps I marked as "guesswork" as these might be purely coincidental. Chances for re-occurrence of the 3 patterns I was looking for, followed by 011010 in a random stream of (152-13) bits is around 0.2%, so coincidence is not probable but is not "impossible".

Step #10 - Internal patterns


Now, the remaining data can be cut/shuffled around, codec part can be removed or the first 7bits removed instead (cause in real data there should be no duplicates). All of that makes SH1TTONS of possibilities of getting 304, 296 or 256bits. In fact, about 5-60 billion.

Let's face it, the authors underestimated difficulty of making a hard & solvable puzzle. Like OnTheMF said once, it's hard to make a puzzle that is complicated&solvable, but easy to make a complicated&unsolvable one. This is the latter case I'm afraid.

The authors simply did not consider the other "view points" on the data they presented us with. To them, it might look like a straight forward case A->B->C, while in reality its more like a tree, or better, a forest, where each tree has million branches. Each one logarithmically increasing possible&probable ways of solving it. IMHO, The Authors should come forward and give some solid clue or at least "burn" the bad leads. Until then, it's a waste of time & I'm out.

You have an IRC channel up in this page.