Smart Contracts & Advanced Scripting
Bitcoin Script enables smart contracts through conditional spending. While intentionally limited (no loops, no complex state), Bitcoin's scripting system supports powerful contract patterns.
Bitcoin smart contracts are spending conditions encoded in Script:
Smart Contract = Locking Script + Unlocking Script
Locking Script: Defines conditions
Unlocking Script: Proves conditions are met
See this in action in Stack Lab.
Unlike Ethereum, Bitcoin contracts are:
- Stateless: No persistent contract state
- Deterministic: Same inputs = same result
- Limited: No loops, no external data
- Secure: Simpler = fewer vulnerabilities
Common Contract Patterns
1. Multisig
Multiple signatures required:
2-of-3 Multisig:
- Requires 2 of 3 keys to sign
- More secure than single key
- Common for shared custody
2. Timelocks
Time-based conditions:
Escrow Contract:
- Funds locked until date
- Can't be spent before
- Useful for inheritance, vesting
3. Hash Locks
Reveal secret to spend:
Hash Lock:
- Locked to hash of secret
- Reveal secret to unlock
- Used in atomic swaps, Lightning
4. Escrow
Three-party contracts:
Escrow:
- Buyer sends funds
- Seller provides goods
- Escrow releases funds
- Dispute resolution possible
Code Examples
Creating a Multisig Contract
Creating an Escrow Contract
Advanced Patterns
Vault Contracts
Time-delayed recovery:
Vault Structure:
1. Hot key: Can spend immediately (small amount)
2. Cold key: Can spend after delay (large amount)
3. Recovery key: Can spend after longer delay
Use case: Theft protection
Inheritance Contracts
Gradual fund release:
Inheritance:
- Beneficiary can claim after date
- Multiple beneficiaries possible
- Time-locked release
Atomic Swaps
Cross-chain exchanges:
Atomic Swap:
1. Lock funds with hash lock
2. Reveal secret to claim
3. Either both succeed or both fail
Taproot Contracts
Taproot enables better contracts:
Benefits:
- Privacy: Complex contracts look like simple payments
- Efficiency: Smaller transaction sizes
- Flexibility: MAST hides unused conditions
Miniscript
Miniscript is a structured language for expressing spending policies that compiles to Bitcoin Script. You describe what must hold (e.g., 2-of-3 keys, or "key A and after block N") and tools produce correct, analyzable Script. This simplifies multisig, timelocks, vaults, and Taproot script trees. See Miniscript for the full specification and use in wallets and protocols.
Covenants (Proposed)
Covenants are a proposed type of contract that would restrict how outputs can be spent in future transactions, for example, "this UTXO may only be spent to addresses of type X" or "funds must pass through a timelocked recovery path." Proposals such as OP_CAT, OP_CTV (CheckTemplateVerify), and SIGHASH_ANYPREVOUT aim to enable covenant-like behavior. None are in consensus today; see Covenants for the design space and BIPs.
Limitations
What Bitcoin Can't Do
- Complex state: No persistent contract state
- Loops: No iterative operations
- External data: No oracles (without DLCs)
- Turing-complete: Intentionally limited
Why Limitations Exist
- Security: Simpler = fewer bugs
- DoS prevention: No infinite loops
- Determinism: Predictable execution
- Decentralization: Easy to validate
Best Practices
For Developers
- Use established patterns: Don't reinvent the wheel
- Test thoroughly: Script bugs are costly
- Consider Taproot: Better privacy and efficiency
- Document contracts: Explain conditions clearly
For Users
- Understand conditions: Know when funds can be spent
- Test on testnet: Verify contracts work
- Use reputable services: Escrow, etc.
- Backup keys: Multisig requires key management
Related Topics
- Bitcoin Script - Script system
- OP Codes - Available operations
- Miniscript - Policy-to-script compiler
- Covenants - Proposed output-spend constraints
- Timelocks - Time-based conditions
- Multisig - Multi-signature wallets
- Atomic Swaps - Cross-chain contracts
Resources
- Bitcoin Script Patterns
- Miniscript - Policy to script compiler
