 Show Posts
|
|
Pages: [1] 2 »
|
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: https://bitcointalk.org/index.php?topic=766000.msg26795620#msg26795620Like 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. |
|
|
|
sorry, i just have to say. we are still hung up on this? jeez you guys. you link to some random comment i made that a minikey SEEMS LESS LIKELY, and that I was unaware of a vanitygen that comes STOCK with a minikey mining mode. for a bunch of pedantic nerds you are absolutely terrible at being pedantic. SEEMS LESS LIKELY is not even remotely the same as saying "impossible." obviously. clearly. self-evidently. and asking if there is anything that comes STOCK with such functionality is, again obviously, clearly, self-evidently a way of saying YES IT IS CLEARLY POSSIBLE. that is to say, put in a different way, CLEARLY I WAS NOT SAYING IT IS IMPOSSIBLE. put yet another way, if you were buying a car and you asked if it comes stock with a fat sound system, you would not be asking "do fat sound systems exist" or "is it possible for fat sound systems to exist anywhere in time and space," you would clearly be asking simply if it typically comes with it as-is. for even yet further clarification, i in fact am writing my own vanitygen as a fun little programming exercise, including minikey mining because why not. allow me to demonstrate how to do pedantry better: ped·ant·ry /ˈped(ə)ntrē/ excessive concern with minor details seem /sēm/ used to make a statement or description of one's thoughts, feelings, or actions less assertive or forceful. like·ly /ˈlīklē/ such as well might happen or be true; probable. stock /stäk/ of the common or ordinary type; in common use and to top it off you then even link to you demonstrating a "PROOF" that it is possible... lol. i now await a full peer-reviewed mathematical proof on the matter. when can we expect it? which journal will it appear in? LOL dude chill, my post had nothing to do with you. Like captainnoob said, I was merely mentioning that this research was done and that it cannot be ruled out (30char minikey resulting in public vanitized address). Key point of the post was to prove that there are MANY ways to look at the puzzle which the Authors likely did not consider. These points may very likely render the entire puzzle unsolvable. |
|
|
|
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: 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: 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: 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. |
|
|
|
These are the matched bits:
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_
|
|
|
|
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. |
|
|
|
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: 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 |
|
|
|
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. |
|
|
|
|
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.
|
|
|
|
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. |
|
|
|
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. |
|
|
|
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":
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. |
|
|
|
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. |
|
|
|
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. What blob? The sequences that I pasted are 76+152+152 bits, there are no other flame-bits after removal of 011 pattern... |
|
|
|
Troll BS aside, here is some realnew research: First of all, I think there are several "keys" involved here. 011010 - Ribbons. Ribbons are cut and ordered, perhaps they indicate something will have to be cut and shuffled around.
011 - Bishop melting points. Melting points "melt away", perhaps indicating 011 will have to be removed.
11110 - Phoenix spikes. Connected via branch with the Dove or into a left/top leaf. Might indicate Dove connection or data insertion at leaf place.
1000 - Dove's "tails". Might indicate data insertion between the leaves or connection with 11110 bits from Phoenix.
Some legend: H: Height flames bits, with 011 even bits REMOVED ("melted away"), not XORed out
I: Inner color bits
O: Outer color bitsAnalysis: 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: H: 1011000 011010 111111011110000100011111111110101011011000011110000110010101010
I: 0111001 011010 1000011110001001000001001101111010010111111001100100011100111010101100001101111110001011011101000000000100111100000010110100100101101010111
O: 1110101 011010 0100011010011111111010001000111000011110101000111100011101000000010100011000010110011010110010011001110000111001111010001010011100010001101
Step #2 - Mark 1st and 7th bit: H: (1)01100(0) 011010 111111011110000100011111111110101011011000011110000110010101010
I: (0)11100(1) 011010 1000011110001001000001001101111010010111111001100100011100111010101100001101111110001011011101000000000100111100000010110100100101101010111
O: (1)11010(1) 011010 0100011010011111111010001000111000011110101000111100011101000000010100011000010110011010110010011001110000111001111010001010011100010001101
Step #3 - Re-order the streams so 1st bit matches 011 pattern (wild guess): I: (0)11100(1) 011010 1000011110001001000001001101111010010111111001100100011100111010101100001101111110001011011101000000000100111100000010110100100101101010111
O: (1)11010(1) 011010 0100011010011111111010001000111000011110101000111100011101000000010100011000010110011010110010011001110000111001111010001010011100010001101
H: (1)01100(0) 011010 111111011110000100011111111110101011011000011110000110010101010
Step #4 - Merge first 7 bits of each stream into one pattern: Codec: (0)11100(1) + (1)11010(1) + (1)01100(0) => merge "connector" bits => (0)11100(1)11010(1)01100(0) => 0111001110101011000
Step #5 - Find that pattern: [found here###############]
I: (0)11100(1) 011010 1000011110001001000001001101111010010111111001100100(0)11100(1)11010(1)01100(0)01101111110001011011101000000000100111100000010110100100101101010111
O: (1)11010(1) 011010 0100011010011111111010001000111000011110101000111100011101000000010100011000010110011010110010011001110000111001111010001010011100010001101
H: (1)01100(0) 011010 111111011110000100011111111110101011011000011110000110010101010
There's more... Step #6 - Extend the pattern following the same logic, to see if there is anything extra there: What if we extend it a little bit...
I: (0)11100(1) 011010 1000011110001001000001001101111010010111111001100100(0)11100(1)11010(1)01100(0)01101(1)11110(0)01011011101000000000100111100000010110100100101101010111
O: (1)11010(1) 011010 0100011010011111111010001000111000011110101000111100011101000000010100011000010110011010110010011001110000111001111010001010011100010001101
H: (1)01100(0) 011010 111111011110000100011111111110101011011000011110000110010101010
Ribbon key discovered: (0)xxxxx(1)xxxxx(1)xxxxx(0)xxxxx(1)xxxxx(0)xxxxx
Even more? There seems to be a reversed version of the key too: 010110:
I: (0)11100(1) 011010 1000(0)11110(0)01001(0)00001(0)01101(1)11010(0)10111(1)11001(1)00100(0)11100(1)11010(1)01100(0)01101(1)11110(0)01011011101000000000100111100000010110100100101101010111
making it 010110+011010, mirror? But with different data inside, like in Wonderland?
Step #7 - Guesswork#1: (0)11100(1) 011010 10000111...
(1)11010(1) 011010 01000110...
(1)01100(0) 011010 11111101...
(0)01101(1) missing
(1)11110(0) missing
(0)01011(0) missing
Step #8 - Guesswork#2: (0)01101(1) search for 0011011 -- found but without 011010 next to it...
(1)11110(0) search for 1111100 -- found but without 011010 next to it...
(0)01011(0) search for 0010110 -- found, WITH 011010 next to it!!! On the "O" stream:
O: (1)11010(1) 011010 010001101001111111101000100011100001111010100011110001110100000001010001100(0)01011(0)011010 110010011001110000111001111010001010011100010001101
Step #9 - Guesswork#3: (0)11100(1) 011010 10000111...
(1)11010(1) 011010 01000110...
(1)01100(0) 011010 11111101...
(0)01101(1) missing
(1)11110(0) missing
(0)01011(0) 011010 11001001...
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 There are two interesting internal patterns:
1) 1000011110 - exists in all 3 streams. Could be very likely a combination of Dove's tail bits and Phoenix spikes (1000 + 0? + 11110).
2) 0111010000000 - exists in the longer streams. Interestingly, if you remove the "codec line", then this pattern occurs at the same location in the "left-over" bits. Extra note, the "10000000" is 80 in hex, and happens twice, 2nd location could be interpreted as "00000001", making both re-occurrences useful for WIF key.
I: (0)11100(1) 011010 1000011110 001001000001001101111010010111111001100100 (0) 11100 (1) 11010 (1) 01100 (0) 01101 (1) 11110 (0) 01011 0111010000000 0010011110000001011010010 0101101010111
---------- -------------
O1: (1)11010(1) 011010 010001101001111111101000100011 1000011110 101000111100 0111010000000 1010001100
---------- -------------
H: (1)01100(0) 011010 11111101111000010001111111111010101101 1000011110 000110010101010
----------
O2: (0)01011(0) 011010 110010011001110000111001111010001010011100010001101
With "codec" removed:
I: (0)11100(1) 011010 1000011110 001001000001001101111010010111111001100100 0111010000000 0010011110000001011010010 0101101010111
---------- -------------
O1: (1)11010(1) 011010 010001101001111111101000100011 1000011110 101000111100 0111010000000 1010001100
---------- -------------
H: (1)01100(0) 011010 11111101111000010001111111111010101101 1000011110 000110010101010
----------
O2: (0)01011(0) 011010 110010011001110000111001111010001010011100010001101
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. |
|
|
|
"The biggest Troll of Satoshi Nakamoto. The fucking Step"
Seems that those creators and coin-troll mom killed the rabbit!
The only one that I am following and missing in this forum is the rabbit.
No rabbit No solution.
You are just waiting around hoping that someone gives you the answer. Exploring DNA/RNA codons is better then just whining for someone to give you the answer. In the interest of keeping my post about more then just engaging this nonsense.., I wanted to visually be able to see what flames were responsible for that "iskeyfile" pattern.., so I worked through it by hand and color coded the bits. Note: when I say Top/Top I am referring to the outside track of the top of the image, after it has been rotated 90 degrees cw (Portrait). https://imgur.com/a/DGGOgDon't feedo troll. |
|
|
|
for one thing it seems unlikely they would have mined minikeys for a vanity address...is there even vanity software that comes stock with that functionality?
Well, just because there is no off-the-shelf software to do something, doesn't mean its not doable: SUPER1FLAMEN6QPEGRLTFZXDEAFFAL -> 1FLANSqJppAGxWdCrUW2VsrncH1NfWtNXo
SUPER1FLAMEN6JQWSXAAHLJQJDEZXR -> 1FLArjwv7oPTZGUuGxLhEtPh7pkfoSbRTX
SUPER1FLAMEN6RHJSDXWSCEFMSBMWX -> 1FLA4LzZtRuaV914mEJHaWmBGdaMt2AmRG These are all valid mini-private keys that I vanitized in 2 minutes, on GPU it would be much faster... They are: - 30 chars long
- follow base58 charset
- follow code128b charset
|
|
|
|
We have 152x3=456 bits, 76 are nulls after xoring, that leaves as with 380 bits, then, we have a set of 17 bits doubled, perhaps a 2nd key, making yet another 17 bits nullified, that's 380-17=363. What is 363? Well, Code-128-B, that can encode Base58 and Minikeys uses START code and END code, which are 11 bits each, also uses CRC code, also 11 bits, that's 363-11-11-11, so 330 bits left, 330 bits is exact bit count needed to encode 30-char miniprivate key... Here: 1F4crLa8TuSNKfDiUhjkCsDqKx6VTSifG2 thx! |
|
|
|
Regarding what RealOnTheMF said, the message can be also " THEFMSAUR ISKEYFILE" Below are the flame sides aligned in the order that results in the message above. a = inner top CW b = inner right CW c = inner bottom CW d = inner left CW e = outer left CW f = outer bottom CW g = outer right CW h = outer top CW ABCDEFGH same, but read order is CCW (counter clock wise) In the decoder-stream, only 6 out of 8 sides are used in the following fashion: CDbAHF Then, start reading every 5th bit from the stream until you get the the end, then start over from the beginning, +4 bits... then from the beginning +3 bits, then +2 and +1 Everything has to be xored by 011010. You can either ignore first bit of C, or last bit of F, total length of this stream must be 131 bits. Make sure xor key aligns like below. # C CCCCCC CCCCCC CCCCCC CCCCCC CCCCCC CCDDDD DDDDDD DDDbbb bbbbbb bbbbbb bbbbbb bbbAAA AAAAAA AAAAAA AAAAAA AAAAAA AHHHHH HHHHHH HHHHHH HFFFFF FFFFFF F FFFF
#011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010 011010
# T T T T T H H H H H E E E E E
# F F F F F M M M M M S
# S S S S A A A A A U U U U U R R R R R
# I I I I I S S S
#
# S S
# K K K K K E E E E E Y Y Y Y Y
# F F F F F I I I I
# I L L L L L E E E E E |
|
|
|
White Rabbit, I don't know what your goal is, but from what I know you are saying random things. If you knew more, you could simply solve this puzzle and go away with money. You probably, as 99% of people here, don't even know where to start and why. So, do you want tips? Do you want to bring people out of track just to have more time to solve this? I don't really know but I don't think you are in some way related to this puzzle as someone guessed
The one thing that comes to mind is that the White Rabbit is part of the team that designed the puzzle and is frustrated that most people are stuck on the first page, counting flames. The first real step and beyond goes many, many layers deeper. I have found dozens of significant images in that file, or hundreds if you count intermediary steps. There are two big stories, told graphically in there. It’s almost a game, more than a set of images, and appears to descibe at the very least, a vast 3 dimensional space to explore. There may be more dimensions there, if you go by the nodes between them. The white rabbit is the key, and you won’t find him (I don’t think) on the first image. Everything White Rabbit said in this thread, that I’ve seen, applies to the puzzle. This isn’t bragging, more of a sideways hint because I have a sense of honor. The flames, and counting them may have later relevance, I’m not sure, but I haven’t used them directly at all, and I’m hundreds of steps deep. Lateral thinking and a sense of aesthetics will serve you well. This is an amazing feat of software engineering, but the progress I’ve made has mostly involved my artistic skills. In fact, I’m stuck, a bit on a more traditionallly cryptographic aspect of the puzzle. It involves decrypting symbols that serve as instructions in a long series of chains. If you figure out the first step, save early and often, and set aside gigabytes of space for the data you pull out. I lost a few days before I got back on track after a mistake in that department. You could refer to all these small drawings spreaded throughout all the art piece: https://imgur.com/a/5z9WLThey are thousands and more, they are people, animals, creatures... I noticed them the third day spent on this hi-res image at 200% zoom, I thought I was visionary. Thanks for noticing them too. By the way, they are not the very first step that lead to something useful, they could be only funny easter eggs, or maybe they become useful later. I don't know. My workflow is much simpler and straightforward, it involves only what everyone can see without the need to zoom. You will eat your hands when I, or someone else, will reveal it to you. I hope to solve this before being forced to tell you. Yes, the puzzle is 100% solvable with low-res picture, as initially released. The fact that while zooming in you can find certain things is the cloud-effect playing on you. There are hidden things left on purpose, like the rabbit, but these are all clearly visible with the original JPEG image. TIFF/hi-res-JPEG were released only so people stopped following JPEG-related compression artifacts NOT so you can zoom-in 1000% to find hidden birds singing songs to you. |
|
|
|
White Rabbit, I don't know what your goal is, but from what I know you are saying random things. If you knew more, you could simply solve this puzzle and go away with money. You probably, as 99% of people here, don't even know where to start and why. So, do you want tips? Do you want to bring people out of track just to have more time to solve this? I don't really know but I don't think you are in some way related to this puzzle as someone guessed
The one thing that comes to mind is that the White Rabbit is part of the team that designed the puzzle and is frustrated that most people are stuck on the first page, counting flames. The first real step and beyond goes many, many layers deeper. I have found dozens of significant images in that file, or hundreds if you count intermediary steps. There are two big stories, told graphically in there. It’s almost a game, more than a set of images, and appears to descibe at the very least, a vast 3 dimensional space to explore. There may be more dimensions there, if you go by the nodes between them. The white rabbit is the key, and you won’t find him (I don’t think) on the first image. Everything White Rabbit said in this thread, that I’ve seen, applies to the puzzle. This isn’t bragging, more of a sideways hint because I have a sense of honor. The flames, and counting them may have later relevance, I’m not sure, but I haven’t used them directly at all, and I’m hundreds of steps deep. Lateral thinking and a sense of aesthetics will serve you well. This is an amazing feat of software engineering, but the progress I’ve made has mostly involved my artistic skills. In fact, I’m stuck, a bit, on a more traditionally cryptographic aspect of the puzzle. It involves decrypting symbols that serve as instructions in a long series of chains. If you figure out the first step, save early and often, and set aside gigabytes of space for the data you pull out. I lost a few days before I got back on track after a mistake in that department. Are you sure you're not telling yourself a story that you simply want to believe? To me, internal part of the art simply tells how to interpret the flames properly, so you wont have to brute-force them. It might tell something quite specific, like read only reds, or skip this, jump over that, flip bits of flames related to the "partially turned page" (that reveals the blue side), etc. I really doubt you need to go hundreds of steps deep in order to see N-th meaning of all of this. Remember, if you stare long enough at the cloud, you can see anything, and usually those are things that directly reflect your life somehow. Make sure you'Re not in a rabbit hole, dug by the author of the puzzle, cause you might get lost in there. |
|
|
|
|
