Taproot & Tapscript

Taproot (SegWit v1) lets coins be spent with a single Schnorr signature in the common case, while still allowing complex scripts as hidden alternatives. Addresses look like bc1p... (Bech32m).

Why this matters

Taproot improves privacy and efficiency for multisig-like policies and future Lightning constructions. Modern wallet descriptors increasingly default to Taproot.

Analogy

A Taproot output is a house with a normal front door (key path) and several secret side doors (script leaves). Neighbors usually only see you use the front door, they never learn which side doors exist unless you open one.

Two ways to spend

1. Key-path: sign with the tweaked output key, cheapest and most private
2. Script-path: reveal a script leaf + merkle proof + satisfy that script

Tapscript

Script-path leaves use Tapscript, Script with Taproot-specific rules and Schnorr CHECKSIG behavior. Multisig and timelock policies can live in leaves while cooperative spends stay on the key path (especially with MuSig-style aggregation).

Common mistakes

• Treating Taproot as “just a new address” without descriptors/backup of the script tree
• Losing the internal key / merkle info needed for script-path recovery
• Mixing Bech32 (v0) and Bech32m (v1) validation

Internal key and tweak

Taproot output keys commit to an internal key tweaked by a merkle root of scripts (or a nothing-up-my-sleeve tweak when no scripts). Cooperative MuSig-style key aggregation can make complex custody look like a single key on-chain when everyone agrees.

When script path appears

Script path reveals:

• The leaf script used
• A merkle proof to the tweak
• Satisfaction data (signatures, preimages, etc.)

Unused leaves remain hidden, a privacy and fungibility win versus revealing a full redeem script every time (as with many P2SH spends).

Wallet responsibilities

If you support Taproot script trees, backups must include enough data to reconstruct spends for every leaf you might need, not only the key path.

Worked mental model

Re-read the diagrams in this lesson once out loud in plain language. If you cannot explain the flow to a friend without jargon, pause and revisit Mastering Bitcoin / Mastering Lightning chapters linked in Resources. Chapter references are intentional, not decorative.

Hands-on habit

Every protocol idea should be paired with one local experiment:

1. Reproduce the happy path on regtest (or Polar for Lightning)
2. Break it on purpose (wrong fee, expired invoice, offline peer)
3. Write down what error you saw and which layer produced it (wallet, node, mempool, peer)

That habit turns reading into builder instinct.

Glossary check

Pick three terms from this lesson and define them in one sentence each without opening notes. Weak definitions mean the lesson is not finished yet.

Resource order

Use Resources in order: narrative book chapter first, then BIP/BOLT for precision, then implementation docs for commands. Jumping straight to RPC flags without the mental model creates brittle knowledge.

Next steps

Study multisig and timelocks, the policies often hidden inside Taproot trees and Lightning scripts.