Understanding Locking Script in BSV: The Core Mechanism of Spending Conditions

In the BSV (Bitcoin SV) network, funds are not stored in traditional "accounts" but exist as Unspent Transaction Outputs (UTXOs). Each spendable output carries a locking script that defines the conditions required to spend it in the future. Understanding locking scripts is key to grasping the underlying control of assets in BSV.

The Role of Locking Script

A transaction output is not complete with just an amount. For example, suppose an output contains 1000 satoshis. Without spending conditions, the network cannot determine who is entitled to use it—anyone could reference that output as an input. Therefore, every output must include a locking script that explicitly states:

To spend these funds in the future, these conditions must be met.

In a common payment, the condition is typically: "Provide a valid digital signature corresponding to a specific public key."

Where Locking Script Lives

The locking script resides in the output section of a transaction. A simplified transaction structure looks like this:

When an output has not been spent, it is a UTXO. A future transaction that wants to spend it must provide an unlocking script (or unlocking data) in its input. These two scripts are combined into one script for execution and verification:

If the result is true, the spend is valid; otherwise, the transaction is rejected.

Locking Script and Addresses

An address is not the locking script itself, but it typically helps a wallet generate the corresponding locking script. For the common P2PKH (Pay to Public Key Hash) pattern, an address corresponds to a public key hash (Hash160). The wallet generates the locking script based on the address, with logic roughly as follows:

• The future spender must provide:
  1. A public key.
  2. A signature.
• And the script verifies:
  1. The hash of the provided public key equals the locked hash.
  2. The signature can be verified with that public key.

Thus, the address is a user-friendly identifier for receiving funds, while the locking script is the actual on-chain spending condition.

Different Patterns Locking Script Can Express

Beyond a simple single-signature payment, the Bitcoin Script programming language can express a variety of complex conditions:

• Multi-signature conditions: Require multiple signatures to spend.
• Hash preimage conditions: Provide the preimage of a hash (e.g., a secret value) to spend.
• Time or sequence constraints: Based on absolute time (OP_CHECKLOCKTIMEVERIFY) or relative time (OP_CHECKSEQUENCEVERIFY).
• Data outputs: For example, OP_RETURN is used to store arbitrary data on chain; such outputs are typically not spendable as ordinary funds.
• Application protocol states: In token, credential, or smart contract scenarios, locking scripts can express asset ownership, state update permissions, etc.

The BSV ecosystem particularly emphasizes the expressiveness of Script, making it not just a simple transfer system but capable of supporting complex on-chain applications.

Locking Script and UTXO Control

Control of a UTXO is not bound to a username or account; it is entirely defined by the locking script. For example:

• If the locking script requires a signature from a specific private key, the holder of that private key can spend the UTXO.
• If it requires multiple signatures, the multisig condition must be satisfied.
• If it is an unspendable data output (like OP_RETURN), that output cannot be spent as ordinary funds.

Therefore, understanding locking scripts means understanding the underlying rules of "who can spend money" in BSV.

Locking Script in BSV Applications

In BSV applications, locking scripts are used not only for payments but also as part of application state. For example:

• Token outputs where the locking script expresses ownership of an asset.
• Credential outputs that define who can update or revoke the credential.
• Application state outputs that require a specific signature to advance a state machine.
• Data outputs that use a specific format for Overlay networks to recognize.

However, designing complex locking scripts requires caution because script complexity can affect transaction standardness, fees, verification costs, and acceptance by miners or services.

Common Misunderstandings for Beginners

1. Locking script is not an address: An address is a shorthand representation of a locking script, not the script itself.
2. Locking script is in the output, not the input: Inputs provide the unlocking script, which works together with the locking script from the output.
3. Amount and locking script together form the core of an output: Without either, the output cannot be correctly used.
4. Who can spend a UTXO depends on whether the locking script and unlocking data match: It has nothing to do with user identity; it is purely determined by technical conditions.
5. A normal address payment is just one common template of locking script: BSV supports far more than just P2PKH.
6. Complex scripts are not necessarily widely accepted: You need to pay attention to the Bitcoin network's standard transaction policies and miner policies.

References

• Script Documentation
• Transaction Inputs and Outputs
• Advanced Transaction Construction Tutorial