Definition
Bitcoin Script is the stack-based, Turing-incomplete programming language used to define the conditions under which Bitcoin transactions can be spent. It is a simple yet powerful scripting system embedded in every Bitcoin transaction output (locking script or scriptPubKey) and input (unlocking script or scriptSig), enabling programmable spending conditions without exposing the Bitcoin network to the risks of a Turing-complete smart contract platform. Bitcoin Script enables multi-signature wallets, time-locked transactions, hash-locked contracts, payment channels, and atomic swaps — all without requiring a general-purpose blockchain.
Origin & History
| Date | Event |
| 2008 | Satoshi Nakamoto designs Bitcoin Script as part of the Bitcoin whitepaper design |
| 2009 | Bitcoin Script deployed in Bitcoin genesis block; Pay-to-Public-Key (P2PK) is first script type |
| 2012 | BIP 16: Pay-to-Script-Hash (P2SH) introduced, enabling complex redeem scripts |
| 2015 | CHECKLOCKTIMEVERIFY (CLTV) added enabling absolute time locks on transactions |
| 2016 | CHECKSEQUENCEVERIFY (CSV) added enabling relative time locks for payment channels |
| 2017 | SegWit introduces Pay-to-Witness-Public-Key-Hash (P2WPKH) and P2WSH |
| 2021 | Taproot upgrade (BIP 340/341/342) introduces Schnorr signatures and MAST via Tapscript |
| 2023 | Bitcoin Ordinals leverage Script to inscribe data in witness data |
| 2023 | BIP 347 (OP_CAT) revival debate intensifies for potential Script extensions |
“Bitcoin Script is deliberately limited — and that’s a feature, not a bug. Simplicity is security.” — Greg Maxwell, Bitcoin Core Developer
How It Works
BITCOIN TRANSACTION SCRIPT EXECUTION ═══════════════════════════════════════════════════════ LOCKING SCRIPT (scriptPubKey) — on the UTXO output: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG (Standard P2PKH — Pay to Public Key Hash)
UNLOCKING SCRIPT (scriptSig) — provided by spender: <signature> <publicKey>
EXECUTION (stack-based): Stack starts empty
- Push <signature> → Stack: [sig]
- Push <publicKey> → Stack: [sig, pubKey]
- OP_DUP: duplicate top → Stack: [sig, pubKey, pubKey]
- OP_HASH160: hash top → Stack: [sig, pubKey, pubKeyHash]
- Push <pubKeyHash> → Stack: [sig, pubKey, pubKeyHash, expected]
- OP_EQUALVERIFY: compare → Stack: [sig, pubKey] (if equal)
- OP_CHECKSIG: verify sig → Stack: [TRUE]
Result: TRUE = transaction is valid and UTXO is spent
SCRIPT TYPES: P2PK → Pay to Public Key (legacy) P2PKH → Pay to Public Key Hash (most common) P2SH → Pay to Script Hash (multi-sig, complex) P2WPKH → Native SegWit (bech32) P2TR → Pay to Taproot (most efficient/private) ═══════════════════════════════════════════════════════
| Script Type | Address Format | Use Case | Privacy |
| P2PK | (no standard address) | Original Bitcoin, Satoshi coins | Low |
| P2PKH | 1… (Base58) | Standard single-sig payments | Low |
| P2SH | 3… (Base58) | Multi-sig, complex scripts | Medium |
| P2WPKH | bc1q… (bech32) | Native SegWit, lower fees | Medium |
| P2WSH | bc1q… (bech32) | Native SegWit scripts | Medium |
| P2TR | bc1p… (bech32m) | Taproot, Tapscript, Ordinals | High |
In Simple Terms
- Lock and key: Every Bitcoin output has a lock (locking script) — to spend it, you must provide the correct key (unlocking script) that satisfies the conditions.
- Stack machine: Script executes by pushing values onto a stack and running operations — it’s simple, predictable, and deliberately not Turing-complete to prevent infinite loops.
- Multi-sig example: A 2-of-3 multisig script requires 2 of 3 designated private key signatures to unlock funds — used for team treasuries and secure wallets.
- Taproot privacy: Taproot makes complex multi-sig and smart contract scripts look identical to simple single-sig transactions on the blockchain — improving privacy.
- Deliberate limits: Unlike Ethereum’s Solidity, Bitcoin Script cannot access external data, loop, or call other contracts — making it predictable and secure.
Real-World Examples
| Scenario | Script Type | Benefit |
| Exchange hot wallet | P2SH 2-of-3 multisig | Requires 2 of 3 keys to spend — protects against single key theft |
| Lightning Network channel | HTLC (Hash Time-Locked Contract) | Enables instant off-chain BTC payments |
| Atomic swap BTC↔LTC | HTLC on both chains | Trustless cross-chain exchange without intermediary |
| Time-locked inheritance | CHECKLOCKTIMEVERIFY | Funds only spendable after specific date |
| Ordinals inscription | P2TR witness data | NFT/data inscription in Taproot witness |
Advantages
| Advantage | Detail |
| Security | Turing-incomplete design prevents complex attack vectors possible in smart contracts |
| Predictability | Every script executes deterministically with bounded computation |
| Expressiveness | Enables multi-sig, time locks, HTLCs sufficient for Lightning Network |
| Efficiency | Scripts are compact, minimizing transaction data and fees |
| Privacy (Taproot) | Complex spending conditions indistinguishable from simple payments |
Disadvantages & Risks
| Risk | Detail |
| Limited functionality | Cannot implement complex DeFi, oracles, or arbitrary smart contracts |
| Script complexity | Advanced multi-sig scripts are complex to implement correctly |
| Legacy format issues | Older script types (P2PK, P2PKH) have lower privacy than modern alternatives |
| Disabled opcodes | Several powerful opcodes (OP_CAT, OP_CHECKSIGFROMSTACK) were disabled for security |
| Script bug risks | Errors in custom scripts can permanently lock funds |
Risk Management Tips:
- Always test custom Script implementations on testnet before mainnet
- Use P2TR (Taproot) addresses for best privacy and future compatibility
- For multi-sig wallets, use established implementations (Bitcoin Core, Sparrow Wallet) rather than custom scripts
- Store redeem scripts (P2SH) securely — you need them to spend funds
FAQ
Q: Why is Bitcoin Script not Turing-complete?
A: Turing completeness allows infinite loops — dangerous in a blockchain where all nodes must execute every script. Bitcoin Script’s deliberate incompleteness ensures scripts terminate predictably, preventing denial-of-service attacks and making formal verification of scripts possible.
Q: What is an HTLC in Bitcoin Script?
A: A Hash Time-Locked Contract (HTLC) is a script that allows a payment to be claimed by revealing a secret (preimage) that hashes to a predetermined value, or refunded to the sender after a timeout. HTLCs are the fundamental building block of the Lightning Network.
Q: How does Taproot improve Bitcoin Script?
A: Taproot (BIP 340/341/342) introduces Schnorr signatures enabling key aggregation, MAST (Merklized Abstract Syntax Trees) via Tapscript enabling complex scripts while revealing only executed branches, and making all Taproot outputs look identical externally — significantly improving privacy and efficiency.
UPay Tip: When setting up a Bitcoin wallet, use Taproot (bc1p…) addresses for the best combination of privacy, efficiency, and future compatibility. Most modern wallets like Sparrow and Phoenix support Taproot natively.
Disclaimer: This content is for educational purposes only and does not constitute financial or technical advice.
UPay — Making Crypto Encyclopedic
