If you 'unhexlify' both hex strings on that page, you can see that the first 320 bytes of each PDF from shattered.io were used as input.
In : import binascii, hashlib
In : input1 = binascii.unhexlify('255044462d312e330a25e2e3cfd30a0a0a312030206f626a0a3c3c2f57696474682032203020522f4865696768742033203020522f547970652034
In : input2 = binascii.unhexlify('255044462d312e330a25e2e3cfd30a0a0a312030206f626a0a3c3c2f57696474682032203020522f4865696768742033203020522f547970652034
In : input1[:8], input2[:8]
Out: ('%PDF-1.3', '%PDF-1.3')
In : hashlib.sha1(input1).hexdigest() == hashlib.sha1(input2).hexdigest()
You'd need a system supporting zero knowledge proofs.
ZKCP is a much more robust solution.
The script is just checking that the spender knows 2 pieces of data that are different but have the same SHA1 hash. I can't see a way to do that that can't be easily replayed by somebody else spending to a different address.
As soon as the transaction is broadcast, you reveal your 2 pieces of data that are different but have the same SHA1 hash.
(And to not put too fine a point on it: the existing track record of ethereum smart contracts suggests that if such a bounty had been created there it would have simply been stolen due to contract/vm flaws by now.)
Unless it is SHA-1 hash :)
Usually the challenge is to prove that you have the private key to a public key included in the challenge so that the public key can function as an address for you and only you can spend the coins because only you have the private key.
But in this case Peter Todd placed 2.48 BTC in the block chain with the challenge to provide two different but otherwise arbitrary pieces of data yielding the same SHA-1 hashes. Someone now used the collision generated by Google to spend those coins.
If Google had not publish the collision but you found it yourself, miners could still just steal the collision from your transaction, throw your transaction away and spend the coins themselves.
Actually everybody could just watch all new transactions, steal your collision once they see it and try to front-run you. So this kind of challenge is not really a good idea in general, at least not in this simple form.
With normal transaction this is not an issue because there you only reveal a signature proving that you know the private key, you do not reveal the private key itself and therefore others can not sign their own transaction and try to front-run you.
[...] and, as a followup challenge, something encrypted with your public key so only you can decrypt it later on.
That is not entirely correct, as mentioned above this works by signing and not encrypting. Everybody and especially miners have to be able to verify your transaction but they could not do that if you simply encrypted something. Well, they could if you published the private key but then you get into said front-running issue.
(Not pointing this out to be critical. With a bit of thought, the policy makes enough sense to me, for various reasons. Pointing this out to prevent people from doing silly things, and because it's an interesting document on its own.)