The Legend of Satoshi Nakamato, FINAL STEP PUBLISHED.... 4.87 BTC GRAND PRIZE!

[Pan Troglodytes]

Troll BS aside, here is some real research(...)

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.

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.)

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.

[1715533733]

1715533733

[1715533733]

1715533733

[1715533733]

1715533733

[1715533733]

1715533733

[crax0r]

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.

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://bitcointalk.org/index.php?topic=766000.msg27801341#msg27801341
• 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://bitcointalk.org/index.php?topic=766000.msg26676467#msg26676467

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":

Code:

10110011110011100010100010100011110001110010100011102211000000111001100111011100101112100110210010110011100212020110100012200202001011000100120211000021

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.

[Pan Troglodytes]

Skinny/Fat Cons:

• 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.

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.

I ran a simulation in R, drawing 25-tuples from 64 pool with repeats, and out of a milion runs only 4544 had 16 or less unique values. So call it what you will, it is an anomaly to me - anomaly at worst, but human creation hopefully

[crax0r]

Skinny/Fat Cons:

• 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.

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.

I ran a simulation in R, drawing 25-tuples from 64 pool with repeats, and out of a milion runs only 4544 had 16 or less unique values. So call it what you will, it is an anomaly to me - anomaly at worst, but human creation hopefully

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.

[crax0r]

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.

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.

[Pan Troglodytes]

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.

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).

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.

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.

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.

[crax0r]

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.

[crax0r]

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.

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.

[Pan Troglodytes]

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.

No
I am saying that if red and yellow arrive randomly, and you match it against the mixed fixed&random pattern of long and short, then (if red and yellow arrive randomly - remember) you will have the random number of matches. By "match" I consider matching red with long and yellow with short (red=long=1, yellow=short=0). But you have 103 matches out of 152. It is not random, or rather: not probable if randomity is assumed

[Pan Troglodytes]

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.

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).

That I am not getting. Can you please explain? It seems to me that if we allow every 6th bit be 0 and the rest 5 bits are (more or less) random, and you xor them all against a 6 bit word 011010 in a loop, then only 6th bits are consistently impacted and fixed, and the rest of more or less random bits remain more or less random. The pattern 0x1x1x, however, is very consistent and it involves every 2nd bit, not every 6th.
EDIT: on second thought, you are absolutely right and I was wrong. I am getting it now . No further explanation is necessary. You are simply using colors as the remainder 4 bits.
EDIT2: But if you factor in blob, that is invalidated, again
 

[bug.lady]

(...)
3) Bacon26 encoded string #1
(...)

It has been rumoured  on the forum many times it may be bacon cyphre. It seems to have been indicated by Coin Artist, allegedly in a tweet, that it is bacon. Does anyone have any source of that information, or a link to that tweet of hers? For now, it seems more like a rumour to me.

[crax0r]

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.

No
I am saying that if red and yellow arrive randomly, and you match it against the mixed fixed&random pattern of long and short, then (if red and short arrive randomly - remember) you will have the random number of matches. By "match" I consider matching red with long and yellow with short (red=long=1, yellow=short=0). But you have 103 matches out of 152. It is not random, or rather: not probable if randomity is assumed

Okay I see what you mean, yes, if we combine the chances of both red==long==1 and yellow==short==0, then of course at random it should be 50%/50%, so close to 76/152.

Here is a quick&lame function in python that tests it out:

Code:

def testMatchesRnd(usePattern=False, sampleSize=10000):
    totalCount = 0
    pattern = "011"*100
    for x in range(0, sampleSize):
        rndA = ""
        if usePattern:
            bits = getRandomBits(76)
            for i in range(0, 76):
                rndA += pattern[i] + bits[i]
        else:
            rndA = getRandomBits(152)
        rndB = getRandomBits(152)
        for i in range(0, 152):
            if rndA[i] == rndB[i]:
                totalCount += 1
    return (float(totalCount)/float(sampleSize))

def testMatchesFlames(trackA, trackB):
    totalCount = 0
    dataA = dataBuilder("abcdEFGH", trackA)
    dataB = dataBuilder("abcdEFGH", trackB)
    for i in range(0, 152):
        if dataA[i] == dataB[i]:
            totalCount += 1
    return (float(totalCount))

print testMatchesRnd(False), testMatchesRnd(True) 
print testMatchesFlames(0, 1), testMatchesFlames(0, 2), testMatchesFlames(1, 2) #0=Heights,1=Outer,2=Inner

>> 76.0035  75.9582
>> 103.0  74.0  69.0 

[Pan Troglodytes]

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.

No
I am saying that if red and yellow arrive randomly, and you match it against the mixed fixed&random pattern of long and short, then (if red and short arrive randomly - remember) you will have the random number of matches. By "match" I consider matching red with long and yellow with short (red=long=1, yellow=short=0). But you have 103 matches out of 152. It is not random, or rather: not probable if randomity is assumed

Okay I see what you mean, yes, if we combine the chances of both red==long==1 and yellow==short==0, then of course at random it should be 50%/50%, so close to 76/152.

