Solution for the 2nd stage
Please read the
solution for the 1st stage if you haven't already
As before, the first thing to do is to understand what the scriptPubKey requires in order to be reclaimed. Let's see it:
OP_DEPTH OP_1 OP_NUMEQUAL OP_IF 6e616d65206f66206e616b616b616d6f746f OP_DROP
OP_RIPEMD160 OP_RIPEMD160 9c864b8bb110c05cb9c77381ad5d6868f0fd9f9f OP_EQUAL
OP_ELSE OP_DUP OP_HASH160 897b934876ff50bfebe218e30382d7eaa6559a12
OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF
So, the first thing it does is OP_DEPTH, that returns the number of entries in the stack and put it in the stack itself. that plus OP_1 and OP_NUMEQUAL make a test that returns true if the scriptSig (which get executed before) yelds a single value, false otherwise. The If....Else...End if block after tell us that this scriptPubKey can work in 2 different ways: the second one is a standard pay-to-address transaction script, which gets executed when the scriptSig gives the two variables needed by a signature verification: sig and pubkey. As the address associated with this method is the same used to fund the contest, it's safe to assume that the private key isn't pubblicly available, so this method isn't the one we'll use. Let's focus on the other verification subscript:
6e616d65206f66206e616b616b616d6f746f OP_DROP
OP_RIPEMD160 OP_RIPEMD160 9c864b8bb110c05cb9c77381ad5d6868f0fd9f9f OP_EQUAL
So this script starts with some data that gets pushed in the stack over the one provided by the scriptSig, only to be dropped right after by that OP_DROP. After that, the scriptSig gets hashed two times by RIPEMD160 and compared with a given hash. So, this script is asking for some data that, when double hashed with RIPEMD160, gives 9c864b8bb110c05cb9c77381ad5d6868f0fd9f9f. Now, back to the 6e616d... discarded data: why would someone add and drop random data to a transaction? Couldn't be that the hint we need to solve this? Why yes! I guess that anybody who ever worked with string and hexadecimal representation immediately noticed that all those bytes are in the 0x60-0x7A range, which are the a-z charaters in the ASCII table. By
decoding it you get "name of nakakamoto". No, that "kaka" is just a typo of mine, no hidden messages. As we all know, the obvious solution to this riddle is "satoshi". To test this, we just have to hash that string two times with RIPEMD160 and check the hash. Be careful! Do not simply hash the string, then copy/paste the resulting hash and rehash it the same way, because you'd be doing an hash of the string representation, and not the hash of the actual binary data. To do this you need a tool that makes a difference between string and hexadecimal input data, like
this one. Hashing first time gives
this, and the second time gives
this. Notice that the second RIPEMD160 hash is the same as in the scriptPubKey.
Now, since we know how to create a transaction with a custom scriptSig from the previous stage, the rest is trivial. Just build a transaction that spends the output ab149362ea4e119d2bc5211b35083c23ec41842af6bbc2ff3c5f1e55941199cc n=0 , and as scriptSig you just have to put the
hexadecimal ASCII representation of the string "satoshi" which is "7361746f736869".
This script shows that it's possibile to have a txout reedemed by one out of different methods, leaving the claiming user the freedom to choose which one to use. It's even possibile to set up the script so that it automatically knows which method to use for the verification, basing on the format of the scriptSig.
