Exercises: Bitcoin Scripting, Taproot, and Programmability

Exercises: Bitcoin Scripting, Taproot, and Programmability

Conceptual Questions

Exercise 9.1 — Stack Tracing (Bloom: Understand)

Trace the following Bitcoin Script on a stack, showing the stack state after each operation. Determine whether the script evaluates to TRUE or FALSE.

5 3 OP_ADD 8 OP_EQUAL

Show each step in a table format with columns for Step Number, Operation, and Stack State.

Exercise 9.2 — P2PKH Walkthrough (Bloom: Apply)

Consider a P2PKH transaction where Alice pays Bob. The locking script is:

OP_DUP OP_HASH160 <Bob_pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

And Bob provides the unlocking script:

<Bob_sig> <Bob_pubKey>

(a) Trace through the full execution, showing the stack state after each operation.

(b) At which step would the script fail if Bob provided the wrong public key? What about the wrong signature?

(c) Why does the script use OP_EQUALVERIFY instead of OP_EQUAL for the hash check?

Exercise 9.3 — Why Not Turing-Complete? (Bloom: Evaluate)

A student argues: "Bitcoin should add loops to its scripting language. Ethereum has them and it works fine with the gas mechanism. Bitcoin is just being stubborn."

Write a response that: (a) Explains the technical reasons Bitcoin avoids loops (b) Describes how Ethereum's gas mechanism addresses the halting problem (c) Identifies at least two disadvantages of Ethereum's approach (d) Concludes with a balanced assessment of whether Bitcoin's design choice is justified

Exercise 9.4 — Time Lock Design (Bloom: Apply)

Design a Bitcoin Script that implements the following inheritance plan:

Alice can spend the funds at any time with her signature alone
If Alice does not spend the funds for 52,560 blocks (approximately 1 year), Bob can spend the funds with his signature
If neither Alice nor Bob spends the funds for 105,120 blocks (approximately 2 years), a charity (represented by CharityPubKey) can spend with its signature

Write the complete locking script using OP_IF, OP_ELSE, OP_ENDIF, OP_CHECKSEQUENCEVERIFY, OP_DROP, OP_CHECKSIG, and any other necessary opcodes.

Exercise 9.5 — Multi-Sig Analysis (Bloom: Analyze)

A cryptocurrency exchange is designing its cold storage security model. They are considering three options:

(a) 3-of-5 multi-sig with keys held by five executives (b) 2-of-3 multi-sig with one key on a hardware security module, one held by the CEO, and one in a geographically separate secure facility (c) A Taproot-based approach with Schnorr key aggregation for the cooperative case and a 3-of-5 MAST fallback

For each option, analyze: 1. How many keys can be lost or compromised before funds are at risk? 2. What information is revealed on-chain when funds are spent? 3. What is the operational complexity for routine transactions? 4. What are the failure modes?

Recommend one approach and justify your recommendation.

Technical Exercises

Exercise 9.6 — Script Interpreter Extension (Bloom: Create)

Using the script_interpreter.py provided with this chapter as a starting point:

(a) Add support for the following opcodes: OP_SWAP (swap the top two stack elements), OP_ROT (rotate the top three stack elements), and OP_2DUP (duplicate the top two elements).

(b) Write a test script that uses all three new opcodes and verify your implementation produces the correct stack output.

(c) Explain why OP_SWAP and OP_ROT might be useful in real Bitcoin scripts. Provide an example scenario for each.

Exercise 9.7 — CLTV vs. CSV Comparison (Bloom: Analyze)

For each of the following scenarios, determine whether CLTV (absolute time lock) or CSV (relative time lock) is more appropriate, and explain why:

(a) A vesting schedule that releases tokens on January 1st of each year from 2026 to 2030 (b) A payment channel that allows a dispute window after a party broadcasts a commitment transaction (c) A dead man's switch that transfers funds to heirs if the owner does not move them for 6 months (d) A futures contract that settles at a specific block height (e) A penalty mechanism in the Lightning Network

Exercise 9.8 — Taproot Privacy Analysis (Bloom: Evaluate)

Consider a 3-of-5 multi-sig controlled by a corporate board. Compare the on-chain privacy properties of the following approaches when the funds are spent cooperatively (all parties agree):

(a) Raw OP_CHECKMULTISIG (pre-P2SH) (b) P2SH-wrapped multi-sig (c) P2WSH-wrapped multi-sig (d) P2TR (Taproot) with Schnorr key aggregation

For each, describe exactly what information is visible on-chain after the transaction is confirmed. Which approach reveals the least information? Which reveals the most?

Exercise 9.9 — MAST Tree Construction (Bloom: Apply)

You are designing a Taproot output with the following spending conditions:

