---
title: Transactions
description: "# Transactions Transactions let users spend [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/). Each transaction is constructed out of several parts which enable both simple direct payments and complex transactions. ## Introduction This section will describe each part and demonstrate how to use them together to…"
url: "https://bitcoindevelopers.org/docs/developer-guides/transactions/"
updated: "2025-05-13"
category: Developer Guides
---

# Transactions

# Transactions

Transactions let users spend [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/). Each transaction is constructed out of several parts which enable both simple direct payments and complex transactions.

## Introduction

This section will describe each part and demonstrate how to use them together to build complete transactions.

To keep things simple, this section pretends [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transactions do not exist. [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transactions can only be created by Bitcoin miners and they’re an exception to many of the rules listed below. Instead of pointing out the [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) exception to each rule, we invite you to read about [Coinbase](https://bitcoindevelopers.org/encyclopedia/coinbase/) transactions in the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain section of this guide.

  ![The Parts Of A Transaction](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-tx-overview.svg)

The Parts Of A Transaction

The figure above shows the main parts of a Bitcoin transaction. Each transaction has at least one [Input](https://bitcoindevelopers.org/encyclopedia/input/) and one [Output](https://bitcoindevelopers.org/encyclopedia/output/). Each [Input](https://bitcoindevelopers.org/encyclopedia/input/) spends the [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) paid to a previous [Output](https://bitcoindevelopers.org/encyclopedia/output/). Each [Output](https://bitcoindevelopers.org/encyclopedia/output/) then waits as an Unspent Transaction [Output](https://bitcoindevelopers.org/encyclopedia/output/) ([UTXO](https://bitcoindevelopers.org/encyclopedia/utxo/)) until a later [Input](https://bitcoindevelopers.org/encyclopedia/input/) spends it. When your Bitcoin [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) tells you that you have a 10,000 satoshi balance, it really means that you have 10,000 [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) waiting in one or more UTXOs.

Each transaction is prefixed by a four-byte [Transaction version number](https://bitcoindevelopers.org/encyclopedia/transaction-version-number/) which tells Bitcoin peers and miners which set of rules to use to validate it. This lets developers create new rules for future transactions without invalidating previous transactions.

  ![Spending An Output](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-tx-overview-spending.svg)

Spending An [Output](https://bitcoindevelopers.org/encyclopedia/output/)

An [Output](https://bitcoindevelopers.org/encyclopedia/output/) has an implied index number based on its location in the transaction—the index of the first [Output](https://bitcoindevelopers.org/encyclopedia/output/) is zero. The [Output](https://bitcoindevelopers.org/encyclopedia/output/) also has an amount in [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) which it pays to a conditional [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/). Anyone who can satisfy the conditions of that [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) can spend up to the amount of [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) paid to it.

An [Input](https://bitcoindevelopers.org/encyclopedia/input/) uses a transaction identifier ([Txid](https://bitcoindevelopers.org/encyclopedia/txid/)) and an [Output index](https://bitcoindevelopers.org/encyclopedia/output-index/) number (often called “vout” for [Output](https://bitcoindevelopers.org/encyclopedia/output/) vector) to identify a particular [Output](https://bitcoindevelopers.org/encyclopedia/output/) to be spent. It also has a [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script which allows it to provide data parameters that satisfy the conditionals in the [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/). (The [Sequence number](https://bitcoindevelopers.org/encyclopedia/sequence-number/) and [Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/) are related and will be covered together in a later subsection.)

The figures below help illustrate how these features are used by showing the workflow Alice uses to send Bob a transaction and which Bob later uses to spend that transaction. Both Alice and Bob will use the most common form of the standard Pay-To-Public-Key-Hash (P2PKH) transaction type. P2PKH lets Alice spend [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) to a typical Bitcoin [Address](https://bitcoindevelopers.org/encyclopedia/address/), and then lets Bob further spend those [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) using a simple cryptographic [Key pair](https://bitcoindevelopers.org/encyclopedia/key-pair/).

  ![Creating A P2PKH Public Key Hash To Receive Payment](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-creating-p2pkh-output.svg)

Creating A P2PKH [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) Hash To Receive Payment

Bob must first generate a private/[Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) pair before Alice can create the first transaction. Bitcoin uses the Elliptic Curve Digital [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) Algorithm (ECDSA) with the secp256k1 curve; secp256k1 private keys are 256 bits of random data. A copy of that data is deterministically transformed into an secp256k1 [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/). Because the transformation can be reliably repeated later, the [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) does not need to be stored.

The [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) (pubkey) is then cryptographically hashed. This pubkey hash can also be reliably repeated later, so it also does not need to be stored. The hash shortens and obfuscates the [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/), making manual transcription easier and providing security against unanticipated problems which might allow reconstruction of private keys from [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) data at some later point.

Bob provides the pubkey hash to Alice. Pubkey hashes are almost always sent encoded as Bitcoin addresses, which are base58-encoded strings containing an [Address](https://bitcoindevelopers.org/encyclopedia/address/) version number, the hash, and an error-detection checksum to catch typos. The [Address](https://bitcoindevelopers.org/encyclopedia/address/) can be transmitted through any medium, including one-way mediums which prevent the spender from communicating with the receiver, and it can be further encoded into another format, such as a QR code containing a “bitcoin:” URI.

Once Alice has the [Address](https://bitcoindevelopers.org/encyclopedia/address/) and decodes it back into a standard hash, she can create the first transaction. She creates a standard P2PKH transaction [Output](https://bitcoindevelopers.org/encyclopedia/output/) containing instructions which allow anyone to spend that [Output](https://bitcoindevelopers.org/encyclopedia/output/) if they can prove they control the [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) corresponding to Bob’s hashed [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/). These instructions are called the [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) or [ScriptPubKey](https://bitcoindevelopers.org/encyclopedia/scriptpubkey/).

Alice broadcasts the transaction and it is added to the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain. The network categorizes it as an Unspent Transaction [Output](https://bitcoindevelopers.org/encyclopedia/output/) ([UTXO](https://bitcoindevelopers.org/encyclopedia/utxo/)), and Bob’s [Wallet](https://bitcoindevelopers.org/encyclopedia/wallet/) software displays it as a spendable balance.

When, some time later, Bob decides to spend the [UTXO](https://bitcoindevelopers.org/encyclopedia/utxo/), he must create an [Input](https://bitcoindevelopers.org/encyclopedia/input/) which references the transaction Alice created by its hash, called a Transaction Identifier ([Txid](https://bitcoindevelopers.org/encyclopedia/txid/)), and the specific [Output](https://bitcoindevelopers.org/encyclopedia/output/) she used by its index number ([Output index](https://bitcoindevelopers.org/encyclopedia/output-index/)). He must then create a [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script—a collection of data parameters which satisfy the conditions Alice placed in the previous [Output](https://bitcoindevelopers.org/encyclopedia/output/)’s [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/). [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) scripts are also called scriptSigs.

Pubkey scripts and [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) scripts combine secp256k1 pubkeys and signatures with conditional logic, creating a programmable authorization mechanism.

  ![Unlocking A P2PKH Output For Spending](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-unlocking-p2pkh-output.svg)

Unlocking A P2PKH [Output](https://bitcoindevelopers.org/encyclopedia/output/) For Spending

For a P2PKH-style [Output](https://bitcoindevelopers.org/encyclopedia/output/), Bob’s [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script will contain the following two pieces of data:

1. His full (unhashed) [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/), so the [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) can check that it hashes to the same value as the pubkey hash provided by Alice.
2. An secp256k1 [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) made by using the ECDSA cryptographic formula to combine certain transaction data (described below) with Bob’s [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/). This lets the [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) verify that Bob owns the [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/) which created the [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/).

Bob’s secp256k1 [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) doesn’t just prove Bob controls his [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/); it also makes the non-[Signature](https://bitcoindevelopers.org/encyclopedia/signature/)-script parts of his transaction tamper-proof so Bob can safely broadcast them over the [Peer](https://bitcoindevelopers.org/encyclopedia/peer/)-to-[Peer](https://bitcoindevelopers.org/encyclopedia/peer/) network.

  ![Some Things Signed When Spending An Output](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-signing-output-to-spend.svg)

Some Things Signed When Spending An [Output](https://bitcoindevelopers.org/encyclopedia/output/)

As illustrated in the figure above, the data Bob signs includes the [Txid](https://bitcoindevelopers.org/encyclopedia/txid/) and [Output index](https://bitcoindevelopers.org/encyclopedia/output-index/) of the previous transaction, the previous [Output](https://bitcoindevelopers.org/encyclopedia/output/)’s [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/), the [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) Bob creates which will let the next recipient spend this transaction’s [Output](https://bitcoindevelopers.org/encyclopedia/output/), and the amount of [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) to spend to the next recipient. In essence, the entire transaction is signed except for any [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) scripts, which hold the full public keys and secp256k1 signatures.

After putting his [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) and [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) in the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script, Bob broadcasts the transaction to Bitcoin miners through the [Peer](https://bitcoindevelopers.org/encyclopedia/peer/)-to-[Peer](https://bitcoindevelopers.org/encyclopedia/peer/) network. Each [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) and [Miner](https://bitcoindevelopers.org/encyclopedia/miner/) independently validates the transaction before broadcasting it further or attempting to include it in a new [Block](https://bitcoindevelopers.org/encyclopedia/block/) of transactions.

## P2PKH Script Validation

The validation procedure requires evaluation of the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script and [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/). In a P2PKH [Output](https://bitcoindevelopers.org/encyclopedia/output/), the [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) is:

```
OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
```

The spender’s [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script is evaluated and prefixed to the beginning of the script. In a P2PKH transaction, the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script contains an secp256k1 [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) (sig) and full [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) (pubkey), creating the following concatenation:

```
<Sig> <PubKey> OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG
```

The script language is a Forth-like stack-based language deliberately designed to be stateless and not Turing complete. Statelessness ensures that once a transaction is added to the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain, there is no condition which renders it permanently unspendable. Turing-incompleteness (specifically, a lack of loops or gotos) makes the script language less flexible and more predictable, greatly simplifying the security model.

To test whether the transaction is valid, [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script and [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) operations are executed one item at a time, starting with Bob’s [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script and continuing to the end of Alice’s [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/). The figure below shows the evaluation of a standard P2PKH [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/); below the figure is a description of the process.

  ![P2PKH Stack Evaluation](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-p2pkh-stack.svg)

P2PKH Stack Evaluation

- The [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) (from Bob’s [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script) is added (pushed) to an empty stack. Because it’s just data, nothing is done except adding it to the stack. The [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) (also from the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script) is pushed on top of the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/).
- From Alice’s [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/), the “OP_DUP” operation is executed. “OP_DUP” pushes onto the stack a copy of the data currently at the top of it—in this case creating a copy of the [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) Bob provided.
- The operation executed next, “OP_HASH160”, pushes onto the stack a hash of the data currently on top of it—in this case, Bob’s [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/). This creates a hash of Bob’s [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/).
- Alice’s [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) then pushes the pubkey hash that Bob gave her for the first transaction. At this point, there should be two copies of Bob’s pubkey hash at the top of the stack.
- Now it gets interesting: Alice’s [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) executes “OP_EQUALVERIFY”. “OP_EQUALVERIFY” is equivalent to executing “OP_EQUAL” followed by “OP_VERIFY” (not shown).

  “OP_EQUAL” (not shown) checks the two values at the top of the stack; in this case, it checks whether the pubkey hash generated from the full [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) Bob provided equals the pubkey hash Alice provided when she created transaction #1. “OP_EQUAL” pops (removes from the top of the stack) the two values it compared, and replaces them with the result of that comparison: zero (*false*) or one (*true*).

  “OP_VERIFY” (not shown) checks the value at the top of the stack. If the value is *false* it immediately terminates evaluation and the transaction validation fails. Otherwise it pops the *true* value off the stack.
- Finally, Alice’s [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) executes “OP_CHECKSIG”, which checks the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) Bob provided against the now-authenticated [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) he also provided. If the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) matches the [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) and was generated using all of the data required to be signed, “OP_CHECKSIG” pushes the value *true* onto the top of the stack.

If *false* is not at the top of the stack after the [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) has been evaluated, the transaction is valid (provided there are no other problems with it).

## P2SH Scripts

Pubkey scripts are created by spenders who have little interest what that script does. Receivers do care about the script conditions and, if they want, they can ask spenders to use a particular [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/). Unfortunately, custom pubkey scripts are less convenient than short Bitcoin addresses and there was no standard way to communicate them between programs prior to widespread implementation of the now deprecated BIP70 [Payment protocol](https://bitcoindevelopers.org/encyclopedia/payment-protocol/) discussed later.

To solve these problems, pay-to-script-hash (P2SH) transactions were created in 2012 to let a spender create a [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) containing a hash of a second script, the [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/).

The basic P2SH workflow, illustrated below, looks almost identical to the P2PKH workflow. Bob creates a [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/) with whatever script he wants, hashes the [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/), and provides the [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/) hash to Alice. Alice creates a P2SH-style [Output](https://bitcoindevelopers.org/encyclopedia/output/) containing Bob’s [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/) hash.

  ![Creating A P2SH Redeem Script And Hash](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-creating-p2sh-output.svg)

Creating A P2SH [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/) And Hash

When Bob wants to spend the [Output](https://bitcoindevelopers.org/encyclopedia/output/), he provides his [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) along with the full (serialized) [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/) in the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script. The [Peer](https://bitcoindevelopers.org/encyclopedia/peer/)-to-[Peer](https://bitcoindevelopers.org/encyclopedia/peer/) network ensures the full [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/) hashes to the same value as the script hash Alice put in her [Output](https://bitcoindevelopers.org/encyclopedia/output/); it then processes the [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/) exactly as it would if it were the primary [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/), letting Bob spend the [Output](https://bitcoindevelopers.org/encyclopedia/output/) if the [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/) does not return false.

  ![Unlocking A P2SH Output For Spending](https://bitcoindevelopers.org/wp-content/uploads/2025/05/en-unlocking-p2sh-output.svg)

Unlocking A P2SH [Output](https://bitcoindevelopers.org/encyclopedia/output/) For Spending

The hash of the [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/) has the same properties as a pubkey hash—so it can be transformed into the standard Bitcoin [Address](https://bitcoindevelopers.org/encyclopedia/address/) format with only one small change to differentiate it from a standard [Address](https://bitcoindevelopers.org/encyclopedia/address/). This makes collecting a P2SH-style [Address](https://bitcoindevelopers.org/encyclopedia/address/) as simple as collecting a P2PKH-style [Address](https://bitcoindevelopers.org/encyclopedia/address/). The hash also obfuscates any public keys in the [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/), so P2SH scripts are as secure as P2PKH pubkey hashes.

## Standard Transactions

After the discovery of several dangerous bugs in early versions of Bitcoin, a test was added which only accepted transactions from the network if their pubkey scripts and [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) scripts matched a small set of believed-to-be-safe templates, and if the rest of the transaction didn’t violate another small set of rules enforcing good network behavior. This is the `IsStandard()` test, and transactions which pass it are called standard transactions.

Non-standard transactions—those that fail the test—may be accepted by nodes not using the default Bitcoin Core settings. If they are included in blocks, they will also avoid the IsStandard test and be processed.

Besides making it more difficult for someone to attack Bitcoin for free by broadcasting harmful transactions, the [Standard Transaction](https://bitcoindevelopers.org/encyclopedia/standard-transaction/) test also helps prevent users from creating transactions today that would make adding new transaction features in the future more difficult. For example, as described above, each transaction includes a version number—if users started arbitrarily changing the version number, it would become useless as a tool for introducing backwards-incompatible features.

As of Bitcoin Core 0.9, the standard [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) types are:

- Pay To [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) Hash (P2PKH)
- Pay To Script Hash (P2SH)
- [Multisig](https://bitcoindevelopers.org/encyclopedia/multisig/)
- Pubkey
- Null Data

### Pay To [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) Hash (P2PKH)

P2PKH is the most common form of [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) used to send a transaction to one or multiple Bitcoin addresses.

```
Pubkey script: OP_DUP OP_HASH160 <PubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
Signature script: <sig> <pubkey>
```

### Pay To Script Hash (P2SH)

P2SH is used to send a transaction to a script hash. Each of the standard pubkey scripts can be used as a P2SH [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/), excluding P2SH itself. As of Bitcoin Core 0.9.2, P2SH transactions can contain any valid [RedeemScript](https://bitcoindevelopers.org/encyclopedia/redeemscript/), making the P2SH standard much more flexible and allowing for experimentation with many novel and complex types of transactions. The most common use of P2SH is the standard [Multisig](https://bitcoindevelopers.org/encyclopedia/multisig/) [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/), with the second most common use being the Open Assets Protocol.

Another common [RedeemScript](https://bitcoindevelopers.org/encyclopedia/redeemscript/) used for P2SH is storing textual data on the blockchain. The first bitcoin transaction ever made included text, and P2SH is a convenient method of storing text on the blockchain as its possible to store up to 1.5kb of text data. An example of storing text on the blockchain using P2SH can be found in this repository.

```
Pubkey script: OP_HASH160 <Hash160(RedeemScript)> OP_EQUAL
Signature script: <sig> [sig] [sig...] <RedeemScript>
```

This script combination looks perfectly fine to old nodes as long as the script hash matches the [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/). However, after the soft [Fork](https://bitcoindevelopers.org/encyclopedia/fork/) is activated, new nodes will perform a further verification for the [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/). They will extract the [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/) from the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script, decode it, and execute it with the remaining stack items(<sig> [sig] [sig..]part). Therefore, to redeem a P2SH transaction, the spender must provide the valid [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) or answer in addition to the correct [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/).

This last step is similar to the verification step in P2PKH or P2Multisig scripts, where the initial part of the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script(<sig> [sig] [sig..]) acts as the “[Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script” in P2PKH/P2Multisig, and the [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/) acts as the “[Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/)”.

### [Multisig](https://bitcoindevelopers.org/encyclopedia/multisig/)

Although [P2SH multisig](https://bitcoindevelopers.org/encyclopedia/p2sh-multisig/) is now generally used for [Multisig](https://bitcoindevelopers.org/encyclopedia/multisig/) transactions, this base script can be used to require multiple signatures before a [UTXO](https://bitcoindevelopers.org/encyclopedia/utxo/) can be spent.

In [Multisig](https://bitcoindevelopers.org/encyclopedia/multisig/) pubkey scripts, called m-of-n, *m* is the *minimum* number of signatures which must match a [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/); *n* is the *number* of public keys being provided. Both *m* and *n* should be opcodes `OP_1` through `OP_16`, corresponding to the number desired.

Because of an off-by-one error in the original Bitcoin implementation which must be preserved for compatibility, “OP_CHECKMULTISIG” consumes one more value from the stack than indicated by *m*, so the list of secp256k1 signatures in the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script must be prefaced with an extra value (`OP_0`) which will be consumed but not used.

The [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script must provide signatures in the same order as the corresponding public keys appear in the [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) or [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/). See the description in “OP_CHECKMULTISIG” for details.

```
Pubkey script: <m> <A pubkey> [B pubkey] [C pubkey...] <n> OP_CHECKMULTISIG
Signature script: OP_0 <A sig> [B sig] [C sig...]
```

Although it’s not a separate transaction type, this is a [P2SH multisig](https://bitcoindevelopers.org/encyclopedia/p2sh-multisig/) with 2-of-3:

```
Pubkey script: OP_HASH160 <Hash160(RedeemScript)> OP_EQUAL
Redeem script: <OP_2> <A pubkey> <B pubkey> <C pubkey> <OP_3> OP_CHECKMULTISIG
Signature script: OP_0 <A sig> <C sig> <RedeemScript>
```

### Pubkey

Pubkey outputs are a simplified form of the P2PKH [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/), but they aren’t as secure as P2PKH, so they generally aren’t used in new transactions anymore.

```
Pubkey script: <pubkey> OP_CHECKSIG
Signature script: <sig>
```

### Null Data

[Null data transaction](https://bitcoindevelopers.org/encyclopedia/null-data-transaction/) type relayed and mined by default in Bitcoin Core 0.9.0 and later that adds arbitrary data to a provably unspendable [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) that full nodes don’t have to store in their [UTXO](https://bitcoindevelopers.org/encyclopedia/utxo/) database. It is preferable to use null data transactions over transactions that bloat the [UTXO](https://bitcoindevelopers.org/encyclopedia/utxo/) database because they cannot be automatically pruned; however, it is usually even more preferable to store data outside transactions if possible.

[Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/) allow null data outputs up to the maximum allowed [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) size of 10,000 bytes provided they follow all other [Consensus rules](https://bitcoindevelopers.org/encyclopedia/consensus-rules/), such as not having any data pushes larger than 520 bytes.

Bitcoin Core 0.9.x to 0.10.x will, by default, relay and mine null data transactions with up to 40 bytes in a single data push and only one null data [Output](https://bitcoindevelopers.org/encyclopedia/output/) that pays exactly 0 [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/):

```
Pubkey script: OP_RETURN <0 to 40 bytes of data>
(Null data scripts cannot be spent, so there's no Signature script.)
```

Bitcoin Core 0.11.x increases this default to 80 bytes, with the other rules remaining the same.

Bitcoin Core 0.12.0 defaults to relaying and [Mining](https://bitcoindevelopers.org/encyclopedia/mining/) null data outputs with up to 83 bytes with any number of data pushes, provided the total byte limit is not exceeded. There must still only be a single null data [Output](https://bitcoindevelopers.org/encyclopedia/output/) and it must still pay exactly 0 [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/).

The `-datacarriersize` Bitcoin Core configuration option allows you to set the maximum number of bytes in null data outputs that you will relay or mine.

### Non-Standard Transactions

If you use anything besides a standard [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) in an [Output](https://bitcoindevelopers.org/encyclopedia/output/), peers and miners using the default Bitcoin Core settings will neither accept, broadcast, nor mine your transaction. When you try to broadcast your transaction to a [Peer](https://bitcoindevelopers.org/encyclopedia/peer/) running the default settings, you will receive an error.

If you create a [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/), hash it, and use the hash in a P2SH [Output](https://bitcoindevelopers.org/encyclopedia/output/), the network sees only the hash, so it will accept the [Output](https://bitcoindevelopers.org/encyclopedia/output/) as valid no matter what the [Redeem script](https://bitcoindevelopers.org/encyclopedia/redeem-script/) says. This allows payment to non-standard scripts, and as of Bitcoin Core 0.11, almost all valid redeem scripts can be spent. The exception is scripts that use unassigned NOP opcodes; these opcodes are reserved for future soft forks and can only be relayed or mined by nodes that don’t follow the standard mempool policy.

Note: standard transactions are designed to protect and help the network, not prevent you from making mistakes. It’s easy to create standard transactions which make the [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) sent to them unspendable.

As of Bitcoin Core 0.9.3, standard transactions must also meet the following conditions:

- The transaction must be finalized: either its [Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/) must be in the past (or less than or equal to the current [Block height](https://bitcoindevelopers.org/encyclopedia/block-height/)), or all of its sequence numbers must be 0xffffffff.
- The transaction must be smaller than 100,000 bytes. That’s around 200 times larger than a typical single-[Input](https://bitcoindevelopers.org/encyclopedia/input/), single-[Output](https://bitcoindevelopers.org/encyclopedia/output/) P2PKH transaction.
- Each of the transaction’s [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) scripts must be smaller than 1,650 bytes. That’s large enough to allow 15-of-15 [Multisig](https://bitcoindevelopers.org/encyclopedia/multisig/) transactions in P2SH using compressed public keys.
- Bare (non-P2SH) [Multisig](https://bitcoindevelopers.org/encyclopedia/multisig/) transactions which require more than 3 public keys are currently non-standard.
- The transaction’s [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script must only push data to the script evaluation stack. It cannot push new opcodes, with the exception of opcodes which solely push data to the stack.
- The transaction must not include any outputs which receive fewer than 1/3 as many [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) as it would take to spend it in a typical [Input](https://bitcoindevelopers.org/encyclopedia/input/). That’s currently 546 [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) for a P2PKH or P2SH [Output](https://bitcoindevelopers.org/encyclopedia/output/) on a Bitcoin Core [Node](https://bitcoindevelopers.org/encyclopedia/node/) with the default [Relay fee](https://bitcoindevelopers.org/encyclopedia/relay-fee/). Exception: standard null data outputs must receive zero [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/).

## [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) Hash Types

“OP_CHECKSIG” extracts a non-stack argument from each [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) it evaluates, allowing the signer to decide which parts of the transaction to sign. Since the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) protects those parts of the transaction from modification, this lets signers selectively choose to let other people modify their transactions.

The various options for what to sign are called [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) hash types. There are three base [Sighash](https://bitcoindevelopers.org/encyclopedia/sighash/) types currently available:

- “[SIGHASH_ALL](https://bitcoindevelopers.org/encyclopedia/sighash_all/)”, the default, signs all the inputs and outputs, protecting everything except the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) scripts against modification.
- “[SIGHASH_NONE](https://bitcoindevelopers.org/encyclopedia/sighash_none/)” signs all of the inputs but none of the outputs, allowing anyone to change where the [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) are going unless other signatures using other [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) hash flags protect the outputs.
- “[SIGHASH_SINGLE](https://bitcoindevelopers.org/encyclopedia/sighash_single/)” the only [Output](https://bitcoindevelopers.org/encyclopedia/output/) signed is the one corresponding to this [Input](https://bitcoindevelopers.org/encyclopedia/input/) (the [Output](https://bitcoindevelopers.org/encyclopedia/output/) with the same [Output index](https://bitcoindevelopers.org/encyclopedia/output-index/) number as this [Input](https://bitcoindevelopers.org/encyclopedia/input/)), ensuring nobody can change your part of the transaction but allowing other signers to change their part of the transaction. The corresponding [Output](https://bitcoindevelopers.org/encyclopedia/output/) must exist or the value “1” will be signed, breaking the security scheme. This [Input](https://bitcoindevelopers.org/encyclopedia/input/), as well as other inputs, are included in the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/). The sequence numbers of other inputs are not included in the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/), and can be updated.

The base types can be modified with the “[SIGHASH_ANYONECANPAY](https://bitcoindevelopers.org/encyclopedia/sighash_anyonecanpay/)” (anyone can pay) flag, creating three new combined types:

- `SIGHASH_ALL|SIGHASH_ANYONECANPAY` signs all of the outputs but only this one [Input](https://bitcoindevelopers.org/encyclopedia/input/), and it also allows anyone to add or remove other inputs, so anyone can contribute additional [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) but they cannot change how many [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) are sent nor where they go.
- `SIGHASH_NONE|SIGHASH_ANYONECANPAY` signs only this one [Input](https://bitcoindevelopers.org/encyclopedia/input/) and allows anyone to add or remove other inputs or outputs, so anyone who gets a copy of this [Input](https://bitcoindevelopers.org/encyclopedia/input/) can spend it however they’d like.
- `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` signs this one [Input](https://bitcoindevelopers.org/encyclopedia/input/) and its corresponding [Output](https://bitcoindevelopers.org/encyclopedia/output/). Allows anyone to add or remove other inputs.

Because each [Input](https://bitcoindevelopers.org/encyclopedia/input/) is signed, a transaction with multiple inputs can have multiple [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) hash types signing different parts of the transaction. For example, a single-[Input](https://bitcoindevelopers.org/encyclopedia/input/) transaction signed with `NONE` could have its [Output](https://bitcoindevelopers.org/encyclopedia/output/) changed by the [Miner](https://bitcoindevelopers.org/encyclopedia/miner/) who adds it to the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain. On the other hand, if a two-[Input](https://bitcoindevelopers.org/encyclopedia/input/) transaction has one [Input](https://bitcoindevelopers.org/encyclopedia/input/) signed with `NONE` and one [Input](https://bitcoindevelopers.org/encyclopedia/input/) signed with `ALL`, the `ALL` signer can choose where to spend the [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) without consulting the `NONE` signer—but nobody else can modify the transaction.

## [Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/) And [Sequence number](https://bitcoindevelopers.org/encyclopedia/sequence-number/)

One thing all [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) hash types sign is the transaction’s [Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/). (Called [nLockTime](https://bitcoindevelopers.org/encyclopedia/nlocktime/) in the Bitcoin Core source code.) The [Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/) indicates the earliest time a transaction can be added to the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain.

[Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/) allows signers to create time-locked transactions which will only become valid in the future, giving the signers a chance to change their minds.

If any of the signers change their mind, they can create a new non-[Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/) transaction. The new transaction will use, as one of its inputs, one of the same outputs which was used as an [Input](https://bitcoindevelopers.org/encyclopedia/input/) to the [Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/) transaction. This makes the [Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/) transaction invalid if the new transaction is added to the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain before the time lock expires.

Care must be taken near the expiry time of a time lock. The [Peer](https://bitcoindevelopers.org/encyclopedia/peer/)-to-[Peer](https://bitcoindevelopers.org/encyclopedia/peer/) network allows [Block](https://bitcoindevelopers.org/encyclopedia/block/) time to be up to two hours ahead of real time, so a [Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/) transaction can be added to the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain up to two hours before its time lock officially expires. Also, blocks are not created at guaranteed intervals, so any attempt to cancel a valuable transaction should be made a few hours before the time lock expires.

Previous versions of Bitcoin Core provided a feature which prevented transaction signers from using the method described above to cancel a time-locked transaction, but a necessary part of this feature was disabled to prevent denial of service attacks. A legacy of this system are four-byte sequence numbers in every [Input](https://bitcoindevelopers.org/encyclopedia/input/). Sequence numbers were meant to allow multiple signers to agree to update a transaction; when they finished updating the transaction, they could agree to set every [Input](https://bitcoindevelopers.org/encyclopedia/input/)’s [Sequence number](https://bitcoindevelopers.org/encyclopedia/sequence-number/) to the four-byte unsigned maximum (0xffffffff), allowing the transaction to be added to a [Block](https://bitcoindevelopers.org/encyclopedia/block/) even if its time lock had not expired.

Even today, setting all sequence numbers to 0xffffffff (the default in Bitcoin Core) can still disable the time lock, so if you want to use [Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/), at least one [Input](https://bitcoindevelopers.org/encyclopedia/input/) must have a [Sequence number](https://bitcoindevelopers.org/encyclopedia/sequence-number/) below the maximum. Since sequence numbers are not used by the network for any other purpose, setting any [Sequence number](https://bitcoindevelopers.org/encyclopedia/sequence-number/) to zero is sufficient to enable [Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/).

[Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/) itself is an unsigned 4-byte integer which can be parsed two ways:

- If less than 500 million, [Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/) is parsed as a [Block height](https://bitcoindevelopers.org/encyclopedia/block-height/). The transaction can be added to any [Block](https://bitcoindevelopers.org/encyclopedia/block/) which has this [Height](https://bitcoindevelopers.org/encyclopedia/height/) or higher.
- If greater than or equal to 500 million, [Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/) is parsed using the Unix epoch time format (the number of seconds elapsed since 1970-01-01T00:00 UTC—currently over 1.395 billion). The transaction can be added to any [Block](https://bitcoindevelopers.org/encyclopedia/block/) whose [Block](https://bitcoindevelopers.org/encyclopedia/block/) time is greater than the [Locktime](https://bitcoindevelopers.org/encyclopedia/locktime/).

## Transaction Fees And Change

Transactions pay fees based on the total byte size of the signed transaction. Fees per byte are calculated based on current demand for space in mined blocks with fees rising as demand increases. The [Transaction fee](https://bitcoindevelopers.org/encyclopedia/transaction-fee/) is given to the Bitcoin [Miner](https://bitcoindevelopers.org/encyclopedia/miner/), as explained in the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain section, and so it is ultimately up to each [Miner](https://bitcoindevelopers.org/encyclopedia/miner/) to choose the minimum [Transaction fee](https://bitcoindevelopers.org/encyclopedia/transaction-fee/) they will accept.

There is also a concept of so-called “high-priority transactions” which spend [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) that have not moved for a long time.

In the past, these “priority” transaction were often exempt from the normal fee requirements. Before Bitcoin Core 0.12, 50 KB of each [Block](https://bitcoindevelopers.org/encyclopedia/block/) would be reserved for these high-priority transactions, however this is now set to 0 KB by default. After the priority area, all transactions are prioritized based on their fee per byte, with higher-paying transactions being added in sequence until all of the available space is filled.

As of Bitcoin Core 0.9, a minimum fee (currently 1,000 [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/)) has been required to broadcast a transaction across the network. Any transaction paying only the minimum fee should be prepared to wait a long time before there’s enough spare space in a [Block](https://bitcoindevelopers.org/encyclopedia/block/) to include it. Please see the verifying payment section for why this could be important.

Since each transaction spends Unspent Transaction Outputs (UTXOs) and because a [UTXO](https://bitcoindevelopers.org/encyclopedia/utxo/) can only be spent once, the full value of the included UTXOs must be spent or given to a [Miner](https://bitcoindevelopers.org/encyclopedia/miner/) as a [Transaction fee](https://bitcoindevelopers.org/encyclopedia/transaction-fee/). Few people will have UTXOs that exactly match the amount they want to pay, so most transactions include a change [Output](https://bitcoindevelopers.org/encyclopedia/output/).

Change outputs are regular outputs which spend the surplus [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) from the UTXOs back to the spender. They can reuse the same P2PKH pubkey hash or P2SH script hash as was used in the [UTXO](https://bitcoindevelopers.org/encyclopedia/utxo/), but for the reasons described in the next subsection, it is highly recommended that change outputs be sent to a new P2PKH or P2SH [Address](https://bitcoindevelopers.org/encyclopedia/address/).

## Avoiding Key Reuse

In a transaction, the spender and receiver each reveal to each other all public keys or addresses used in the transaction. This allows either person to use the public [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain to track past and future transactions involving the other person’s same public keys or addresses.

If the same [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) is reused often, as happens when people use Bitcoin addresses (hashed public keys) as static payment addresses, other people can easily track the receiving and spending habits of that person, including how many [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) they control in known addresses.

It doesn’t have to be that way. If each [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) is used exactly twice—once to receive a payment and once to spend that payment—the user can gain a significant amount of financial privacy.

Even better, using new public keys or unique addresses when accepting payments or creating change outputs can be combined with other techniques discussed later, such as CoinJoin or [Merge avoidance](https://bitcoindevelopers.org/encyclopedia/merge-avoidance/), to make it extremely difficult to use the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain by itself to reliably track how users receive and spend their [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/).

Avoiding key reuse can also provide security against attacks which might allow reconstruction of private keys from public keys (hypothesized) or from [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) comparisons (possible today under certain circumstances described below, with more general attacks hypothesized).

1. Unique (non-reused) P2PKH and P2SH addresses protect against the first type of attack by keeping ECDSA public keys hidden (hashed) until the first time [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) sent to those addresses are spent, so attacks are effectively useless unless they can reconstruct private keys in less than the hour or two it takes for a transaction to be well protected by the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain.
2. Unique (non-reused) private keys protect against the second type of attack by only generating one [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) per [Private key](https://bitcoindevelopers.org/encyclopedia/private-key/), so attackers never get a subsequent [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) to use in comparison-based attacks. Existing comparison-based attacks are only practical today when insufficient entropy is used in signing or when the entropy used is exposed by some means, such as a side-channel attack.

So, for both privacy and security, we encourage you to build your applications to avoid [Public key](https://bitcoindevelopers.org/encyclopedia/public-key/) reuse and, when possible, to discourage users from reusing addresses. If your application needs to provide a fixed URI to which payments should be sent, please see the “bitcoin:” URI section below.

## [Transaction malleability](https://bitcoindevelopers.org/encyclopedia/transaction-malleability/)

None of Bitcoin’s [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) hash types protect the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script, leaving the door open for a limited denial of service attack called [Transaction malleability](https://bitcoindevelopers.org/encyclopedia/transaction-malleability/). The [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script contains the secp256k1 [Signature](https://bitcoindevelopers.org/encyclopedia/signature/), which can’t sign itself, allowing attackers to make non-functional modifications to a transaction without rendering it invalid. For example, an attacker can add some data to the [Signature](https://bitcoindevelopers.org/encyclopedia/signature/) script which will be dropped before the previous [Pubkey script](https://bitcoindevelopers.org/encyclopedia/pubkey-script/) is processed.

Although the modifications are non-functional—so they do not change what inputs the transaction uses nor what outputs it pays—they do change the computed hash of the transaction. Since each transaction links to previous transactions using hashes as a transaction identifier ([Txid](https://bitcoindevelopers.org/encyclopedia/txid/)), a modified transaction will not have the [Txid](https://bitcoindevelopers.org/encyclopedia/txid/) its creator expected.

This isn’t a problem for most Bitcoin transactions which are designed to be added to the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain immediately. But it does become a problem when the [Output](https://bitcoindevelopers.org/encyclopedia/output/) from a transaction is spent before that transaction is added to the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain.

Bitcoin developers have been working to reduce [Transaction malleability](https://bitcoindevelopers.org/encyclopedia/transaction-malleability/) among [Standard Transaction](https://bitcoindevelopers.org/encyclopedia/standard-transaction/) types, one outcome of those efforts is BIP 141: Segregated Witness, which is supported by Bitcoin Core and was activated in August 2017. When SegWit is not being used, new transactions should not depend on previous transactions which have not been added to the [Block](https://bitcoindevelopers.org/encyclopedia/block/) chain yet, especially if large amounts of [Satoshis](https://bitcoindevelopers.org/encyclopedia/satoshis/) are at stake.

[Transaction malleability](https://bitcoindevelopers.org/encyclopedia/transaction-malleability/) also affects payment tracking. Bitcoin Core’s RPC interface lets you track transactions by their [Txid](https://bitcoindevelopers.org/encyclopedia/txid/)—but if that [Txid](https://bitcoindevelopers.org/encyclopedia/txid/) changes because the transaction was modified, it may appear that the transaction has disappeared from the network.

Current best practices for transaction tracking dictate that a transaction should be tracked by the transaction outputs (UTXOs) it spends as inputs, as they cannot be changed without invalidating the transaction.

Best practices further dictate that if a transaction does seem to disappear from the network and needs to be reissued, that it be reissued in a way that invalidates the lost transaction. One method which will always work is to ensure the reissued payment spends all of the same outputs that the lost transaction used as inputs.