Quote from: alphabetacanary on December 03, 2015, 03:41:02 AM

An observation:

Traverse the flames in this order:

outer top, outer right, outer bottom, outer left
inner left, inner bottom, inner right, inner top

If you number the flames starting at 1, then every even numbered flame's length produces this consistent pattern all around the image:

0 1 1 0 1 1 0 1 1 0 1 1 .... (short = 0, tall = 1)

The 011 pattern repeats 25 times but only for the lengths.

The odd lengths (the bits between the 011 pattern) seem random and all color bits seem random too.

So the information encoded in the lengths cannot possibly be part of a private key (at least not the even numbered ones).

This suggests to me that the bits of the private key have been interleaved in the inner/outer colors of the flames. Perhaps the pattern is there to indicate how to rearrange the bits back into order?

Also note that if you take the first 6 lengths of the outer top in this
order:

2 4 6 1 3 5

You get: 0 1 1 0 1 0

Which is the same pattern we see in the lengths of the 6 ribbons in the image. (2 4 6 5 3 1 would also work) In fact, the ribbon pattern also has the 0 1 1 pattern for it's even numbered ribbons.

This suggests a length of 6 is significant.

I count 456 bits of information in total (98 inner flames + 54 outer flames each flame carrying 3 bits of information : length, outer color, inner color)

But 456 bits is much more than is needed for a private key. You need either:

1) 256 bits for a raw key; or

2) 296 bits for a wallet import formatted key (uncompressed); or

3) 304 bits for a wallet import formatted key (compressed)

If we omit the pattern which we know can't be part of the private key, that leaves 380 bits. However, the color encoding part contains 304 bits which is just enough to encode 38 bytes (the right number for an compressed wallet import formatted key).

My guess is the lengths are there to show how to un-jumble the color bits back into place.

I think what you found is the very first real lead.
I looked again and found your pattern albeit with ONE error which is marked:

Code:

Flame Length. Direction of reading: >v<^

Outer Top (>)
001101100111001101
0 1 1 0 1 1 0 1 1

Outer Right (v)
0011110001
0 1 1 0 1

Outer Bottom (<)
0011111011010001
0 1 1 0 1 1 0 1

^ here is the error in the sequence. It should be a 1 first to continue the pattern from Outer Right

Outer Left (^)
01101101
1 0 1 1

Inner Left (v)
1011011001110
0 1 1 0 1 1

Inner Bottom (>)
011111011111011111011010001110001
0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1

Inner Right (^)
010011111011011011111011
1 0 1 1 0 1 1 0 1 1 0 1

Inner Top (<)
1100110110110100010110110110
1 0 1 1 0 1 1 0 1 1 0 1 1 0

How did you discover the order in which you read the sides?

Note, that you can read the whole pattern from hehind (of course)

PS: As a checksum: I counted 150 flames. Does this match with your findings alphabetacanary?
We might want to abstract the whole image, having only flames, length and color in the image so we dont start deciding if something is a flame or not over and over again