Here is a quick&lame function in python that tests it out:

Code:

def testMatchesRnd(usePattern=False, sampleSize=10000):
    totalCount = 0
    pattern = "011"*100
    for x in range(0, sampleSize):
        rndA = ""
        if usePattern:
            bits = getRandomBits(76)
            for i in range(0, 76):
                rndA += pattern[i] + bits[i]
        else:
            rndA = getRandomBits(152)
        rndB = getRandomBits(152)
        for i in range(0, 152):
            if rndA[i] == rndB[i]:
                totalCount += 1
    return (float(totalCount)/float(sampleSize))

def testMatchesFlames(trackA, trackB):
    totalCount = 0
    dataA = dataBuilder("abcdEFGH", trackA)
    dataB = dataBuilder("abcdEFGH", trackB)
    for i in range(0, 152):
        if dataA[i] == dataB[i]:
            totalCount += 1
    return (float(totalCount))

print testMatchesRnd(False), testMatchesRnd(True) 
print testMatchesFlames(0, 1), testMatchesFlames(0, 2), testMatchesFlames(1, 2) #0=Heights,1=Outer,2=Inner

>> 76.0035  75.9582
>> 103.0  74.0  69.0 

thanks I cannot currently run any simulations as I have no access to my R computer at the moment, but would you be so kind and check what are the chances of getting 103 or more matches by random? I would assume, quite low. Or I'll do it in the evening and post

[crax0r]

Code:

def testMatchesRndLimited(usePattern=False, sampleSize=1000000, limit=103):
    totalCount = 0
    pattern = "011"*100
    for x in range(0, sampleSize):
        rndA = ""
        if usePattern:
            bits = getRandomBits(76)
            for i in range(0, 76):
                rndA += pattern[i] + bits[i]
        else:
            rndA = getRandomBits(152)
        rndB = getRandomBits(152)

        count = 0
        for i in range(0, 152):
            if rndA[i] == rndB[i]:
                count += 1
        
        if count >= limit:
            print count
            totalCount += 1
    return (float(totalCount)/float(sampleSize))*100

print testMatchesRndLimited(False), "%"
>>> 0.0009 %

