 Show Posts
|
|
Pages: [1] 2 3 4 »
|
Maybe they are waiting for their BCH and BTG wallets to resync after importing the private key before they release the solution. I would.
That's what I was thinking too. |
|
|
|
|
Congrats to the winner! I'm looking forward to the walk-thru.
I can't understand the hate from some people. The solution will be revealed proving that it was possible for anyone to solve it all this time. I hope you don't infect others IRL with your self hatred, self loathing, blame everyone but yourself attitude.
Sheesh. Taylor Swift was right....haters gonna hate ('cause that's all they know, I guess)
|
|
|
|
|
That's two more troll accounts to ignore....
|
|
|
|
|
Another observation re: data.
If you look at the first 17 bits of the inner track top color (l->r) against the first 17 bits of the outer track top color in same direction, they are identical. I know you'd expect repeats even in random data but 17 bits in a row starting right on the boundary? Odds are 1 in 131072 that'd happen?
inside colors
"000101010010110110", // outside track top, left to right
outside colors
"0001010100101101110010110000", // inside track top, left to right
|
|
|
|
Ahh....that's better  |
|
|
|
It's not coin_artist fault if you are blind or if you are so attracted by flames. She is happy that way.
Welcome to my ignore list. Bye-bye. |
|
|
|
[the reocurring patterns are as follow:
Actually, on second look, I don't think this is statistically significant. Out of a sample of 25, you have 16 unique values which is not surprising. You're bound to get repeats even if you look at random data. If the sample size was much larger and you still got few values, that would mean something more I think. But that doesn't mean the thin/thick data can't also be part of the solution. |
|
|
|
If we are on the level of terminology, the more accurate statement would be that WIF is a 51 char string with certain chars excluded.
Yep, you're right. WIF as 306 bits doesn't really exist outside my convenient mapping from 6 bits onto base58 space. So my 306 bit definition fails  I take it back. |
|
|
|
It is extremely interesting. Maybe even a breakthrough post, for me. If you divide it in groups of 6 (exactly how alphabetcanary did for lengths earlier) you'll notice that the same patterns reoccure all over again:
Wow, actually that would be a game changer if true! I will try to verify. |
|
|
|
Of course it does leave 51 chars in base58 encoding. It is by no means surprising. As I said above, 152 flames, if you assume a flame codes only 2 bits i. e. two colors, inner and outer (with length bits EXCLUDED, exactly how you did exclude length information but using a different method), code 304 bits which is exactly the WIF length and as I said above, this is exactly the reason this theory was so appealing to many forum members (around page 29 of this thread I think)
Just to clarify terminology, WIF format is not 304 bits (my mistake on a previous post too, BTW). WIF implies a base58 encoding because it's the format you import into a wallet. In this case, it would be either 306 bits for a non-compressed version and 312 for compressed version assuming 6 bits per char. 304 bits = 38 bytes which is enough space for a compressed 'raw' key (not base58, but the bytes before it gets base58 encoded) which fits just the inner/outer color informatin. I think the subtle difference here is I don't exclude ALL length information when making the key. I include 2 bits to get up to that 306 number so I can make a base58 string. But I agree, this is not that surprising since I outlined all this around page 25 of this thread. |
|
|
|
Have you tried using the inner shape as the third bit (skinny line or blob of paint)?
No. I noticed those too but just felt it was not consistent enough to count as data. 6PR theory might still be possible but I haven't gone down that road. |
|
|
|
The two missing flames is a good theory and deserves to be tried. I'm going to share the path I attempted which assumes there is no missing data. If you interpret the data stream 6 bits at a time, with the traversal path I outlined in a previous post, you get strings that look like this: UTCUGYUYBFCYYYFUUTCYBGCFU2Mnsq3?cqkarYvtusft8c30rxBEB?FxwHn1tVRjXHFdQ?RYiUKh
UTCUGYUYBFCYYYFUUTCYBGCFU9ukq?YS3u4Erbiz10JY?a?enBZNCVm1oy?ByVQ?V?DimryqomWs
UTCUGYUYBFCYYYFUUTCYBGCFU2Mnsq3?cqkarYvtusft8c30rxAsv4r9ApK?DcgNaprUh1gZPdnQ
EgEG6Gn6nngGppn86GnppEn6nd?cQHrytSLCtk?cav4rxH4LnBZNCTQyU?heqAzMR?D3uApnq?Kr
deudqZdZvruZZZrddeuZvqurdrMnsq3?cqkarYvtusft8c30rxAsv4r9ApK?DcgNaprUh1gZPdnQ
deudqZdZvruZZZrddeuZvqurdxCMG5Zf?C?sFWP7?6oZ3X2TKvVNCVm1oy?ByVQ?V?DimryqomWs
(Here, I've concatenated all the data starting with lengths, then inner, then outer colors in the order of the pattern. This is just ONE of a many ways of concatenating the data. Just for demonstration purposes, I used a base 58 alphabet here and use ? when the value goes beyond 58. By no means is this a complete list). Now, due to the pattern in the lengths, the beginning part sticks out like a sore thumb because there are actually only 8 possible combinations for 6 bits when you fix 3 of them (0.1.1.). Turns out only 7 are actually used. That's why the characters repeat. So let's split the strings where the repeated characters end: EgEG6Gn6nngGppn86GnppEn6n d?cQHrytSLCtk?cav4rxH4LnBZNCTQyU?heqAzMR?D3uApnq?Kr
UTCUGYUYBFCYYYFUUTCYBGCFU 2Mnsq3?cqkarYvtusft8c30rxBEB?FxwHn1tVRjXHFdQ?RYiUKh
UTCUGYUYBFCYYYFUUTCYBGCFU 9ukq?YS3u4Erbiz10JY?a?enBZNCVm1oy?ByVQ?V?DimryqomWs
UTCUGYUYBFCYYYFUUTCYBGCFU 2Mnsq3?cqkarYvtusft8c30rxAsv4r9ApK?DcgNaprUh1gZPdnQ
deudqZdZvruZZZrddeuZvqurd rMnsq3?cqkarYvtusft8c30rxAsv4r9ApK?DcgNaprUh1gZPdnQ
deudqZdZvruZZZrddeuZvqurd xCMG5Zf?C?sFWP7?6oZ3X2TKvVNCVm1oy?ByVQ?V?DimryqomWs
Oh look, you end up with exactly 51 characters left over after the pattern ends. (Note: This actually means that you start taking 'key' bits while two bits away from the end of the lengths but I don't think that really matters. That could be the tricky part. There's no reason the key needs to start exactly on a boundary between lengths and colors, for example.) So my theory is that the first part is supposed to be used as a key to deciphering the second part. Of course, if you leave the lengths to the end, then the whole thing gets reversed but you end up with the same situation. Basically, 51 *ciphered* characters representing the bitcoin key, then another key to deciphering THAT key. If you try this, you will of course have to keep the values those '?' represent in my examples so you can apply math operations on them. I think once you do the right math, everything will fall within 0-57 as expected. So in short, my theory is: Flames = FlameEncode(cipherkey + Cipher(bitcoinpk, cipherkey)) or Flames = FlameEncode(Cipher(bitcoinpk, cipherkey) + cipherkey) I've tried many operations trying to use those 25 characters as a deciphering key for the 2nd part with no luck (add, subtract, xor, bit shifting, even hill cipher 5x5 matrix). Good luck! [edit : This theory means the cipher key has no meaning. It doesn't have to have any meaning. It was chosen to be conspicuous so you can separate it from the random data which is the bitcoin key] |
|
|
|
Were there some coins in this one you solved?
Yes, 0.0260414 BTC. |
|
|
|
The solution is interesting and may relate to this puzzle. Each image is converted to six bits of information, and this series of six bits are used as index into Base58 charset, "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz". To simplify it, each 6 bits are index how much is each letter away from the beginning of charset - the letter/number "1". This series of 6 bits converts to WIF encoded private key in this manner. If something like this applies to this puzzle also, we are looking for series of 6 bits which begin with 5 since all WIF encoded private keys begin with this number.
Heh, I solved that one. I was excited that it might apply to this one too but alas I've tried it and nothing. Compared to 1FLAMEN6, this was a cinch... Here is my solution code: import java.io.*;
public class Puzzle
{
static int perm = 0;
static char[][] pt = new char[720][];
static char b58[] = {
'1','2','3','4','5','6','7','8','9','A','B','C','D','E',
'F','G','H','J','K','L','M','N','P','Q','R','S','T','U',
'V','W','X','Y','Z','a','b','c','d','e','f','g','h','i',
'j','k','m','n','o','p','q','r','s','t','u','v','w','x',
'y','z','?','?','?','?','?','?'
};
static {
for (int i = 0; i< 720;i++) {
pt[i] = new char[6];
}
}
static void swap(char i[], int j, int k) {
char tmp = i[j];
i[j] = i[k];
i[k] = tmp;
}
static void permute(char[] i, int start, int end) {
int c;
if (start == end) {
pt[perm][0] = i[0];
pt[perm][1] = i[1];
pt[perm][2] = i[2];
pt[perm][3] = i[3];
pt[perm][4] = i[4];
pt[perm][5] = i[5];
perm++;
} else {
for (c = start; c <= end; c++) {
swap(i, start, c);
permute(i, start + 1, end);
swap(i, start, c);
}
}
}
public static void main(String args[]) throws Exception {
char[] lst = {'A','B','C','D','E','F'};
permute(lst, 0,5);
// Data file represents which vertices inside the
// 6 point hexagon are used on each character of
// the key. Labels A,B,C,D,E,F.
File f = new File("data");
FileInputStream fis = new FileInputStream(f);
InputStreamReader ir = new InputStreamReader(fis);
BufferedReader br = new BufferedReader(ir);
String[] key = new String[51];
// Slurp in vertices file
int c=0;
while (true) {
String l = br.readLine();
if (l == null) break;
key[c] = l; c=c+1;
}
// For every permutation of vertices
for (int p=0;p<720;p++) {
// Build candidate string
StringBuffer candidate = new StringBuffer();
for (int i=0;i<51;i++) {
String keychars = key[i];
// Translate into binary given perm p
int total = 0;
for (int j=0;j<keychars.length();j++) {
int rel = keychars.charAt(j) - 'A';
int v = pt[p][rel] - 'A';
// Tricky. Rotate position of bits on each frame!
v=v-i; while (v < 0) v=v+6;
total += (int)Math.pow(2,v);
}
candidate.append(b58[total]);
}
String candidateStr = candidate.toString();
if ((candidateStr.startsWith("5H") ||
candidateStr.startsWith("5J") ||
candidateStr.startsWith("5K") ||
candidateStr.startsWith("5L")) && !candidateStr.contains("?"))
System.out.println(candidate.toString());
}
}
}
And this is the data file: F
FC
CE
FAC
AC
AC
ABFD
FBC
FCD
E
FA
CED
BFEC
ABFED
FCD
BE
FC
EA
AC
ACDEF
DEF
BCDF
CF
ABE
BCEF
CDE
ACF
AD
BCD
ACDF
FB
BCE
AF
ACDE
CF
CFA
BDE
ABDEF
ACD
ABF
F
CD
CDEF
AB
ABCF
AE
ABEF
B
ACE
CD
ABCE
|
|
|
|
I will not ask for a part of the winnings, or something. I only ask the possible winner not to run away with the money without explain to all of us how to solve the final steps.
This is the only condition.
LOL. This is an unnecessary condition. Once the funds are moved, the puzzle creator will release the 'solver' image/post that explains how everything works. This is how it's always worked with these puzzles. No reason to believe otherwise this time. |
|
|
|
This is clearly a scam and you are a fool taking anything out of this posts.
+1 The rabbit is on my ignore list. Stop feeding the troll. |
|
|
|
1) We have 17 leaves, 17x3=51 characters of WIF. WIF is encoded in Base58 (26 letters capital and small and numbers without O, 0, l, I, +, / - so it's smaller Base64).
Could anyone tell me what's the lowest bit number to encode it ? Is 6 bits enough or we need at least 7 ?
Yes, 6 bits is sufficient to cover Base58. But if you come across 6 bits that represent a value >= 58, you have to decide how to handle that as it would not address a B58 character. You can wrap around or consider it invalid. |
|
|
|
This is my dataset visualized. Relative positioning between inner/outer track not preserved as I assume bits are meant to be taken track-wise.  |
|
|
|
How did you discover the order in which you read the sides?
I grouped just the lengths by six each on a single line and the pattern pops out: 0 1 1 0 1 1 0 1 1 0 1 0 0 0 1 0 1 1 0 1 1 0 1 1 0 0 1 1 1 1 0 1 1 1 1 1 0 1 1 0 1 1 0 1 1 1 1 1 0 0 1 0 1 0 0 0 1 1 1 0 0 0 1 0 1 1 0 1 1 1 1 1 0 1 1 1 1 1 0 1 1 1 1 1 0 0 1 1 1 0 0 1 1 0 1 1 0 1 1 0 1 1 0 1 1 0 1 0 0 0 1 0 1 1 0 1 1 1 1 1 0 0 1 0 1 1 0 0 1 1 1 0 0 1 1 0 1 1 0 0 1 0 1 0 0 0 1 1 1 1 0 0 PS: As a checksum: I counted 150 flames. Does this match with your findings alphabetacanary?
We might want to abstract the whole image, having only flames, length and color in the image so we dont start deciding if something is a flame or not over and over again
No, I count 152 flames in total. If you look at my post #518, I provided the dataset I am working with. That probably accounts for the disruption of the pattern in your dataset. I went over my numbers four times and they always check out for me. |
|
|
|
|
