A locking script is a Script that is used dictate how funds can be spent in the future.
Locking scripts do this by defining a set of operations that must end in a successful script execution.
The rest of the script execution is to be provided in an unlocking script in a future transaction’s input.
Every locking script is executed after the unlocking script.
If the unlocking script were run second, it could end by removing any values currently on the stack and replacing it with a success value.
For more information about how script execution works, see Script.
The below locking script formats are regarded as “standard” on the Bitcoin Cash network and, as a result, are the three forms of transactions that will be relayed among nodes for mining.
It is possible to have transactions without these standard locking script formats mined into a block, but such transactions are at a disadvantage due since they will not be as widely propagated.
The P2PK locking script expects the unlocking script to push a signature to the stack.
If the signature is valid for the specified public key in the locking script, the output is allowed to be spent.
|OP_DATA_X (public key)||Add the recipient’s public key to the stack. The data pushed must be either a compressed or uncompressed public key with appropriate length (33 bytes if the key is compressed, 65 bytes if it is not) for the type for the script to be recognized as P2PK.|
|OP_CHECKSIG||Check the public key at the top of the stack against the signature below it on the stack.|
NOTE: Pay to Public Key is a largely obsolete type of locking script due to its property of leaking the public key of the recipient before the output is unlocked, resulting in:
Pay to Public Key Hash is a widely used standard locking script format, that works similarly to P2PK but instead of pushing the public key, it pushes a hash of the public key, commonly referred to as an address.
This heavily reduces the risks associated with a plain P2PK script as the hashing algorithms used provide a considerable barrier to determining the public key a priori.
To spend an output locked with this type of script, the unlocking script is expected to push a signature and then the public key corresponding to the private key that created the signature.
If that public key hashes to the expected address, and the signature is valid, the output is allowed to be spent.
|OP_DUP||Copy the value at the top of the stack (public key of the recipient).|
|OP_HASH160||Perform a SHA-256 then a RIPEMD-160 on the copied value.|
|OP_DATA_X (20 bytes)||Push the expected 20 byte address.|
|OP_EQUALVERIFY||Verify that the hash of the copied value matches the expected hash that was pushed.|
|OP_CHECKSIG||Verify that the stack now contains only a public key (which was duplicated, hashed, and checked against the expected value) and a signature and verify that the signature is valid for that public key.|
Pay to Script Hash is used to require the spender of an output to include a specific set of operations in their unlocking script.
To achieve this, the unlocking script is expected to end by pushing data to the stack that is the expected script to be executed.
Once this data is verified to match the expected script hash, this internal script, commonly referred to as the redeem script, is executed on the pre-locking-script-execution stack.
If this redeem script finishes execution successfully, the output is allowed to be spent.
|OP_HASH160||Hash the data at the top of the stack, this should be the script to be executed.|
|OP_DATA_X (20 bytes)||Push the expected redeem script hash.|
|OP_EQUAL||Verify that the hash of the provided script is equal to the expected hash.|
Due to the nature of this type of locking script, the following steps must be performed by a node executing this script:
The P2SH form places all interesting constraints in the redeem script, whereas previously these constraints were placed in the locking script.
It is arguably better to place constraints in the redeem script for several reasons:
Multiple-signature, or multisig, scripts provide a mechanism to have multiple private keys coordinate with spending funds.
For example, three people could share funds and require that for some transactions any one of them could spend it while, for others, two of them would need to agree, and for others still, all three people would need to agree to spend the funds.
Each party’s public key is included in the locking script along with the required number of signatures (i.e. from above, 1, 2, and 3, respectively).
An unlocking script is therefore expected to provide the required number of signatures which are then checked against the list of public keys. If a sufficient number of valid signatures are provided, the output is allowed to be spent.
|OP_X||Push the number of parties required to provide signatures.|
|1 or more OP_DATA_X (public key)||Push 1 or more public keys, indicating all of the parties that could provide signatures.|
|OP_X||The total number of parties added (i.e. the number of public keys pushed).|
|OP_CHECKMULTISIG||Check for signatures matching the number of required parties, verify that they correspond to permitted public keys, and that the signatures are valid.|
NOTE: due to a historical bug, the locking script must push an additional value before the signatures. Traditionally this is done via OP_0. The value is not used but is popped off of the stack by the OP_CHECKMULTISIG at the end of the locking script.
Data Output scripts are used to create outputs that are not spendable but instead are used purely to add data to a transaction.
They are made provably unspendable by immediately failing script execution.
As such, outputs locked with data scripts generally have zero satoshis associated with them.
|OP_RETURN||Fail execution immediately.|
|Data||Any additional data is not executed and thus can be whatever data is desired by the script creator.|