SaibunScript Guide
UTXO Splitter

Script Guide

A deep walkthrough of every template in the Script Lab. Each pattern is explained opcode-by-opcode with real-world context, so you understand not just what the script does, but why it exists and when you'd use it on-chain.

How Bitcoin Script Works

Locking Script

Placed on a transaction output when you send funds. It defines the conditions required to spend those funds. Think of it as the lock on a safe — it encodes the puzzle that must be solved.

Unlocking Script

Provided in the transaction input that spends the output. It supplies the solution — the key that opens the lock. The network executes both scripts together to verify the spend.

Execution Model

Bitcoin Script is a stack-based language. There is no memory, no variables, no loops — only a stack of byte arrays. Execution happens in two phases:

  1. Unlocking script runs first — it pushes data (secrets, signatures, values) onto the stack.
  2. Locking script runs second — it reads those values and performs checks (hash comparisons, signature verification, arithmetic).

If the final stack has exactly one truthy element, the spend is valid. This is called the clean stack rule.

Stack-based

Every opcode either pushes data onto the stack, pops data off it, or does both. For example, OP_ADD pops two numbers, adds them, pushes the result.

No state

Scripts can't read the blockchain, call APIs, or store persistent data. The only input is what's on the stack and the transaction being validated.

Restored opcodes

BSV restored disabled opcodes (OP_MUL, OP_CAT, OP_SPLIT, etc.) and removed script size limits, enabling much more expressive scripts than BTC.

Basic

2 templates

The most minimal scripts — useful for understanding how script validation works at the most fundamental level, and for special-purpose outputs like provably unspendable burns.

Lock Funds

9 templates

Lock funds to a mathematical or cryptographic condition. Anyone who can solve the puzzle can spend the coins — no private key required. Hash puzzles are the foundation of atomic swaps, HTLCs, and most DeFi primitives.

Control Flow

3 templates

OP_IF/OP_ELSE/OP_ENDIF enable conditional execution. This is how scripts offer multiple spending paths — the foundation of HTLCs, dispute resolution, and any "either Alice OR Bob can spend" pattern.

Stack

3 templates

The alt stack is a secondary stack used as scratch space. Moving values to the alt stack and back lets you perform operations that would be awkward with just the main stack. These patterns are essential for complex BSV smart contracts.

Time Lock

2 templatesEducational

Timelocks on BSV work at the transaction level, not via script opcodes. The nLockTime and nSequence fields of a transaction control when miners will accept it. This is the original Satoshi design.

OP_CHECKLOCKTIMEVERIFY (CLTV) and OP_CHECKSEQUENCEVERIFY (CSV) are disabled on BSV. They were reverted to OP_NOP2 and OP_NOP3 at the Genesis upgrade (Feb 2020). These opcodes only work on BTC and BCH. On BSV, timelocks are enforced by miners via the transaction's nLockTime field — no script opcode needed.

Escrow & Swaps

5 templates

Escrow and swap patterns combine hash puzzles, multisig, and transaction-level timelocks to create trustless agreements. HTLCs (Hash Time-Locked Contracts) are the foundation of atomic swaps. On BSV, the "time-locked" part uses nLockTime at the transaction level, while the script handles the hash puzzle and branching logic.

Standard Payments

3 templates

The script patterns used by almost every Bitcoin transaction. P2PKH (pay-to-public-key-hash) is the most common — it's what your wallet uses when you "send to an address." These are reference templates; they require real signatures to validate.

Data Manipulation

2 templates

BSV restored OP_CAT, OP_SPLIT, and other byte-manipulation opcodes that were disabled on BTC in 2010. These enable scripts to concatenate, split, and transform byte strings — essential building blocks for advanced patterns like OP_PUSH_TX (sighash preimage inspection).

Data Embedding

4 templates

OP_RETURN outputs embed arbitrary data on the blockchain. They are provably unspendable (the script always fails), so nodes can safely prune them. This is the backbone of on-chain data protocols like B://, MAP, Bitcom, and tokenization standards.

Custom

1 template

The blank canvas. Write your own locking and unlocking scripts from scratch. Combine any of the patterns you've learned above — or invent entirely new ones.

Tips for writing custom scripts

• Start simple. Get the basic logic working with hardcoded values, then make it more complex.

• Use the simulator. The step-by-step execution view shows exactly what's on the stack after each opcode. This is the fastest way to debug.

• Remember the clean stack rule. After execution, there must be exactly one truthy value on the stack. Use OP_DROP to remove extra items. Use OP_VERIFY to consume TRUE from intermediate checks.

• OP_EQUALVERIFY vs OP_EQUAL. Use EQUALVERIFY for intermediate checks (it fails fast and removes both items). Use EQUAL for the final check (it leaves TRUE/FALSE as the result).

• Stack order matters. The stack is LIFO (last in, first out). The first thing pushed in the unlock script is the deepest item when the lock script runs.

• Hex data pushes. In ASM, hex strings like 68656c6c6f are automatically pushed as data. You don't need a PUSH opcode.

Ready to build?

Try any of these patterns in the Script Lab. Load a template, modify it, step through the execution, and build real transactions.

Open Script Lab