As a participant in The Legend of Satoshi Nakamoto from the very beginning in late summer of 2014, I'm absolutely thrilled that someone has finally solved this last piece of the ARG. I learned so much about cryptography and bitcoin during the solving--and made treasured puzzle friends in the process. What a wonderful experience!
So excited to read about the solve!
Congrats to the brilliant creators and solvers!
+1! |
|
|
|
|
Bots used to be fun, now they just sound like disturbed people.
|
|
|
|
Check the OP... The guy who posted it and the Twitter guy coin_artist.
It's a girl! mirth won that one, it's over. Those tokens were used when the puzzle was being played on LTB forum, which lead up to the image. Best image available is at post 1 of this thread. |
|
|
|
he says he believes its correct, but translating between the two is irritating.
meaning he doesnt yet have an answer and is still working on it.
meaning level 1 is not solved. the cell door is still locked.
Please read posts carefully, mirth23 is refering to the translation between the notation he used and the one 4pollo is using. Door was opened, level1 is solved, prize was claimed and I can show you a printscreen if you still don't believe. |
|
|
|
Level 1 has been SOLVED with the entry of a correct keypad code. Doing so has kicked off a 30 day timer prior to the Level 2 opening. I'll drop a few hints during that time to help folks catch up:
Hint #1: The keypad code is derived entirely from the triangle + dot code. That and the URL for the text adventure are the only pieces of info needed from the painting to complete Level 1.
Any hints on roughly how long the final code is? Hint #2: The final code was surprisingly long (> 100 characters) with all caps and no spaces. Well, that throws my brute forcing scheme out the window.  Depends on how you implement your brute force - the text game checks the keypad code using an unprotected POST.  Yeah, I was using a custom tool to check for variations of my guesses, but I would never imagine that a "cell key" would be so big. |
|
|
|
You can simply use the object initial letter and it will accept the command. Example: "x d" = "x door" You can also use this to "bruteforce" all visible objects in the room, by typing: - x a - x b - x c - ... |
|
|
|
|
I am only responsible for creating the list and one of the projects (bitcoincity.info), all others were found online and have different authors. This list includes only realtime visualizations of bitcoin related objects, like transactions, blocks or nodes. There are many great block explorers with awesome ways to visualize txs, blocks, chains, etc., but you're watching historical info and not realtime, so those are not the purpose of this list. These visualizations show many different ways you can take some data and present it in a pleasent way. Some are more detailed than others, some are more data-driven while others give more relevance to the visual part. I agree that most might not have a great practical use, but it depends on what you need. In some of them, you can have them monitoring your own addresses with a little tweak, or make analysis on specific types of transactions...
@btc_enigma: your idea sounds interesting, but I don't think you can predict for sure how long it will take until a tx gets included in a block, since it's always up to the miner to decide which transactions are included in his block.
|
|
|
|
|
Qe8: 1 vote (mathgal23)
Qf3: 1 vote (Morecoin Freeman)
Qb7: 1 vote (micaman)
|
|
|
|
Additionally, the input address isn't actually gotten from any public key in the input. Rather that address is retrieved by checking the specified output since there are special p2sh addresses that exist that don't even use public keys anywhere in them.
It is possible to determine the addresses based on the pubkeys or redeem scripts when those appear in input scripts, without having to check the transaction that is being spent. Maybe I'm using the wrong terminology here, but I can show you an example if you want. |
|
|
|
If you check, as example, this transaction / raw: 0100000002f60b5e96f09422354ab150b0e506c4bffedaf20216d30059cc5a3061b4c83dff000000004a493046022100e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b022100b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d01fffffffff7272ef43189f5553c2baea50f59cde99b3220fd518884d932016d055895b62d000000004a493046022100a2ab7cdc5b67aca032899ea1b262f6e8181060f5a34ee667a82dac9c7b7db4c3022100911bc945c4b435df8227466433e56899fbb65833e4853683ecaa12ee840d16bf01ffffffff0100e40b54020000001976a91412ab8dc588ca9d5787dde7eb29569da63c3a238c88ac00000000 This transaction shows 2 inputs but I can't find any pubkeys: 01000000 - version number
02 - number of inputs
f60b5e96f09422354ab150b0e506c4bffedaf20216d30059cc5a3061b4c83dff - tx hash (spending)
00000000 - tx index
4a - script length
49 - OP_CODE 49
30 - header byte
46 - sig length
02 - header byte
21 - r length
00e26d9ff76a07d68369e5782be3f8532d25ecc8add58ee256da6c550b52e8006b - r
02 - header byte
21 - s length
00b4431f5a9a4dcb51cbdcaae935218c0ae4cfc8aa903fe4e5bac4c208290b7d5d - s
01 - sighash type
ffffffff - sequence number
f7272ef43189f5553c2baea50f59cde99b3220fd518884d932016d055895b62d - tx hash (spending)
00000000 - tx index
4a - script length
49 - OP_CODE 49
30 - header byte
46 - sig length
02 - header byte
21 - r length
00a2ab7cdc5b67aca032899ea1b262f6e8181060f5a34ee667a82dac9c7b7db4c3 - r
02 - header byte
21 - s length
00911bc945c4b435df8227466433e56899fbb65833e4853683ecaa12ee840d16bf - s
01 - sighash type
ffffffff - sequence number
(...) How can you determine what are the addresses of the inputs without a pubkey? |
|
|
|
Thank you for your suggestion! I believe Oxt is a great tool for historical data analysis, but I'm not able to find any realtime/live data visualizations there, which is the common ground between all the projects listed here. Please correct me if I missed something. |
|
|
|
|
Updated: New visualizations added. 27 available at the moment.
|
|
|
|
Great work on that tool!
I'm just confused while reading the block size chart where, for example, it says:
Charts / Transactions / Block Size
Monthly Stats from January 2009 to January 2016 - Lin. Scale
December 2015
Aggregate: 3157779464 bytes
Maximum: 122842930 bytes
Minimum: 78795102 bytes
Am I reading this wrong or does it say that the minimum block size in December 2015 was ~75MB?
These stats should be read like this: - The cumulated size of blocks mined in December 2015 was ~3.15GB - The max value for blocks mined during 1 day of this month was ~122MB (actually it was on 12/14/2015) - The min value was ~78MB (on 12/31/2015) You can check this by clicking on the chart with the mouse put on December. The chart will display the same metric for december 2015 only and you'll see the max and min values very easily. Note that the same principle applies at this level (but this time it's related to blocks mined during a given day). The FAQ page contains a short help about the interactive charts. But my english is crap and I fear some points may remain unclear (sorry about that). Feel free to asks more questions if needed. Got it, clear answer. Thanks! |
|
|
|
|
Great work on that tool!
I'm just confused while reading the block size chart where, for example, it says:
Charts / Transactions / Block Size
Monthly Stats from January 2009 to January 2016 - Lin. Scale
December 2015
Aggregate: 3157779464 bytes
Maximum: 122842930 bytes
Minimum: 78795102 bytes
Am I reading this wrong or does it say that the minimum block size in December 2015 was ~75MB?
|
|
|
|
The function 'json_decode' returns an object. In that object you have an array of txs. Each of those txs is, again, of type object. You don't need to replace anything on the '$json3' string. $json_url3 = "https://blockchain.info/da/unconfirmed-transactions?format=json";
$json3 = file_get_contents($json_url3);
$data3 = json_decode($json3);
$tx_count = count($data3->txs);
$latesttx = $data3->txs[$tx_count-1]->hash; |
|
|
|
|
Show Posts
