Bitcoin transactions are more complex than traditional bank transfers. While a bank transfer simply deducts money from one account and credits it to another, Bitcoin transactions use scripts to enable programmable functionality. This is why Bitcoin is often called a "programmable currency." Let's explore how Bitcoin transactions achieve this programmability.
Understanding Unspent Transaction Outputs (UTXOs)
At the core of Bitcoin transactions lies the concept of Unspent Transaction Outputs (UTXOs).
- UTXOs represent the fundamental building blocks of Bitcoin transactions
- Each transaction input comes from a previously unspent output
- Transaction outputs then become potential inputs for future transactions
Mining rewards are special transactions (called coinbase transactions) that may have no inputs
UTXOs cannot be divided further
Bitcoin doesn't use account balances—only UTXOs scattered across the blockchain
This creates a chain of ownership as funds move from one address to another.
Bitcoin Scripting System
Bitcoin transactions require two key components:
- Unlocking Script (Signature Script): Provides the credentials to spend a UTXO
- Locking Script (PubKey Script): Specifies the conditions to spend the output
Every Bitcoin node validates transactions by executing both scripts together. The transaction is only valid if the combined script evaluates as true.
A transaction is only valid when the unlocking script satisfies the conditions set by the locking script
Common Transaction Script Verification Process
Bitcoin uses a scripting language based on Reverse Polish Notation (RPN) with stack-based execution:
- The language supports basic arithmetic, logical operations, and cryptographic functions
- It processes items from left to right
- No loops are supported in the language
The verification process involves:
- Unlocking Script Execution: Primarily pushes items onto the stack
- Locking Script Execution: Primarily pops items from the stack
- Result Evaluation: Transaction is valid if final result is true
Detailed Transaction Analysis
Bitcoin transactions can include multiple inputs and outputs, offering flexibility in design.
Transaction Structure
Key components of a Bitcoin transaction include:
- Version number
- Input count and inputs
- Output count and outputs
- Lock time (usually 0 for immediate execution)
Lock times can specify either block heights or UNIX timestamps
Transaction fees aren't explicitly stated—they're the difference between total inputs and total outputs
Input Structure Breakdown
Each input contains:
- Reference to previous transaction output
- Unlocking script
- Sequence number (used for lock times)
Output Structure Breakdown
Each output contains:
- Amount being transferred
- Locking script (conditions for spending the output)
Transaction Hash Calculation
Transaction hashes are computed by:
- Serializing all transaction fields into byte arrays
- Concatenating these byte arrays
- Performing double SHA-256 hash on the resulting string
This hash becomes part of the Merkle tree in Bitcoin blocks.
Smart Contract Prototypes: Practical Applications
Bitcoin's scripting enables numerous conditional variations. The two most common script types are:
- P2PKH (Pay-to-Public-Key-Hash)
- P2SH (Pay-to-Script-Hash)
P2SH replaces locking scripts with cryptographic hashes, requiring spenders to provide matching scripts.
Real-World Use Cases
Multi-Signature Applications:
- Corporate governance (majority approval for payments)
- Escrow services (third-party dispute resolution)
Assurance Contracts:
- Public goods funding (only execute if minimum funding reached)
- Collective decision-making for community projects
Time-Based Transactions:
- Inheritance planning (release funds at death or specific age)
- Conditional payments based on external events
👉 Discover more advanced Bitcoin applications
While Bitcoin's scripting language isn't Turing-complete (limiting complex contracts), it laid the foundation for more advanced platforms like Ethereum.
Frequently Asked Questions
Q: How do UTXOs differ from account balances?
A: UTXOs represent discrete chunks of unspent funds, while account balances aggregate all funds in an account.
Q: Can Bitcoin scripts include complex conditions?
A: Yes, but they're limited by the non-Turing-complete nature of the scripting language.
Q: What makes P2SH different from P2PKH?
A: P2SH uses script hashes instead of public key hashes, enabling more complex spending conditions.
Q: How are transaction fees determined?
A: Fees emerge naturally as the difference between inputs and outputs—no explicit fee field exists.
Q: Can Bitcoin scripts handle multi-party agreements?
A: Yes, through multi-signature scripts that require multiple approvals.
Q: What limitations exist in Bitcoin smart contracts?
A: The main limitations are no loops and limited complexity compared to Ethereum's Solidity.
For those interested in programmable money, 👉 explore these advanced blockchain concepts further.