Templates
login
{ "title": "Templates", "related":["op_template.md","op_exec.md"] }

Script Templates

Allows 3 agent (group designer, owner, and spender) trustless interaction

Problem Statement

Introduction

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.

Script Template Execution

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.

Script Template Placement

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) {SHA256(constraint) or empty stack item} 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 script, [constraint script], satisfier script

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. If the “scriptPubKey” contains an empty stack item in the 2nd push (top stack item), then the “scriptSig” field must not contain a constraint script.

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.

Advantages

  • Combined with OP_EXEC, this system allows 2 agents (the covenant author, and the output “owner”) to specify constraints/permissions via scripts.
  • All scripts are provided to the blockchain when they are executed. Therefore no scripts are stored in the UTXO database. This saves UTXO space for nontrivial scripts.
  • Addresses remain reasonable for arbitrary scripts & templates, although this is larger than the addresses we currently have. In the worst case, an address must contain 2 SHA256 numbers (the template and the constraint scripts). However, if the template is a group covenant, its value is enforced so generally does not need to be specified. If no constraint script is used it does not need to be specified.

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.