Bitcoin differs from most other cryptocurrencies by not including the script with the unspent transaction output on the blockchain, only the scriptPubKey is publicly viewable until spending time. The practical effects of this are:
Users wishing to sign transactions which are locked using locking scripts require two pieces of information:
The relevant private key(s)
redeemScript, i.e. the contract of the script itself.
Scripts are executed by first evaluating the unlocking script, then evaluating the locking script on the same stack. If both of these steps result in a
1 (or any other non-zero value) being the only item on the stack, the script is verified as
If any of the following are true, the script will evaluate to
The final stack is empty
The top element on the stack is
There is more than one element remaining on the stack
The script returns prematurely
There are a number of other ways which scripts can fail TODO
Bitcoin addresses can be of a "script hash" type (P2SH, and now P2WSH). As the name implies a valid script is created before being hashed. This hash is then used to generate an address which coins can be sent to. Once coins have been received to this address a (redeem / witness) script which hashes to the same hash must be provided (
scriptPubKey), along with a satisfactory
scriptSig in order to authorize a new spend.
The origins of this revolutionary (at the time) style of address are touched upon in this email from ZmnSCPxj. The general context of the email is recursive covenants. A portion of the email is quoted below for convenience:
Covenants were first expressed as a possibility, I believe, during discussions around P2SH. Basically, at the time, the problem was this:
Some receivers wanted to use k-of-n multisignature for improved security.
The only way to implement this, pre-P2SH, was by putting in the
scriptPubKeyall the public keys.
The sender is the one paying for the size of the
It was considered unfair that the sender is paying for the security of the receiver.
OP_EVALand the P2SH concept was conceived. Instead of the
scriptPubKeycontaining the k-of-n multisignature, you create a separate script containing the public keys, then hash it, and the
scriptPubKeywould contain the hash of the script. By symmetry with the P2PKH template:
OP_DUP OP_HASH160 <hash160(pubkey)> OP_EQUALVERIFY OP_CHECKSIG
The P2SH template would be:
OP_DUP OP_HASH160 <hash160(redeemScript)> OP_EQUALVERIFY OP_EVAL
OP_EVALwould take the stack top vector and treat it as a Bitcoin SCRIPT.
It was then pointed out that
OP_EVALcould be used to create recursive SCRIPTs by quining using
OP_CATwas already disabled by then, but people were talking about re-enabling it somehow by restricting the output size of
OP_CATto limit the O(2^N) behavior.
Thus, since then,
OP_CAThas been associated with recursive covenants (and people are now reluctant to re-enable it even with a limit on its output size, because recursive covenants). In particular,
OP_CATin combination with
OP_CHECKSIG, you could get a deferred
OP_EVALand then use
OP_CATtoo to quine.
Because of those concerns, the modern P2SH is now "just a template" with an implicit
redeemScript, but without any
OP_EVALbeing actually enabled.
For more details refer to BIP16 which introduced P2SH addresses.