Quiz: Bitcoin Scripting, Taproot, and Programmability

Multiple Choice

Question 1

Bitcoin Script is best described as a: - (a) Turing-complete programming language with state management - (b) Stack-based, non-Turing-complete verification language - (c) Object-oriented language compiled to bytecode - (d) Register-based assembly language

Answer: (b) Bitcoin Script is a stack-based language that lacks loops and persistent state, making it non-Turing-complete by design. It serves primarily as a verification system for spending conditions rather than a general-purpose computation engine.

Question 2

Why does every OP_CHECKMULTISIG transaction include a dummy OP_0 element in the unlocking script? - (a) It is a security feature that prevents replay attacks - (b) It compensates for an off-by-one bug in the original implementation that cannot be fixed without a hard fork - (c) It serves as a version indicator for future multi-sig upgrades - (d) It is required by the P2SH specification

Answer: (b) The original implementation of OP_CHECKMULTISIG consumes one extra element from the stack beyond what it should. This bug has been present since Bitcoin's inception and is preserved for backward compatibility. The dummy OP_0 is a harmless placeholder consumed by this bug.

Question 3

In a P2PKH transaction, at what point is the recipient's public key first revealed on the blockchain? - (a) When the sender creates the output - (b) When the output is confirmed in a block - (c) When the recipient spends the output - (d) When the recipient generates the address

Answer: (c) P2PKH outputs contain only the hash of the public key. The actual public key is revealed only in the unlocking script when the recipient spends the output. This provides an additional layer of protection against potential future breaks in ECDSA.

Question 4

What is the primary difference between CLTV and CSV time locks? - (a) CLTV uses block height; CSV uses Unix timestamps - (b) CLTV enforces absolute time points; CSV enforces relative durations after UTXO confirmation - (c) CLTV works with SegWit; CSV only works with legacy transactions - (d) CLTV is used in Lightning channels; CSV is used in atomic swaps

Answer: (b) OP_CHECKLOCKTIMEVERIFY (CLTV) locks funds until a specific block height or timestamp. OP_CHECKSEQUENCEVERIFY (CSV) locks funds for a relative duration (in blocks or 512-second intervals) after the UTXO is confirmed. Both can use either block height or time, but CLTV is absolute and CSV is relative.

Question 5

Which of the following is NOT an advantage of Schnorr signatures over ECDSA? - (a) Key and signature aggregation (linearity) - (b) Formal security proof reducing to the discrete logarithm problem - (c) Backward compatibility with existing Bitcoin addresses - (d) Smaller, fixed-size signatures (64 bytes)

Answer: (c) Schnorr signatures are used in a new address format (P2TR/bech32m starting with bc1p) and are not backward compatible with existing P2PKH or P2SH addresses. The other three options are genuine advantages of Schnorr over ECDSA.

Question 6

In a Taproot (P2TR) transaction using key path spending, what information about the MAST script tree is revealed on-chain? - (a) The complete MAST tree, including all script leaves - (b) Only the Merkle root of the MAST tree - (c) Nothing — the existence of script conditions is completely hidden - (d) The number of script leaves, but not their contents

Answer: (c) Key path spending produces a single Schnorr signature for the tweaked public key. The MAST tree, its root, and all script conditions remain completely hidden. Observers cannot even determine whether a MAST tree existed.

Question 7

P2SH (Pay-to-Script-Hash) was introduced primarily to: - (a) Reduce transaction fees by compressing script data - (b) Enable SegWit compatibility with older wallets - (c) Shift the complexity of spending conditions from the sender to the recipient - (d) Fix the transaction malleability bug

Answer: (c) Before P2SH, senders had to construct the full locking script, which required them to know the recipient's spending conditions. P2SH allows the recipient to create any script, hash it to produce an address, and give that address to the sender. The sender creates a simple hash-check lock. The complex script is revealed only when the recipient spends.

Question 8

