I'm a bit late to the party but done some experiements with the flames on the border.
The datasets provided by other users seem to be consistent with a number of 152 flames. But no one knows in which order or direction you have to read them.
So what I did is the hard way: I wrote a little script, which tries every possible combination you can read the flames in.
The dataset I used is:
outer_top_left_to_right = "001101100111001101"
outer_right_top_to_bottom = "001111000101"
outer_bottom_right_to_left = "0011111011010001"
outer_left_bottom_to_top = "01101101"
inner_top_left_to_right = "0110110110100010110110110011"
inner_right_top_to_bottom = "110111110110110111110010"
inner_bottom_right_to_left = "100011100010110111110111110111110"
inner_left_bottom_to_top = "0111001101101"
Of course I tried them forwards and backwards, so I don't miss the right combination.
What I did than, is use the binary strings (152 bit long each) and parse them to ASCII. So I got lots of strings (around 200 MB as a txt file with 10339728 lines)
(...)
You seem to be forgetting that the pattern of 0 1 1 is VERY consistent across the flame-bits.
If you read the flames from inner top, right, bottom, left then at the top of the left go to outer and read down left, then bottom, right, and the top, you would end up right above the point where you started reading from.
(PS. You can also start from outer top and end in inner top, pattern 0 1 1 also prevails.)
(PPS. If you look at the 0 1 1 pattern, then the only safe-transition from inner to outer is on left-side's top.)
Now, if you read every even-numbered flame-length in that stream (first flame is flame-0, lets index from 0), you will get repeated pattern of 0 1 1. Since it's repeated then:
A) it cannot encode any data or
B) we should read by skipping some colors, only then such lengths can encode some data. For example, if we read only 78 of the outer-red-colored flames, we still could treat inner color as a bit of data and flame height as a bit of data, regardless if its a part of 011 pattern or not.
Lets focus on:
A) So, if we assume pattern 0 1 1 is there to guide us where to start and end, lets take Inner-top as a starting point.
It starts with short-length flame number 0, so its a pattern-bit-0, that flame still has 2 color-bits, the next flame is uneven, so we take full 3 bits out of it, then the third flame is even again, its long, so its pattern-bit-1, 2 bits again, next flame is uneven again, so 3 bits etc etc.
So, from
152 flames, we get
76 flames that encode
1 bit of
011 pattern and
2 bits of data AND
76 flames that encode full
3 bits. That's 76*2+76*3=380 bits.
It's basically a very solid proof that you can only read the bits in general 2 ways:
1) inner top to outer top (all around the painting as described above)
2) outer top to inner top (all around the painting as described above)
On top of that, since you have 3 data-types, you can choose to read them:
1) In pairs of 2 flames, so 76 * (2+3) bits
2) SplitA: even flames first, 76*2 then uneven ones, 76*3
3) 6 permutations on how to order the data-types in 3bit-flames: height=H, innerColor=I, outerColor=O, then HIO, HOI, OIH, OHI, IHO, IOH
2 permutations on how to order the data-types in 2bit-flames: innerColor=I, outerColor=O, then IO, OI
In total: 12 permutations
4) Read each data-type separately, then combine using 6 permutations listed above. So we first make stream of 76bits of Heights, then stream of 152 bits of InnerColor, then 152bits of OuterColor
5) Possibly, 2 out of 5 bits have to be combined into 1 (like Phoenix and the Dove), making it 1+3 bits of data. I like this one cause 76*4=304, an exact length of a WIF-compressed private key.
6) All the 380bits, read in one of many possible "ways" listed above can be:
a) WIF key (296/304 bits)
b) base64 key (44*6bits)
c) pure 32byte long priv key (256bits)
c) QR 25x25 raw data (skipping statics, to encode 32 bytes in binary mode you need QR Version2, with L-Level ECC == 389bits, missing 9 bits from the rabbits hat? ribbons?)
For example:
rs32 389 01101001000111010101111011111000010000101011110001111000101000001101100010101101001010000101001100000101111000011000000010001111110111001010010100000111010001110111110001111000110110100110001000010000101001110110001101100100111010111001111000001101000001001001011001101101011101110001110101001011100110000011100101110111001110000000000110110101100000101110110111010101001001010100010100111
██████████████ ████ ██ ██ ██████████████
██ ██ ██████ ██ ██ ██ ██
██ ██████ ██ ████████ ██████ ██ ██████ ██
██ ██████ ██ ████ ██ ██ ██████ ██
██ ██████ ██ ██ ██ ██████ ██ ██████ ██
██ ██ ██ ████████ ██ ██
██████████████ ██ ██ ██ ██ ██ ██████████████
██ ██
████ ██████ ██ ██ ████ ██ ██ ██
██ ██ ████ ██ ████████
████ ██ ██ ████████████ ██████
██ ██ ██ ██ ██████ ██ ████
██ ████████████ ████████ ████ ████ ██
████ ██ ██ ██ ██ ████
██ ████ ██ ████ ████ ██ ██████ ██ ██
████ ████ ████ ████ ██ ██
██ ██ ██████ ████ ██████████████ ██ ██
██████ ██████ ██ ██ ████
██████████████ ██ ██ ██ ████ ██ ██ ██████
██ ██ ████ ██ ██ ██████
██ ██████ ██ ██ ██████ ████████████████
██ ██████ ██ ██████ ████
██ ██████ ██ ████ ██ ████ ██ ██████
██ ██ ████ ██████ ██ ██ ██ ██
██████████████ ██ ██ ██ ██ ██ ██████
389
6022d55444dc4f15f3a4306fb979b49a2bf66488a594ab7f806aab278b0e83804ed197
d) some Bacon-Ciphered text
e) ascii url
Bonus, funnily, if you read 18 flames from inner top, skipping the flame-0 (which might be there to "tell" us what zero-values are: short, blue, yellow), then you get:
101 (2) 5 10 (2)
000 (0) 0 00 (0)
110 (2) 6 10 (2)
110 (2) 6 10 (2)
001 (1) 1 01 (1)
001 (1) 1 01 (1)
000 (0) 0 00 (0)
010 (1) 2 01 (1)
110 (2) 6 10 (2)
Format is: databits (1-bitcount) datavalue sumbits (sumvalue)
Note: databits were masked with 011
As you see, by some strange coincidence, the first 9-pairs (so 18 flames) that encode 3+2 bits are somehow connected via this logic. I said it's funny cause im 99% sure its just a coincidence (chance is 1:4^9 so 1 in 262144) (unless Coin_Artist can tip otherwise).