Alice and Bob cooperate (key path — Schnorr aggregated key)
Alice alone, after 1,000 blocks (CSV time lock)
Bob alone, with a hash preimage of H (hash lock)
Carol alone, after 10,000 blocks (CSV time lock — emergency recovery)

(a) Draw the MAST tree structure, placing conditions 2, 3, and 4 as script leaves. How would you arrange the leaves to minimize proof size for the most likely script-path spend?

(b) If the cooperative key path (condition 1) is used, what information is revealed on-chain about conditions 2, 3, and 4?

(c) If condition 2 is used (Alice alone after timeout), what Merkle proof must be provided? What information about conditions 3 and 4 is revealed?

(d) Calculate the Merkle proof size (in number of hashes) for each script-path spending condition, assuming a balanced binary tree with 3 leaves.

Exercise 9.10 — Atomic Swap Protocol (Bloom: Create)

Design a complete atomic swap protocol between Bitcoin and a hypothetical altcoin (AltCoin) that supports CLTV time locks and hash locks. Your design should include:

(a) The HTLC scripts for both the Bitcoin side and the AltCoin side (b) The step-by-step protocol: who creates the secret, who locks funds first, and in what order do actions occur (c) The time lock values for each side, and an explanation of why the Bitcoin time lock must be longer than the AltCoin time lock (d) An analysis of all possible failure scenarios and how the protocol handles each one (e) A diagram showing the happy path and at least one failure path

Applied Questions

Exercise 9.11 — Real Transaction Analysis (Bloom: Analyze)

Using a block explorer (such as mempool.space or blockstream.info), find and analyze:

(a) A P2PKH transaction — identify the locking script and verify it matches the standard P2PKH template (b) A P2SH multi-sig transaction — determine the M-of-N configuration from the redeem script (c) A P2TR (Taproot) transaction — determine whether it used key path or script path spending

For each transaction, provide the transaction ID and a brief analysis of what the scripts reveal about the spending conditions.

Exercise 9.12 — The OP_RETURN Debate (Bloom: Evaluate)

OP_RETURN allows embedding up to 80 bytes of arbitrary data in a provably unspendable output. This feature has been used for timestamping documents, anchoring sidechain data, and the Omni Layer protocol.

(a) Explain why OP_RETURN outputs are described as "provably unspendable." What makes them different from other unspendable outputs? (b) Before OP_RETURN, users embedded data in fake addresses (like the Satoshi Nakamoto tribute address). Why is OP_RETURN considered a better approach? (c) Some Bitcoin developers argue that OP_RETURN should be removed or restricted because it enables non-financial uses of Bitcoin's block space. Evaluate this argument from both the pro-restriction and anti-restriction perspectives.

Exercise 9.13 — Schnorr vs. ECDSA (Bloom: Understand)

(a) Explain the linearity property of Schnorr signatures in your own words. Why does this property make key aggregation possible? (b) Why is key aggregation impossible (or at least impractical) with ECDSA? (c) A 100-of-100 multi-sig using ECDSA requires 100 public keys and 100 signatures on-chain. What does the same 100-of-100 multi-sig look like on-chain using Schnorr key aggregation? What are the implications for transaction fees? (d) What is the "rogue key attack" in Schnorr key aggregation, and how does the MuSig protocol prevent it?

Exercise 9.14 — Design Challenge: Escrow Contract (Bloom: Create)

Design a complete Bitcoin escrow system for an online marketplace where buyers and sellers trade physical goods. Your design should include:

(a) The Script-level implementation (multi-sig structure, time locks, and any conditional logic) (b) The role of the escrow agent (arbiter) and under what conditions they can intervene (c) The happy path (buyer and seller agree) (d) The dispute path (buyer and seller disagree, arbiter intervenes) (e) The timeout path (one party disappears) (f) A comparison of implementing this escrow using P2SH multi-sig versus Taproot (g) Privacy implications: what information is revealed on-chain in each path?

Exercise 9.15 — Historical Analysis: The DAO of Bitcoin (Bloom: Evaluate)

Bitcoin's scripting limitations have prevented a "DAO hack" equivalent on Bitcoin. However, some argue that these same limitations have prevented Bitcoin from competing with Ethereum's DeFi ecosystem.

Write a 500-word essay evaluating this tradeoff. Your essay should: (a) Identify at least two major smart contract vulnerabilities that would be impossible in Bitcoin Script (b) Identify at least two DeFi applications that are impossible or impractical in Bitcoin Script (c) Discuss whether Layer 2 solutions (Lightning, DLCs, sidechains) adequately bridge the gap (d) Take a position on whether Bitcoin's conservatism has been a net positive or negative for the ecosystem, supporting your position with specific evidence