Which of the following use cases requires a relative time lock (CSV) rather than an absolute time lock (CLTV)? - (a) Releasing funds on a specific calendar date - (b) Creating a dispute window after a Lightning channel commitment is broadcast - (c) Locking funds until block height 1,000,000 - (d) Scheduling a payment for New Year's Day 2030

Answer: (b) Lightning Network dispute windows require that the penalty period begins when the commitment transaction is broadcast — an event whose timing is unknown in advance. This requires a relative time lock (CSV) that counts from the moment of confirmation. The other three options involve known future dates or block heights, making them suitable for absolute time locks (CLTV).

Question 9

What is a Merkelized Abstract Syntax Tree (MAST)? - (a) A data structure that stores transaction outputs in a binary search tree - (b) A Merkle tree where each leaf represents a different spending condition, allowing selective revelation - (c) A tree of abstract syntax nodes representing parsed Bitcoin Script opcodes - (d) A compression format for storing multiple signatures efficiently

Answer: (b) A MAST organizes multiple spending conditions as leaves in a Merkle tree. When spending, only the exercised condition and its Merkle path to the root are revealed. Other conditions remain hidden, improving both privacy and on-chain efficiency.

Question 10

Why did Satoshi Nakamoto disable several opcodes (such as OP_CAT and OP_MUL) early in Bitcoin's history? - (a) They were never implemented in the first place - (b) They were discovered to have potential vulnerabilities such as integer overflow and excessive computation - (c) They were reserved for a future version of Bitcoin Script - (d) They conflicted with the SegWit upgrade specification

Answer: (b) Several opcodes were disabled after concerns about potential attack vectors, including integer overflow (OP_MUL), excessive memory use (OP_CAT with repeated concatenation), and other vulnerabilities. These opcodes remain disabled, though some (particularly OP_CAT) are being reconsidered for reactivation with appropriate safeguards.

True/False

Question 11

True or False: Bitcoin Script's scriptSig and scriptPubKey are concatenated into a single program and executed together.

Answer: False. In the current implementation, scriptSig is executed first on an empty stack, and the resulting stack is then used as the initial stack for scriptPubKey execution. This separation was introduced to prevent attacks where a crafted scriptSig could manipulate the locking script. Many older resources incorrectly describe concatenated execution.

Question 12

True or False: A Taproot-based 3-of-3 multi-sig transaction using key path spending is indistinguishable on-chain from a single-signature transaction.

Answer: True. Schnorr key aggregation allows the three participants to combine their public keys into a single aggregated key and produce a single aggregated signature. On-chain, this looks identical to a standard single-signature P2TR transaction.

Question 13

True or False: OP_RETURN outputs are added to the UTXO set and must be tracked by all full nodes.

Answer: False. OP_RETURN outputs are provably unspendable, so nodes immediately recognize them as such and do not add them to the UTXO set. This is precisely why OP_RETURN is preferred over embedding data in fake addresses, which do pollute the UTXO set.

Question 14

True or False: In Ethereum, a reentrancy attack of the kind that exploited The DAO in 2016 would also be possible in Bitcoin Script.

Answer: False. Bitcoin Script is stateless and has no mechanism for recursive calls between scripts. The reentrancy vulnerability requires the ability for a called contract to call back into the calling contract before the first call completes — a pattern that is impossible in Bitcoin's execution model.

Question 15

True or False: Native SegWit v0 addresses (bc1q...) and Taproot addresses (bc1p...) both use the same bech32 encoding.

Answer: False. Native SegWit v0 addresses use bech32 encoding, while Taproot (SegWit v1) addresses use bech32m encoding. The bech32m format corrects a subtle weakness in the original bech32 encoding related to the detection of certain types of errors in the final character.

Short Answer

Question 16

Explain why P2SH is described as "shifting complexity to the spender." Give a concrete example.

