ARG Puzzle with 3.5 BTC Private Key Prize, Game Over

[Timmmaahh]

0 = 0A = 10BABYA = 36WOW?

On the original image....
0 is the starting point, 0 = A, capital a, 10 characters is a baby a (cute )
Above that there is also the letters 3 6 w o w.......
Wonder what that means....

im braining on this but no way

[1714179365]

1714179365

[1714179365]

1714179365

[1714179365]

1714179365

[1714179365]

1714179365

[1714179365]

1714179365

[1714179365]

1714179365

[S4VV4S]

0 = 0A = 10BABYA = 36WOW?

On the original image....
0 is the starting point, 0 = A, capital a, 10 characters is a baby a (cute )
Above that there is also the letters 3 6 w o w.......
Wonder what that means....

im braining on this but no way

Yeah I found it weird too....

I can't figure out what it means though....

[micaman]

http://www.prometheusforum.net/discussion/178/prometheus-viral-mystery-1-solved/p1

[Gatekeeper]

OP again , but nothing we don't already know

1) 0=0 A=10 a=36
2) 6EQUJ5
3) z69JZqlJn862D1ndx7oLVEMmVOlP1zewEeUCrsI7Roahzpeny7P

we know it's base64 code
OP said "No sha or hash needed"

would also indicate that the squigly lines we added in don't really have anything to do with it.

[mtgox555]

Yea. that hint doesn't help me at all. That is where i have been all along.
6142630195 and
6106091935524719490806021301493959075021311422483100472501614058144030125354180 72750364361514049600725
or
6169193552471949862131493959750213114224831047251614058144030125354187275036436 151404960725

depending on if you use 6=06 or 6=6

[micaman]

Tried to shift uppercase by 10, lowercase by 36, and no shift on numbers. Nothing.

[alphabetacanary]

Guys, I believe it's a shift of the original text.
Each character is shifted within the 62 character alphabet described by Crops clue.  
The amount to shift is given by the WOW signal characters.  

This program, for example transforms the "z69JZ..." string into

5KZnsvrXDcP7JFD7GCuZvifrbcBtK4kAe8nHx6ibktgvPJxs4Lp

Notice how the first two characters changed to 5K ? That's what private keys start with.  However, the answer I get doesn't transform into a valid private key since the checksum doesn't match.  I'm posting my program in the hopes someone else has a better variation.  I just want this thing over...

Code:

#include <stdio.h>
#include <string.h>

char* alph = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";

int idxof(char c, char* alphabet) {
    int i;
    for (i=0;i<strlen(alphabet);i++){
        if (alphabet[i] == c) { return i; }
    }
    return -1;
}

main()
{
    char* s = "z69JZqlJn862D1ndx7oLVEMmVOlP1zewEeUCrsI7Roahzpeny7P";
    char* p = "6EQUJ5";

    int i =0;
    int n;
    while (i < strlen(s)) {
        int n = idxof(s[i],alph);
        int v = idxof(p[i%strlen(p)],alph);
        v=(v+n) % 62;
        printf ("%c",alph[v]);
        i++;
    }
    printf ("\n");
}

EDIT: I believe there is either more after the 6EQUJ5 or the algorithm is slightly off.  Remember, if you are trying variations of the 'p' string, you must only use characters from the alphabet.  So no punctuation or spaces.

[moinen]

This program, for example transforms the "z69JZ..." string into

5KZnsvrXDcP7JFD7GCuZvifrbcBtK4kAe8nHx6ibktgvPJxs4Lp

Notice how the first two characters changed to 5K ? That's what private keys start with.  However, the answer I get doesn't transform into a valid private key since the checksum doesn't match.  I'm posting my program in the hopes someone else has a better variation.  I just want this thing over...

I was just going to post the exact same findings, except that at my end, I got the same key and it does convert to a public key. Namely, 1nchRAYGJofxyrkuhbL1CGYtD5x8Lowi5. It made my heart jump when I found it, but it is, alas, empty.

[arg]

Code:

echo -n "5KZns" | openssl dgst -sha256
b2a950ff612a89d7fd2effa6d75acced098d9d141a559029629080c092aedf14

Yep. That's what I came up with. You can't get a sane private key out of it.

I think this is right, I don't know why it doesn't give the correct key though.

I was just going to post the exact same findings, except that at my end, I got the same key and it does convert to a public key.

It doesn't, it's not valid base58.

[moinen]

I was just going to post the exact same findings, except that at my end, I got the same key and it does convert to a public key.

It doesn't, it's not valid base58.

Oh, it imports fine on blockchain.com though. Maybe it is one of those other wallet import formats that it is defaulting to.

[mtgox555]

I did the exact same thing and was very disappointed that it didn't work.
5KZnsvrXDcP7JFD7GCuZvifrbcBtK4kAe8nHx6ibktgvPJxs4Lp is wrong though. This is the correct one albeit still not the answer:
5KZnsvrXDcP7JFD7GCuZvifrbEBtK4kAe8nHx6ibktgvPJxs4Lp

You are wrong Gatekeeper. For reference the reason why it does get imported is here:
http://gobittest.appspot.com/PrivateKey
play around with it a bit.

[Gatekeeper]

