Deep Dive into Unlocking Script: The 'Key' to Spending Blockchain Transactions

In a Nutshell

An unlocking script is unlocking material written in a transaction input (input) that satisfies the locking script of a previous output (output). If the locking script is a lock, the unlocking script is the key—to spend an old UTXO, a transaction must provide the correct unlocking material.

Where Is Unlocking Script Located

The unlocking script is located in the input of the current transaction. Each input references a specific output from a previous transaction:

The previous output contains a locking script, while the current input contains an unlocking script. Nodes combine and execute them according to the rules: if the execution result is true, the input successfully spends that UTXO.

A P2PKH Example

The most common transaction type is P2PKH (Pay-to-Public-Key-Hash), whose locking script requires:

1. Providing a public key
2. The hash of the public key matches the hash in the lock
3. Providing a valid signature

Therefore, to spend this output, the unlocking script typically provides:

• Signature: proves you own the corresponding private key
• Public key: used to verify the signature and hash match

Node verification process:

• Does the hash of the public key equal the hash recorded in the locking script?
• Can the signature be verified with that public key?
• Is the signature bound to the content of the current transaction?

If all pass, the spend is valid.

Unlocking Script Is Not a "Payment Instruction"

Newcomers often mistakenly think the unlocking script indicates "who I want to send to." That is inaccurate. The recipient is expressed in the outputs of the current transaction; the unlocking script only proves "you can spend this old UTXO."

The two directions of a transaction must be understood separately:

• Inputs + unlocking scripts = which old UTXOs I can spend
• Outputs + locking scripts = which new UTXOs I create

The unlocking script addresses "whether the source of funds is legitimate," not "where the funds go."

Each Input Must Satisfy Its Own Conditions

A transaction can have multiple inputs, each referencing a different old output. Each old output may have a different locking script, so each input must provide its corresponding unlocking data.

For example:

• input 0 spends a P2PKH output → needs signature and public key
• input 1 spends a multisig output → needs multiple signatures
• input 2 spends a hash-locked output → needs preimage data

If any input fails to unlock, the entire transaction is typically invalid.

Why Signatures Must Bind to Transaction Content

If the unlocking script provides a signature, that signature must be bound to the content of the current transaction. Otherwise, an attacker could take your signature and use it in another transaction (replay attack).

Signatures usually cover:

• The spent inputs
• Transaction outputs
• Amounts
• Script context
• Partial transaction data determined by SIGHASH type

Different SIGHASH types affect the scope of the signed data. But for beginners, understand: a signature does not abstractly prove "I am me," but proves "I authorize this specific transaction."

Unlocking Script and Wallets

Regular users rarely write unlocking scripts manually. Wallets or SDKs generate them automatically based on UTXO type. However, developers still need to understand this, as common reasons for transaction failure include:

• Using the wrong private key
• Public key not matching the locking hash
• Signature covering wrong data
• Input referencing the wrong output
• The old output's locking script type is not what you assumed

When debugging, you must look at both the old output's locking script and the current input's unlocking script.

Role in BSV Applications

BSV application protocols may design custom locking scripts, and correspondingly must design correct unlocking data. For example, token or credential state transfers may require:

• Asset owner's signature
• Issuer's signature
• Specific data fields
• Reference to previous state
• Hash preimage

In such cases, the unlocking script is not just a regular signature, but a set of evidence for protocol state transition.

Common Misconceptions for Newcomers

1. The unlocking script does not determine the payee—outputs determine where new funds go.
2. The unlocking script is in the input, not the output.
3. Each input must satisfy the conditions of the old output it references.
4. A valid signature must correspond to the current transaction content.
5. Wallets generate unlocking scripts automatically, but developers still need to understand them for debugging.
6. The old output's locking script and the current input's unlocking script must match.

References

• Script docs
• Transaction Inputs and Outputs
• Advanced Transaction Construction