Answer: Before P2SH, the sender had to construct the full locking script, which meant they needed to know all the details of the recipient's spending conditions (e.g., all public keys in a multi-sig, the threshold, any time locks). With P2SH, the recipient constructs their complex script, hashes it to a 20-byte hash, and encodes that hash as an address (starting with 3). The sender creates a simple locking script that only checks the hash. The full complex script — the "redeem script" — is revealed only when the recipient spends the UTXO. For example, a 3-of-5 multi-sig recipient would construct the OP_CHECKMULTISIG script with all five public keys, hash it, and give the sender only the resulting address. The sender's wallet does not need to understand multi-sig at all.

Question 17

Describe two specific use cases where CSV (relative time locks) is necessary and CLTV (absolute time locks) would not work. Explain why the timing must be relative.

Answer: (1) Lightning Network revocation: When a party broadcasts an old commitment transaction, the counterparty needs a dispute window (typically 144 blocks) to detect the fraud and broadcast a penalty transaction. Since neither party knows in advance when a channel breach will occur, the time lock must be relative to the breach event, not to an absolute time. (2) Payment channel refunds: In a simple unidirectional payment channel, if the recipient disappears, the sender needs a refund path that activates a certain number of blocks after the funding transaction confirms. The funding time is not known in advance, so the refund window must be relative. In both cases, the triggering event (channel breach, funding confirmation) occurs at an unpredictable time, making absolute time locks unusable.

Question 18

Explain the key path vs. script path distinction in Taproot spending. Why is the key path the preferred spending method?

Answer: Key path spending occurs when all parties controlling a P2TR output cooperate. They combine their signatures (using Schnorr aggregation) to produce a single signature for the tweaked public key, resulting in a transaction indistinguishable from a single-signature payment. Script path spending occurs when cooperation fails — a spender reveals the internal key, a specific script leaf from the MAST tree, and the Merkle proof connecting that leaf to the root, then satisfies the script. Key path is preferred because: (1) it is the most private, hiding all script conditions and even the number of participants; (2) it is the most efficient, requiring only a single 64-byte signature; and (3) it produces the smallest on-chain footprint and lowest fees. Taproot is designed so that the overwhelming majority of transactions — those that resolve cooperatively — take the optimal key path.

Question 19

What is the "halting problem" relevance to Bitcoin Script design, and how do Bitcoin and Ethereum each address it?

Answer: The halting problem states that no general algorithm can determine whether an arbitrary program will eventually halt or run forever. In a blockchain context, this matters because every full node must execute every transaction's script. If a script could run forever, it would halt the node (denial-of-service). Bitcoin addresses this by making Script non-Turing-complete: no loops means every script is guaranteed to terminate in a number of steps bounded by the script's length. Ethereum addresses it with the gas mechanism: every EVM operation costs gas, transactions have a gas limit, and execution halts when gas runs out. Bitcoin's approach is simpler and eliminates the problem entirely. Ethereum's approach is more flexible but introduces complexity (gas estimation, out-of-gas errors, gas price markets) and does not fully prevent denial-of-service (a contract can still waste significant computation up to the gas limit).

Question 20

Describe how Discreet Log Contracts (DLCs) achieve financial smart contract functionality without modifying Bitcoin's protocol. What role does the oracle play, and why is it remarkable that the oracle need not know about the contract?

Answer: DLCs use Schnorr signature adaptor techniques to create financial contracts between two parties that settle based on external data. The oracle commits to publishing a Schnorr signature over a specific piece of data (e.g., the BTC/USD price at a given time) on a predetermined schedule. The contract participants use the oracle's public key and the expected signature points to construct conditional transactions off-chain. When the oracle publishes its signature, it serves as the "key" that makes exactly one of the pre-constructed settlement transactions valid. The oracle is remarkable in that it simply publishes data signatures on schedule — it has no knowledge of any contracts built on its data, no ability to favor one party, and no custody of funds. This eliminates the trust, collusion, and centralization risks inherent in oracles that actively participate in contract execution. All of this works with standard Bitcoin transactions and existing opcodes.