The scriptSig is:

    OP_DUP OP_HASH160 404371705fa9bd789a2fcd52d2c580b65d35549d

How did people know that this was the correct permutation of OPCodes and data?


Bitcoin Script is a programming language. As such, it is similar to other languages - You need to know what you are trying to achieve to be able to write in it.

The script you've presented is a P2PKH (pay-to-pubkey-hash) script. The goal here is to allow someone to spend Bitcoin with the corresponding private key by applying a signature. In this kind of verification, you take the input pubkey, duplicate it (OP_DUP), hash160 the duplicate (OP_HASH160), push the hashed value, check if the value you created in the first two operations matches the one you just pushed (OP_EQUALVERIFY), and finally check the signature against the original, pre-dup pubkey (OP_CHECKSIG)

Since Bitcoin Script is a stack based language, it looks a little different to the day to day ones we see (Python, Java, etc). However, it is just another programming language, and you can write code in it just the same way.

Just for reference, a similar program in a more conventional language would look something like:

verifyInputScript(signature, pubkey, outputscript):
    inputPubkeyHash160 = hash160(pubkey)
    if inputPubkeyHash160 != outputscript.hash160:
        return "Invalid"
        isSignatureValid = verifySignature(signature, pubkey)
        return isSignatureValid
  • So does that mean that the P2PKH can be written in another way? using more variables but achieving the same goal? May 6 '18 at 14:18
  • You could possibly rewrite it in a number of ways - For instance, a very simple expansion would be to split OP_HASH160 into the OP_SHA256 and OP_RIPEMD160 (hash160 is just ripemd160(sha256(x))). May 6 '18 at 14:22
  • The parameters cannot change though? Also, what's stopping me from just using OP_1 and returning true, for a scriptSig? May 6 '18 at 14:24
  • An input script is combined with the output script (the one you posted). Input scripts can only contain pushes, so any non-push would invalide the transaction right away. You can push any parameters you like, but they must validate against the output script. Using OP_1 will push 1, then duplicate it, then hash160, then equalverify it. At this point, the equalverify will fail. Moreover, even if you pushed just the pubkey, the equalverify would success, but the stack would be empty since OP_EQUALVERIFY consumes two entries, making your script fail on OP_CHECKSIG May 6 '18 at 14:27
  • 1
    Ohh I see. Thanks for the link, it makes a lot of sense now. The locking script puts items onto the stack and it is the job of the output script to make it evaluate to true. May 6 '18 at 14:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.