Off flame ramblings follow:
It's time well spent going back through this thread a couple times (long though it may be) and seeing for example that:
1) The Phoenix and the Turtle poem was referenced in post #338 on April 5th, 2015
Based on what I have read regarding previous challenges, ytcoin_artist doesn't give hints but does let people know if they are on the right track and confirmed found clues to previous ARG challenges. The fact that she tweeted a section of the poem might be to say "you found this clue but didn't think it was the next step, look again" I couldn't find her giving any hints or clues aside from this one...
2) The skinny inner flame data channel was detailed in post #404 possibly before that as well, then re-discovered recently by smracer. This game has gone on so long that people have forgotten what was tried, abandoned, rediscovered etc.
BitcoinArbiter in post #400 posted a link to some of Rob Myers work https://robmyers.org/blockchain-aesthetics/
It would seem that coin_artist and Rob Myers are tight collaborators
His blockchain-aesthetics code was done around the time this painting was created
some of the code has instructions to "draw" blockchain transactions using "turtle graphics"
I am not a programmer, perhaps someone with better skills can use the code here: https://github.com/robmyers/blockchain-aesthetics/
and make the turtle graphics code examine and draw the transactions done on the 1FLAME address like this one?
Just delving back into the crazy...
Topic: The Legend of Satoshi Nakamato, FINAL STEP PUBLISHED.... 4.87 BTC GRAND PRIZE! - page 23. (Read 108519 times)
January 18, 2018, 12:00:37 PM
January 18, 2018, 05:31:02 AM
they are all universally recognized and ready AS IS
oh right, because programs and things. its easy to forget when thinking of the lower level tedium in these puzzles
January 18, 2018, 05:01:30 AM
I think if the flames holds the private key itself, will be impossible to decode it without the rest of the picture, because if it could be decoded only with operations over the flames, paiting the chess board and the other pieces will be a waste of time for the creator. I think that the chess board is too full of symbols to be only a distraction...
I'm saying this because over the whole thread the flames kept 80% of the attention, and I'm not talking about the 10000% zoom things, the jpeg glitches or the rabbit, simply the pieces and their meaning.
I'm saying this because over the whole thread the flames kept 80% of the attention, and I'm not talking about the 10000% zoom things, the jpeg glitches or the rabbit, simply the pieces and their meaning.
well for one thing the leaves seem to have been (at least partially) incorporated to the big picture. They seem to give the order on feature streams and they seem to tell which feature values should be decoded as 1 and 0. The same for the key ribbons, there are ideas around on how to use them. So it is not that everybody just idles with flames
Agree with you, just saying because I'm seeing a lot of effort on flames, like the lines of code from @kn0w0n3. But for example, nobody talks about why that kind of creeper plant is holding the queen while it melts... Maybe applying maths, logic and counting is not the way for this one. Take this only as thoughts, I really admire all the work being done here. (And in previous puzzles that I followed too).
January 18, 2018, 04:57:16 AM
sure, i was thinking back to previous posts which contemplated all the various possibilities, such as an even shorter word or other fragment being hashed a bazillion times to create the key, which would require conveying the word, how many times to hash it, etc. even in the case of a standard minikey, you still kind of have to figure out you are dealing with a minikey, which then needs to be hashed to get the actual key. all of this is kind of moot anyway until you actually figure out some next steps and make some progress on the painting, as it also seems unlikely that the only part of the painting containing relevant information is the ribbons on the key and the flames. in other words there is still probably plenty to figure out before you need to worry about actually finding the key 
i agree with mostly all you are saying and definitely with the part that a lot of work needs to be done yet. My point was only that if you read a key in any of those formats having 32, 37, 38 bytes or a minikey too, especially the ones with built in sanity control (37, 38 byte, minikey), they are all universally recognized and ready AS IS to sweep the FLAMEN bitcoins. No NEXT steps are needed here.
January 18, 2018, 04:46:21 AM
I think if the flames holds the private key itself, will be impossible to decode it without the rest of the picture, because if it could be decoded only with operations over the flames, paiting the chess board and the other pieces will be a waste of time for the creator. I think that the chess board is too full of symbols to be only a distraction...
I'm saying this because over the whole thread the flames kept 80% of the attention, and I'm not talking about the 10000% zoom things, the jpeg glitches or the rabbit, simply the pieces and their meaning.
I'm saying this because over the whole thread the flames kept 80% of the attention, and I'm not talking about the 10000% zoom things, the jpeg glitches or the rabbit, simply the pieces and their meaning.
well for one thing the leaves seem to have been (at least partially) incorporated into the big picture. They seem to give the order on feature streams and they seem to tell which feature values should be decoded as 1 and 0. The same for the key ribbons, there are ideas around on how to use them. So it is not that everybody just idles with flames
January 18, 2018, 04:42:38 AM
sure, i was thinking back to previous posts which contemplated all the various possibilities, such as an even shorter word or other fragment being hashed a bazillion times to create the key, which would require conveying the word, how many times to hash it, etc. even in the case of a standard minikey, you still kind of have to figure out you are dealing with a minikey, which then needs to be hashed to get the actual key. all of this is kind of moot anyway until you actually figure out some next steps and make some progress on the painting, as it also seems unlikely that the only part of the painting containing relevant information is the ribbons on the key and the flames. in other words there is still probably plenty to figure out before you need to worry about actually finding the key
January 18, 2018, 04:38:08 AM
I think if the flames holds the private key itself, will be impossible to decode it without the rest of the picture, because if it could be decoded only with operations over the flames, paiting the chess board and the other pieces will be a waste of time for the creator. I think that the chess board is too full of symbols to be only a distraction...
I'm saying this because over the whole thread the flames kept 80% of the attention, and I'm not talking about the 10000% zoom things, the jpeg glitches or the rabbit, simply the pieces and their meaning.
I'm saying this because over the whole thread the flames kept 80% of the attention, and I'm not talking about the 10000% zoom things, the jpeg glitches or the rabbit, simply the pieces and their meaning.
January 18, 2018, 04:12:28 AM
jeez you guys are way too hung up on all that. and all i said was it seems less likely they would do all that. sure you could take the name of your pet gerbil and hash it a quintillion times and maybe end up with shakespeare, like a room full of monkeys given infinity to jerk around on a typewriter. of course you would then need to encode instructions on all these irregularly sized things and the steps and number of times to hash them and all that in the painting. again, it simply seems less likely. not impossible
no, no additional instructions are necessary, at least when compared with a random private key setup.
You could, for instance,
1. have the following constraint for the private key: every second bit follows the pattern 011.
2. Then, you could have a constraint for the public address: it starts with 1FLAMEN6
3. (any other constraints we are not aware of at present too)
4. then, you generate matching pair of public address and private key.
5. then, you publicly disclose the address and encode the private key in the flames or generally in the picture
6. And you public the picture as a puzzle.
Observe, that this scheme needs no additional instructions over the scheme with a random private key.
EDIT: you see, the pattern in the flames discloses the order on how to read flames, so maybe it was important for the creators to have this constraint and beneficial over random private key. I mean, it is a random private key which would require additional instructions on how to order segments.
January 18, 2018, 03:59:47 AM
jeez you guys are way too hung up on all that. and all i said was it seems less likely they would do all that. sure you could take the name of your pet gerbil and hash it a quintillion times and maybe end up with shakespeare, like a room full of monkeys given infinity to jerk around on a typewriter. of course you would then need to encode instructions on all these irregularly sized things and the steps and number of times to hash them and all that in the painting. again, it simply seems less likely. not impossible
January 18, 2018, 03:54:32 AM
The fact that the bitcoin address is a vanity one tells us the bits are random, so I guess reading them in a certain order is not possible. So that route is dead.
But CoinArtist also pointed to the poem a few times on twitter. But I couldn't get anything out of it, so I stopped looking at the text.
But CoinArtist also pointed to the poem a few times on twitter. But I couldn't get anything out of it, so I stopped looking at the text.
No, you are mistaken, at least partly. You would have known that if you took the pain to read through the whole thread. As far as I know no commercial or publicly available software allows for creating vanity addresses with vanity private keys, but crax0r showed us (with examples) that you can implement it yourself and fix parts of both the public address and private key and successfuly generate matching pairs of private key and address.
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:
Code:
SUPER1FLAMEN6QPEGRLTFZXDEAFFAL -> 1FLANSqJppAGxWdCrUW2VsrncH1NfWtNXo
SUPER1FLAMEN6JQWSXAAHLJQJDEZXR -> 1FLArjwv7oPTZGUuGxLhEtPh7pkfoSbRTX
SUPER1FLAMEN6RHJSDXWSCEFMSBMWX -> 1FLA4LzZtRuaV914mEJHaWmBGdaMt2AmRG
SUPER1FLAMEN6JQWSXAAHLJQJDEZXR -> 1FLArjwv7oPTZGUuGxLhEtPh7pkfoSbRTX
SUPER1FLAMEN6RHJSDXWSCEFMSBMWX -> 1FLA4LzZtRuaV914mEJHaWmBGdaMt2AmRG
These are all valid mini-private keys that I vanitized in 2 minutes, on GPU it would be much faster...
January 17, 2018, 11:56:39 PM
The fact that the bitcoin address is a vanity one tells us the bits are random, so I guess reading them in a certain order is not possible. So that route is dead.
But CoinArtist also pointed to the poem a few times on twitter. But I couldn't get anything out of it, so I stopped looking at the text.
But CoinArtist also pointed to the poem a few times on twitter. But I couldn't get anything out of it, so I stopped looking at the text.
January 17, 2018, 10:56:38 PM
Good job, but try to find something more interesting as I believe that coin-artist is a big troll and she can draw million of useless shits inside that painting which I believe that it is the most stupid puzzle in history.
January 17, 2018, 10:49:36 PM
One can notice that every long red ribbon in the key has double tooth on top which could mean that the short flames hold only one bit of data whereas long flames hold two bits.
Just a notice for flames fuckers
Just a notice for flames fuckers
January 17, 2018, 04:09:34 PM
January 17, 2018, 03:56:58 PM
We were using different inputs and methods though. I was suggesting construction like this:
first 12 flames (space delimited flames) = 0yp 1yg 1yg 0og 1yp 1op 0yg 1op 1yg 0yg 1op 0yg
and taking one bit per flame on a rotation of height (1) outside color (y) and inside color (o)
first 12 flames after operation = 0 y g 0 y p 0 o g 0 o g which gives 011010001001 according to my scheme
xor of that is of course '000000010011'
....
....
Bacon on the 6s throwaway the leading zero
Doing that now I get-> JAYWUZUZVY.....
and after xoring -> AT_CMODODPCF.....
Bacon on the 5s keeping the zero
Doing this I now get -> NCIBQWK....
after xoring -> AE_IEMHAZY...
first 12 flames (space delimited flames) = 0yp 1yg 1yg 0og 1yp 1op 0yg 1op 1yg 0yg 1op 0yg
and taking one bit per flame on a rotation of height (1) outside color (y) and inside color (o)
first 12 flames after operation = 0 y g 0 y p 0 o g 0 o g which gives 011010001001 according to my scheme
xor of that is of course '000000010011'
....
....
Bacon on the 6s throwaway the leading zero
Doing that now I get-> JAYWUZUZVY.....
and after xoring -> AT_CMODODPCF.....
Bacon on the 5s keeping the zero
Doing this I now get -> NCIBQWK....
after xoring -> AE_IEMHAZY...
Interesting way of taking the data, but I can confirm you are at least doing your debaconing correctly now.
Here is my codes output using your input data
Code:
Turning on Verbose Mode...
line 0 is: 0yg0yp0og0og0op0op0yg0op0yp1
line 1 is: yp0yp1op0yg0og0yp1op0yg0
line 2 is: og0yp1og0yg0op0yg1yg0op1og0og1op0
line 3 is: yg1og0og0op0y
line 4 is: p0op0og0
line 5 is: op0yp0yp0og1og0y
line 6 is: g0yp0yp1og0y
line 7 is: g0og0yg1og0op0yg0y
Total Characters Read: 152
Normalizeing line 0
Line 0 is now: 0110100010010000000110000101
Normalizeing line 1
Line 1 is now: 100101000110010101000110
Normalizeing line 2
Line 2 is now: 010101010110000111110001010011000
Normalizeing line 3
Line 3 is now: 1110100100001
Normalizeing line 4
Line 4 is now: 00000010
Normalizeing line 5
Line 5 is now: 0001001000110101
Normalizeing line 6
Line 6 is now: 101001010101
Normalizeing line 7
Line 7 is now: 100101110100001101
Combined String: 01101000100100000001100001011001010001100101010001100101010101100001111100010100110001110100100001000000100001001000110101101001010101100101110100001101
XORING with 011010
Resulting string 00000001001101101000001000110000111000001100111000001100111100001000010101111101011000011101001000101001001000100001011100000000111100001100011101100100
String split into 5's for decoding:
00000 00100 11011 01000 00100 01100 00111 00000 11001 11000 00110 01111 00001 00001 01011 11101 01100 00111 01001 00010 10010 01000 10000 10111 00000 00011 11000 01100 01110 11001 00
Debaconing:
AE IEMHAZYGPBBL MHJCSIQXADYMOZ
Removing Spaces
00000001001101101000001000110000111000001100111000001100111100001000010101111101011000011101001000101001001000100001011100000000111100001100011101100100
Shifting String
Buffer:
00000001001101101000001000110000111000001100111000001100111100001000010101111101011000011101001000101001001000100001011100000000111100001100011101100100
00000010011011010000010001100001110000011001110000011001111000010000101011111010110000111010010001010010010001000010111000000001111000011000111011001000
String split into 5's for decoding:
00000 01001 10110 10000 01000 11000 01110 00001 10011 10000 01100 11110 00010 00010 10111 11010 11000 01110 10010 00101 00100 10001 00001 01110 00000 00111 10000 11000 11101 10010 00
Debaconing:
AJWQIYOBTQM CCX YOSFERBOAHQY S
line 0 is: 0yg0yp0og0og0op0op0yg0op0yp1
line 1 is: yp0yp1op0yg0og0yp1op0yg0
line 2 is: og0yp1og0yg0op0yg1yg0op1og0og1op0
line 3 is: yg1og0og0op0y
line 4 is: p0op0og0
line 5 is: op0yp0yp0og1og0y
line 6 is: g0yp0yp1og0y
line 7 is: g0og0yg1og0op0yg0y
Total Characters Read: 152
Normalizeing line 0
Line 0 is now: 0110100010010000000110000101
Normalizeing line 1
Line 1 is now: 100101000110010101000110
Normalizeing line 2
Line 2 is now: 010101010110000111110001010011000
Normalizeing line 3
Line 3 is now: 1110100100001
Normalizeing line 4
Line 4 is now: 00000010
Normalizeing line 5
Line 5 is now: 0001001000110101
Normalizeing line 6
Line 6 is now: 101001010101
Normalizeing line 7
Line 7 is now: 100101110100001101
Combined String: 01101000100100000001100001011001010001100101010001100101010101100001111100010100110001110100100001000000100001001000110101101001010101100101110100001101
XORING with 011010
Resulting string 00000001001101101000001000110000111000001100111000001100111100001000010101111101011000011101001000101001001000100001011100000000111100001100011101100100
String split into 5's for decoding:
00000 00100 11011 01000 00100 01100 00111 00000 11001 11000 00110 01111 00001 00001 01011 11101 01100 00111 01001 00010 10010 01000 10000 10111 00000 00011 11000 01100 01110 11001 00
Debaconing:
AE IEMHAZYGPBBL MHJCSIQXADYMOZ
Removing Spaces
00000001001101101000001000110000111000001100111000001100111100001000010101111101011000011101001000101001001000100001011100000000111100001100011101100100
Shifting String
Buffer:
00000001001101101000001000110000111000001100111000001100111100001000010101111101011000011101001000101001001000100001011100000000111100001100011101100100
00000010011011010000010001100001110000011001110000011001111000010000101011111010110000111010010001010010010001000010111000000001111000011000111011001000
String split into 5's for decoding:
00000 01001 10110 10000 01000 11000 01110 00001 10011 10000 01100 11110 00010 00010 10111 11010 11000 01110 10010 00101 00100 10001 00001 01110 00000 00111 10000 11000 11101 10010 00
Debaconing:
AJWQIYOBTQM CCX YOSFERBOAHQY S
And some partial output without verbose...
Quote
AE IEMHAZYGPBBL MHJCSIQXADYMOZ
AJWQIYOBTQM CCX YOSFERBOAHQY S
ATNARQ DHAZ EFPVQ EKJCC APBR E
BG BDBYGOBTYIK LB IUSEFYA DDWI
CNUCGDQM DHQQV WDURJEILQB GHMQ
E IEMHAZYGPBBL MHJCSIQXADYMOZA
JWQIYOBTQM CCX YOSFERBOAHQY SA
TNARQ DHAZ EFPVQ EKJCC APBR EA
G BDBYGOBTYIK LB IUSEFYA DDWIA
NUCGDQM DHQQV WDURJEILQB GHMQA
IEMHAZYGPBBL MHJCSIQXADYMOZAB
WQIYOBTQM CCX YOSFERBOAHQY SAC
NARQ DHAZ EFPVQ EKJCC APBR EAE
AJWQIYOBTQM CCX YOSFERBOAHQY S
ATNARQ DHAZ EFPVQ EKJCC APBR E
BG BDBYGOBTYIK LB IUSEFYA DDWI
CNUCGDQM DHQQV WDURJEILQB GHMQ
E IEMHAZYGPBBL MHJCSIQXADYMOZA
JWQIYOBTQM CCX YOSFERBOAHQY SA
TNARQ DHAZ EFPVQ EKJCC APBR EA
G BDBYGOBTYIK LB IUSEFYA DDWIA
NUCGDQM DHQQV WDURJEILQB GHMQA
IEMHAZYGPBBL MHJCSIQXADYMOZAB
WQIYOBTQM CCX YOSFERBOAHQY SAC
NARQ DHAZ EFPVQ EKJCC APBR EAE
January 17, 2018, 02:53:05 PM
Just for some diversion from the flames:
https://imgur.com/bNjFUzH
CSI 6 E 18 At Est <
> 16
She is wearing those red filter glasses and using black light to check for evidence on clothes around minute 16.
There is more text hidden in the flame area (background of flames and flames) but it is very difficult to read.
https://imgur.com/bNjFUzH
CSI 6 E 18 At Est <
> 16She is wearing those red filter glasses and using black light to check for evidence on clothes around minute 16.
There is more text hidden in the flame area (background of flames and flames) but it is very difficult to read.
January 17, 2018, 02:36:52 PM
@chubbychew, I have updated my code (posted below) so that it can xor bitstrings. That said, I did not find your string "AEIEMHAZYGPBBLMHJCSIQXADYMOZ "
kn0w0n3: Thanks so much for your help, I really appreciate the effort to get me up to speed on the coding. I figured out my errors eventually(bacon with 6bits vs 5bits). We were using different inputs and methods though. I was suggesting construction like this:
first 12 flames (space delimited flames) = 0yp 1yg 1yg 0og 1yp 1op 0yg 1op 1yg 0yg 1op 0yg
and taking one bit per flame on a rotation of height (1) outside color (y) and inside color (o)
first 12 flames after operation = 0 y g 0 y p 0 o g 0 o g which gives 011010001001 according to my scheme
xor of that is of course '000000010011'
My point was that if you followed this pattern around the path you'd always get 0xxxxx0xxxxx0xxxxx0xxxxx (before xoring) which would suggest that constant 0 in front of every 6 bits could be a delimiter. So I was breaking into 6s then throwing out the leading zero and debaconing on the remaining 5 bits.
Code:
0yg0yp0og0og0op0op0yg0op0yp1
yp0yp1op0yg0og0yp1op0yg0
og0yp1og0yg0op0yg1yg0op1og0og1op0
yg1og0og0op0y
p0op0og0
op0yp0yp0og1og0y
g0yp0yp1og0y
g0og0yg1og0op0yg0y
yp0yp1op0yg0og0yp1op0yg0
og0yp1og0yg0op0yg1yg0op1og0og1op0
yg1og0og0op0y
p0op0og0
op0yp0yp0og1og0y
g0yp0yp1og0y
g0og0yg1og0op0yg0y
Bacon on the 6s throwaway the leading zero
Doing that now I get-> JAYWUZUZVY.....
and after xoring -> AT_CMODODPCF.....
Bacon on the 5s keeping the zero
Doing this I now get -> NCIBQWK....
after xoring -> AE_IEMHAZY...
January 17, 2018, 10:22:37 AM
I found this message in the flames:
" I AM COIN-ARTIST, I WANT TO TROLL YOU AND FUCK EVERY SINGLE NEURON CELL IN YOUR STUPID BRAIN"
" I AM COIN-ARTIST, I WANT TO TROLL YOU AND FUCK EVERY SINGLE NEURON CELL IN YOUR STUPID BRAIN"
January 17, 2018, 10:16:38 AM
@Itod, so in your opinion the "The_____iskeyfile" message is the intended message?
Well, I have a theory didn't want to mention before while trying to find the proof. The message "THEfm_aurISKEYFILE" can hardly be a collision, and the bold scrambled part is intentionally left there to be de-scrambled in the same way other bit-streams should be de-scrambled to get a key. If you come across the stream of bytes from private key you may not notice something is scrambled, but if you find something like plaintext quoted above it's pretty obvious something is wrong. So to answer you: yes I think it's intentionally left there scrambled/corrupted to show the way.
Anything can be the way to de-scramble it in a coherent message. The current path I'm working are the chessboard fields affected by Phoenix fire. It looks to me that those chessboard fields that should be dark are somehow lighter with this bright blue Phoenix color then the white ones, so some bits associated with those chessboard fields should be inverted in raw bit-streams. I believe if we invert some bits from the "THEfm_aurISKEYFILE" bit-stream, in this way I've described, we will get coherent message from this bit-stream, and then we should apply this same transformation to colors bit-streams to get the private key.
AUR makes me think of Arch User Repository. Maybe there is a package in there that has some information?
Was there more than just this string in the output?
I am sceptical to the whole idea of it being the intended message, but still - to be on the safe side I entertained this idea for a while and thought that if we were looking for a file then maybe the fm.aur was the name of the file. I googled some results but nothing very constructive, though. But maybe somebody else will be more lucky.
January 17, 2018, 04:36:14 AM
I've got a theory I've been working on for a couple of days. It almost feels like a Eureka moment with no payoff *yet. I'm wondering if anyone else wants to help me see if I'm on the right track or if I'm close but got off somewhere. I really feel like I'm on to something here(...)
I like your theory very much. Finally thanks to your concepts we are somehow getting the leaves to play a role in decyphering the private key. A few observations from my side that hopefully you (we ?) will be able to incorporate too
1. why read one feature per flame, changing features? My impression would be to read all 3 features from each flame, but stick to your interpretation that the leaves would indicate the order of features and what value should be considered as 1.
2. why don't you consider thickness (blob)? There are two more leaves in the upper segment, one is touching a very thin colorless flame and the other is present in the upper segment only in a small part, and that second one is indicating a nice thick short flame. Either of them can indicate thickness (blob).
Jump to: