Read spending conditions, not marketing labels
By the end, explain the diagram in your own words, solve the case and justify the correction.
Prerequisites : Bitcoin UTXOs explained · Hashes, keys and signatures
Level 3 · Advanced →Reading path · 1 / 17 · Advanced
Bitcoin Script specifies spending conditions, such as signatures, multiple signers or time constraints.
The essentials
Bitcoin Script specifies spending conditions, such as signatures, multiple signers or time constraints. Its expressiveness is intentionally constrained. Bitcoin has programmable spending conditions even though its execution model differs substantially from Ethereum’s.
How it works
SegWit moves certain signature data into a dedicated witness structure and addresses a form of transaction malleability important for higher-layer protocols. Taproot combines Schnorr signatures with commitments to alternative script paths. A key-path spend can avoid revealing alternative conditions; a script-path spend reveals the path used.
What to watch
These features can improve efficiency and privacy in particular arrangements. They do not make every transaction anonymous. Values and spending relationships can remain visible, and wallet behaviour matters. Check the address type and signing support of all participants before assuming a recovery or multisignature arrangement supports the same features.
Understand the details
Bitcoin outputs carry conditions that a future spend must satisfy. Script evaluates a limited set of operations rather than running an unrestricted application. A condition can require signatures or a time constraint. SegWit separates witness data and changes its weight accounting; Taproot provides a key path and, when needed, script paths committed through a tree.
Boundaries and common mistakes
A Taproot output is not automatically a multisig wallet or a guarantee of anonymity. Privacy depends on which spending path is used and on surrounding transaction behavior. Backup requirements may include wallet policy and derivation information, not just secret material. A technically valid policy can still be operationally impossible if necessary participants disappear.
The mechanism at a glance
- Output commits conditions
- Choose eligible path
- Supply required witness
- Nodes evaluate conditions
Apply the lesson to a case
Design a fictional policy: two signatures normally, or one recovery signer after a delay. List who must be available for each path and what wallet information must survive. Treat this as policy design, not production script code.
A signer can lose a key, backups can omit the policy, or a recovery delay can be misunderstood. Document both normal and recovery paths and test with nonvaluable examples. A timelock does not automatically send funds when it expires; an eligible transaction still has to be constructed and included.
Terms in this lesson
- Multisig
- A spending policy requiring several signatures, such as two of three authorised keys.
Prepare a correction note
Describe the passage and the proposed correction. This creates a local note for you to share; it sends nothing. Do not include personal or confidential information.