Allows 3 agent (group designer, owner, and spender) trustless interaction
A script template is a generalization of the P2SH (pay-to-script-hash) format, that allows for the implementation of covenants. It is perhaps conceptually difficult to understand at first, but is both easy to implement over the existing Bitcoin scripting system and is powerful.
Three scripts interact during transaction input validation, the “template”, the “constraint”, and the “satisfier” scripts.
The “satisfier” script is analogous to the traditional “scriptSig”. It is provided by the spender and pushes data onto the stack that “satisfies” the constraints enforced by other scripts.
The “constraint” script is analogous to the traditional “scriptPubKey”. It is provided by current “owner” of a UTXO to constrain future spending in manners allowed by the template. It typically consists of “scriptlets” (small scripts) pushed to the stack. The constraint script is optional (its possible that the template script allows no additional constraints).
The “template” script defines the overall structure in which the other scripts execute. It may be conserved from input to output so implements covenants. It implements any constraints (or spending permissions) defined by the Group, and decides when to delegate constraints/permissions to constraint scriptlets.
However these scripts are positioned very differently in the blockchain as compared to traditional locations.
The satisfier and constraint script are executed in separate clean stack environments. A third “template” stack environment is created.
The “main” stack from the satisfier execution is copied to the “main” template stack. The “main” stack from the constraint script is copied to the “alt” template stack. The template script is then executed.
In other words, the template script can access the result of the satisfier script on its main stack, and the result of the constraint script on its alt stack.
Execution is successful if the main stack contains a single element that evaluates to TRUE.
To indicate a template, an output’s “scriptPubKey” contains the following. This is not a script. It simply reuses the existing “scriptPubKey” field, and the PUSH opcodes to indicate data sizes.
SHA256(template) [optional SHA256(constraint)] OP_TEMPLATE => (nothing)
That an input is a template can be determined by seeing that its prevout follows the format above. If it is a template, the input’s “scriptSig” field contains the following items:
template [optional constraint] satisfier
This is not a script, but each item is a script that is placed into the existing “scriptPubKey” field as data structured by PUSH opcodes.
Perhaps at this point the reader can understand that if the optional constraint script is not used, the system reduces to something very similar to P2SH.
Note: it should be possible to hash the hash of the template and the constraint scripts to produce an address that is the same size as today. However, this would not give the blockchain the opportunity to reject an output as unspendable (covenanted output supplied wrong template). Of course, with P2SH its easy to create unspendable outputs that output to the blockchain.