Key Takeaways: Bitcoin Scripting, Taproot, and Programmability

Core Concepts

1. Bitcoin Script Is a Verification Language, Not a Computation Language

Bitcoin Script does not compute new results — it verifies that spending conditions are met. The spender performs computation off-chain and provides proofs (signatures, hash preimages) that the script checks. This verification-only philosophy keeps on-chain costs predictable and the attack surface minimal.

2. Deliberate Limitations Are Features, Not Bugs

Bitcoin Script is not Turing-complete. It has no loops, no persistent state, and limited opcodes. These constraints guarantee that every script terminates in bounded time, that validation requires no global state, and that the consensus layer remains maximally secure. Every limitation exists for a specific security reason.

3. The Lock-and-Key Model Separates Definition from Satisfaction

Every UTXO contains a locking script (scriptPubKey) defining spending conditions and requires an unlocking script (scriptSig or witness data) satisfying those conditions. This separation enables all of Bitcoin's advanced scripting features, from multi-sig to time locks to atomic swaps.

4. Standard Transaction Types Evolved to Solve Real Problems

• P2PKH: Established hash-locked cryptographic verification (addresses starting with 1)
• P2SH: Shifted complexity from sender to recipient, enabling practical multi-sig (addresses starting with 3)
• P2WPKH/P2WSH: Fixed transaction malleability, reduced fees via witness discount, enabled Lightning (addresses starting with bc1q)
• P2TR: Combined Schnorr signatures and MAST for improved privacy, efficiency, and flexibility (addresses starting with bc1p)

5. Time Locks Provide Two Dimensions of Temporal Control

• CLTV (absolute): "This output cannot be spent before block 900,000" — used for vesting schedules, inheritance planning, and futures contracts
• CSV (relative): "This output cannot be spent until 144 blocks after it is confirmed" — used for payment channel dispute windows, Lightning Network penalties, and refund mechanisms

6. Multi-Sig Is the Foundation of Institutional Bitcoin

M-of-N multi-signature patterns protect billions of dollars in Bitcoin. They enable shared custody, organizational controls, geographic key distribution, and redundancy against key loss. The OP_CHECKMULTISIG off-by-one bug is a permanent protocol artifact requiring a dummy OP_0 in every multi-sig transaction.

7. Taproot Is the Most Significant Scripting Upgrade Since SegWit

Taproot combines three innovations: - Schnorr signatures: Linearity enables key and signature aggregation, making multi-party transactions indistinguishable from single-signature transactions - MAST: Merkle trees of spending conditions allow selective revelation — only the exercised condition is revealed on-chain - Key path / script path duality: The common cooperative case produces a single signature; complex scripts are revealed only when cooperation fails

8. Bitcoin's "Limited" Script Enables Surprisingly Complex Applications

Despite its constraints, Bitcoin Script supports atomic swaps, the Lightning Network, Discreet Log Contracts, vaults, colored coins, Ordinals, and BRC-20 tokens. The combination of multi-sig, time locks, hash locks, and conditional logic creates a rich design space.

9. Bitcoin and Ethereum Represent Valid but Different Design Philosophies

Bitcoin: verify, do not compute. Minimal attack surface, predictable execution, no state. Ethereum: world computer. Turing-complete, persistent state, maximum expressiveness. Both approaches have tradeoffs, and the two ecosystems are converging toward hybrid designs through Layer 2 solutions.

10. Every Protocol Feature Will Be Used in Unexpected Ways

Ordinals and BRC-20 demonstrate that users will exploit every available feature regardless of designer intent. Taproot's witness space was designed for scripts but was used for data inscriptions. This validates Bitcoin's conservative development approach, where every change undergoes years of review.

Common Misconceptions Corrected

Formulas and Constructs to Remember

Taproot Key Tweaking:

Q = P + hash(P || m) * G

Where P = internal key, m = MAST Merkle root, G = generator point

HTLC Pattern:

OP_IF
    OP_HASH160 <hash> OP_EQUALVERIFY <recipient_pubkey> OP_CHECKSIG
OP_ELSE
    <timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP <sender_pubkey> OP_CHECKSIG
OP_ENDIF

CSV Time Lock Pattern:

<delay_in_blocks> OP_CHECKSEQUENCEVERIFY OP_DROP <pubkey> OP_CHECKSIG

Chapter Connections