B++ Logo

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

  1. Complex state: No persistent contract state
  2. Loops: No iterative operations
  3. External data: No oracles (without DLCs)
  4. 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

  1. Use established patterns: Don't reinvent the wheel
  2. Test thoroughly: Script bugs are costly
  3. Consider Taproot: Better privacy and efficiency
  4. Document contracts: Explain conditions clearly

For Users

  1. Understand conditions: Know when funds can be spent
  2. Test on testnet: Verify contracts work
  3. Use reputable services: Escrow, etc.
  4. Backup keys: Multisig requires key management


Resources