5KZnsvrXDcP7JFD7GCuZvifrbcBtK4kAe8nHx6ibktgvPJxs4Lp  should be a valid private key. It doesn't include a zero, capital o, capital i or lowercase L.
it is the key for 1nchRAYGJofxyrkuhbL1CGYtD5x8Lowi5 according to blockchain

[arg]

5KZnsvrXDcP7JFD7GCuZvifrbcBtK4kAe8nHx6ibktgvPJxs4Lp  should be a valid private key. It doesn't include a zero, capital o, capital I or lowercase l.
it is the key for 1nchRAYGJofxyrkuhbL1CGYtD5x8Lowi5 according to blockchain

The checksum doesn't verify though. It's called base58check because it has a checksum.

[Gatekeeper]

5KZnsvrXDcP7JFD7GCuZvifrbcBtK4kAe8nHx6ibktgvPJxs4Lp  should be a valid private key. It doesn't include a zero, capital o, capital I or lowercase l.
it is the key for 1nchRAYGJofxyrkuhbL1CGYtD5x8Lowi5 according to blockchain

The checksum doesn't verify though.

blockchain seems to think it does
https://blockchain.info/address/1nchRAYGJofxyrkuhbL1CGYtD5x8Lowi5

[alphabetacanary]

5KZnsvrXDcP7JFD7GCuZvifrbcBtK4kAe8nHx6ibktgvPJxs4Lp  should be a valid private key. It doesn't include a zero, capital o, capital I or lowercase l.
it is the key for 1nchRAYGJofxyrkuhbL1CGYtD5x8Lowi5 according to blockchain

The checksum doesn't verify though.

blockchain seems to think it does
https://blockchain.info/address/1nchRAYGJofxyrkuhbL1CGYtD5x8Lowi5

The public address generated from the 32 bytes within the base 58 string we found (after the 0x80 byte) will obviously be valid.  But the point is, the private key we find (in base 58 format) is not valid since the checksum bytes aren't correct.  So the transformation is a bit off I think.

Again, I think there is either more to the shifting key or the algorithm is a bit off.

[arg]

5KZnsvrXDcP7JFD7GCuZvifrbcBtK4kAe8nHx6ibktgvPJxs4Lp  should be a valid private key. It doesn't include a zero, capital o, capital I or lowercase l.
it is the key for 1nchRAYGJofxyrkuhbL1CGYtD5x8Lowi5 according to blockchain

The checksum doesn't verify though.

blockchain seems to think it does
https://blockchain.info/address/1nchRAYGJofxyrkuhbL1CGYtD5x8Lowi5

The private keys people came up with are wrong. The chance of typing in random characters starting with 5 and getting a valid key are one in 2^32. It's not going to happen to anybody ever. Blockchain.info's wallet is just shit and ignores the checksum by the looks of things.

Prediction:

Code:

016982cea2101f1126034ecb8572e949604054bbb571d4e1b736b10ccee9c9ea

[Gatekeeper]

that imports as
https://blockchain.info/address/1MtR9nBGfWBLY23q4dRGRjjzBBiEdxRmC3

if they are not valid addresses then that is a fatal flaw in the blockchain because it's showing as a valid address and you could send coins there

If you edit the address it comes back as checksum not valid, so it clearly does check the addresses and says that this one is valid. If it's not then blockchain is fucked

eg:
https://blockchain.info/address/1MtR9nBGfWBLY23q4dRGRjjzBBiEdxRmC2 is not valid (change 3 to 2 at end)

[arg]

that imports as
https://blockchain.info/address/1MtR9nBGfWBLY23q4dRGRjjzBBiEdxRmC3

if they are not valid addresses then that is a fatal flaw in the blockchain because it's showing as a valid address and you could send coins there

If you edit the address it comes back as checksum not valid, so it clearly does check the addresses and says that this one is valid. If it's not then blockchain is fucked then

 If you could import that invalid private key to begin with, blockchain.info is not verifying checksums properly. It's invalid, end of story. The address checksum is a different matter, you can have an address but no matching private key.

[ooxtcoo]

L4rK1yDtCWekvXuE6oXD9jCYfFNV2cWRpVuPLBcCU2z8TrisoyY1


this private key have 24 transactions but 0 btc on it!

got to this adress: 1F3sAm6ZtwLAUnj7d38pGFxtP3RVEvtsbV

[itod]

that imports as
https://blockchain.info/address/1MtR9nBGfWBLY23q4dRGRjjzBBiEdxRmC3

if they are not valid addresses then that is a fatal flaw in the blockchain because it's showing as a valid address and you could send coins there

If you edit the address it comes back as checksum not valid, so it clearly does check the addresses and says that this one is valid. If it's not then blockchain is fucked

eg:
https://blockchain.info/address/1MtR9nBGfWBLY23q4dRGRjjzBBiEdxRmC2 is not valid (change 3 to 2 at end)

This is not true, there are extremely large number of BTC address that no private key hashes to. If private key (WIF) checksum is wrong, no decent wallet should import it. For instance look at this BTC address:
https://blockchain.info/address/1BitcoinEaterAddressDontSendf59kuE
You can send money to it, but you can never retrieve coins from it. There are thousands of transactions like that in the blockchain.