Edit: Bigger "sampleSize" shows 0.00068% chance. This is VERY unusual I agree. This might indicate the Outer-flame-bits are the highest bits in the Bacon26 char-bits (5), where we can find anomalous deviance towards more 0's than 1's (because Bacon26 encodes 26 chars using 5 bits, while 5 bits encode values up to 32, hence values 27-32 will never be encoded and those use mostly 1's). With this in mind, more NULLs in plain stream would indicate more bits would "leak" from the XOR 011010 key to the underlying data, hence Outer and Heights might share more bits cause underlying data in both had more NULLs.

[Pan Troglodytes]

Code:

>>> 0.0009 %

thank you. Did I convince you in the slightest that the color data is full of regularities as well, even if they are not as apparent as the height data? And that the existence of regularities in blob does not discredit that data stream, either?

[crax0r]

These are the matched bits:

Code:

    
Key: 01101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001
H+O: 0____101_010____110_101100____0_1_11__1_1_0_111100_010_0111000__110__1_1_1111101_11100111_01_0110_101_01101_001___01111_001__0001_11_0101100_11_011____0 
H+I: 011_____1___0__0___11___0___1_0___1_011011_1_1___01_1_____1_0010___11__1_1_1_1011___0_1_1__11___01__1__1101000_0__0_1__1__10_000_1_1_010_1001_1_01___1__  
I+O: 0__10________10_____1___0_00_000_01___1_1____1___0__1_1___1_00________0111_1_101____0_1_11_1____0___10_1101_00__000_1_____1_0000___11010_100__1101_10_1_  

[Pan Troglodytes]

These are the matched bits:

Code:

    
Key: 01101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001101001
H+O: 0____101_010____110_101100____0_1_11__1_1_0_111100_010_0111000__110__1_1_1111101_11100111_01_0110_101_01101_001___01111_001__0001_11_0101100_11_011____0  (KeyMatched: 111.0)
H+I: 011_____1___0__0___11___0___1_0___1_011011_1_1___01_1_____1_0010___11__1_1_1_1011___0_1_1__11___01__1__1101000_0__0_1__1__10_000_1_1_010_1001_1_01___1__  (KeyMatched: 82.0)
I+O: 0__10________10_____1___0_00_000_01___1_1____1___0__1_1___1_00________0111_1_101____0_1_11_1____0___10_1101_00__000_1_____1_0000___11010_100__1101_10_1_  (KeyMatched: 83.0)

Yes, but it is not all. Just a reminder, because it was a result by some other Member earlier in a thread:
if you write the inner color track backwards, and you match it against the outer color (forward), all first 17 bits in both streams match. All together, 85 bits match, so the rest may be considered just random (the rest shows 68 matches for 135 bits - just random).
Also, there is an almost perfect match of blob bits against the length bits in two segments. But not in the other segments.

Those kind of results are interesting to me and I am sure when we know the solution it will be very clear why they are there. For now, we must work backwards - from regularities we must try to understand what was actually done in the way of artistic creation.
EDIT: now I am reading in your post that you are aware of those 17 bits. But just a comment from my side: maybe 17 is not intentional. It may have been that a match is by intention in 16 or 15, and 1 or two are just random.

[crax0r]

Another interesting insight, if we take 2 random streams, and XOR them with 011010, bit ratio in the similarities of 0/1 is as follows:

Code:

H+O: ('01_0011__1_0_0____01_0111100_00_0___110_00____00____1__11__0_______11__0____1_____1__01_1001_1_010_01_1000101__1_00111____1__100___0_10___1_10_1_10_11_1', 'Matched 78', '0/1 ratio 37/41')
H+I: ('_0_0_1_01_0_1____1_10__1__0___001_____1001__0___011_10___0111_1_110_101__1_0___1___00__01_0010___10_1_____1_____100_01_010___1__101_1100101_101__0___101', 'Matched 77', '0/1 ratio 36/41')
I+O: ('_10__01__10___0__0_011___111_00110___001_11_10__00__01001__00_0__11_01_01_0_0__1_1__10___0101_1_00_10___1___01_____00___1__0___1_10000__1___11___1_100__', 'Matched 77', '0/1 ratio 40/37')

However, in our data streams it's:

Code:

H+O: ('0____100_000____010_000101____0_0_01__0_0_0_010101_000_1010001__010__1_1_0010100_10101010_00_0010_000_00000_010___00010_010__0010_01_1000101_10_000____1', 'Matched 103', '0/1 ratio 72/31')
H+I: ('000_____0___0__0___00___0___0_0___0_000001_0_1___10_0_____0_0100___00__1_0_1_1000___0_0_0__00___00__0__0000001_0__0_0__1__00_001_1_1_100_1010_0_00___1__', 'Matched 74', '0/1 ratio 58/16')
I+O: ('0__11________01_____0___0_10_001_00___0_0____1___1__0_1___0_01________1110_1_100____0_0_01_0____0___00_0000_01__100_0_____0_1001___11100_101__0100_11_1_', 'Matched 69', '0/1 ratio 41/28')

As you see, in randoms, the ratio is close to 50/50, while in flame-streams is deviating towards more 0's after XORing with a key 011010, which it self has a 50/50 0/1 ratio.

Edit: for the reference, here are flame-bits without XORing:

Code:

H+O: ('0____101_010____110_101100____0_1_11__1_1_0_111100_010_0111000__110__1_1_1111101_11100111_01_0110_101_01101_001___01111_001__0001_11_0101100_11_011____0', 103, '0/1 ratio 42/61')
H+I: ('011_____1___0__0___11___0___1_0___1_011011_1_1___01_1_____1_0010___11__1_1_1_1011___0_1_1__11___01__1__1101000_0__0_1__1__10_000_1_1_010_1001_1_01___1__', 74, '0/1 ratio 29/45')
I+O: ('0__10________10_____1___0_00_000_01___1_1____1___0__1_1___1_00________0111_1_101____0_1_11_1____0___10_1101_00__000_1_____1_0000___11010_100__1101_10_1_', 69, '0/1 ratio 34/35')

They show a slight bias towards more '1's. Either way, the first example (with randoms) shows that XORing by 0/1 regular key like 011010 should not change the 0/1 ratio, while in flame-bits it does, quite a lot.

Edit: I guess those dumps are a bit confusing, line by line these are similarity-matches against different track. Updated the code blocks. The "Matched" entry indicates how many bits same on both streams.

[Pan Troglodytes]

Another interesting insight, if we take 2 random streams, and XOR them with 011010, bit ratio in the similarities of 0/1 is as follows(...)

Those are very interesting insights. Could you please edit your post and add some labels naming the datastreams? it would greatly help. Thanks!

EDIT: thank you for doing it

[itod]

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

Sorry to pick this only from the whole analysis, but i'm 99,99% sure this chess piece is not a Bishop. Played on hundreds of chess-sets in my life, not a single one had a Bishop that resembles to piece that is painted. Also played on many chess-sets that had Queen exactly like that. It's a bit non-standard look of the Queen piece, nevertheless some luxury sets have Queen with the collar like that. Bishop is always rounded in that area.

This is important because if that Queen-Knight (Elisabeth and her lover) allegory is true as some suggest, this board may have nothing to do with the chess board and Yari Shogi, it is just used as a mask for real meaning of what is painted. It further implicates if that is not a chess or Yari Shogi board, it gives fuel to the observations that vines and leaves always start in the cracks, between the fields in the board, and that center of the keyhole is exactly in the crack. If it is not a chess board maybe it should be read completely different. That's why it is important that the piece is not a Bishop. A little blasphemy for the end: let's just assume for a second there is 1% chance that rabbit character is not complete troll (I know, hard to believe, but let's give it 1% chance he knows something). In that case his hint with Michael Jackson's YouTube clip - "It don't matter if you're black or white" maybe means it doesn't matter if the fields on the board are black or white because it is not a chess board.