> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/bitcoin-protocol-documentation/concepts/transaction-templates.md).

# Transaction Templates

A transaction template is a standard script pattern used in an output (and the corresponding unlocking script in the spending input) for a common case. Because [Script](/bitcoin-protocol-documentation/specification/script.md) is a general language, an output can impose arbitrary spending conditions; the templates below are the widely used standard forms.

### Transaction Template example : Payment to public key (hash)

"Pay-to-Public Key Hash" (P2PKH) is one of the most widely used template.

To provide some insight into what the script looks like, below is the unlocking and locking script of a P2PKH script:

<pre data-overflow="wrap"><code><strong>Previous Transaction Output
</strong>Locking Script - OP_DUP OP_HASH160 &#x3C;Public Key Hash> OP_EQUALVERIFY OP_CHECKSIG

Current Transaction Input
Unlocking Script - &#x3C;Signature> &#x3C;Public Key>

&#x3C;Signature>, &#x3C;Public Key>, &#x3C;Public Key Hash> are operands and the remaining are opcodes
Note: The opcode OP_CHECKSIG performs a digital signature verification
</code></pre>

When Alice transfers the fund to Bob, she will construct the script that will create the script shown above as the *Current Transaction Input* which along with the *Previous Transaction Output* becomes the full script that goes as input to the script engine and its execution is shown in the animation below.

<figure><img src="/files/92MizOy8aWyAtpbemhro" alt=""><figcaption></figcaption></figure>

As shown first, the operands, Alice’s signature and the public key to which the funds were locked (present in the current transaction’s input) will be put on a stack.

Then the OP\_DUP opcode is processed, which will duplicate the top item on the stack, the public key of Alice.

The next opcode is OP\_HASH160 which, when applied to the public key, produces a 160 bits hash value of the public key. It is the same value the funds would have been locked to in the previous transaction, as shown as the next operand put on the stack.

When OP\_EQUALVERIFY opcode is processed, it will take the top two items, both in this case, public key hash, and compare them; if they are equal, they are removed from the stack.

The last opcode is OP\_CHECKSIG which performs a signature verification (explained in detail in the Cryptography section) and if the signature is valid, the result, true is returned as the final output of the script execution.

Another slightly different variation of this is a P2PK or pay to public key where in place of hash the public key is used as is.

{% hint style="info" %}
The pubKeyHash in the Locking script is the public key hashed twice: first with SHA-256 and then with RIPEMD-160. A Bitcoin address is actually a pubKeyHash prepended by a version byte number and encoded in Base58Check format. In other words, we can consider a Bitcoin address is a compact representation of a public key hash puzzle.
{% endhint %}

### Transaction Template example : Multi-Signature Transactions

Also knowns as P2MS - Pay to Multi Sig transactions.

A typical transaction input requires one private key (i.e., one signature) to spend it. However, it is possible to lock coins with a requirement that more than one signature must be provided before the coins can be spent. Script offers OP\_CHECKMULTISIG opcode to implements a scenario where m private keys out of a possible n (m <= n) are required to move the coins. Transaction outputs with OP\_CHECKMULTISIG are usually denoted as Pay-to-Multi-Signature or P2MS.

For example:

Locking Script: OP\_3 \<pubKey1> \<pubKey2> \<pubKey3> \<pubKey4> \<pubKey5> OP\_5 OP\_CHECKMULTISIG

Unlocking Script: OP\_1 \<sig1> \<sig2> \<sig4>

In the above example, the scriptPubKey says that 3 out of 5 possible signatures are needed to spend the coins. The 3 signatures in the scriptSig must be placed using the same order in which the public keys are arrayed in the scriptPubKey. Note that there is an additional value OP\_1 at the beginning of the scriptSig. This value won't be evaluated (therefore, any piece of data can be used here). It is there to “fix” a bug in the current implementation of the scripting engine where OP\_CHECKMULTISIG removes not only the required parameters but also an extra unnecessary value off the stack.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://hub.bsvblockchain.org/bitcoin-protocol-documentation/concepts/transaction-templates.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.