MASTERING-BITCOIN · Interactive Practice | Unit 8 · Video 3

One Signature to Rule Them All: Taproot

IKey Formulas Reference

Formula	Name	Description
$P_{\text{tweaked}} = P + t \cdot G$	Public key tweak	Adds $t \cdot G$ to existing pubkey
$p_{\text{tweaked}} = p + t$	Private key tweak	Mirror operation on private key
$P_{\text{combined}} = P_a + P_b + P_c$	Scriptless multisig key	Sum of partial public keys
$Q = P + H(P, \text{root}) \cdot G$	Taproot output key	Internal key tweaked by MAST root

IIInteractive Visualizations

Visualization 1: How Multisig Bytes Scale

Traditional (scripted) multisig lists every signature on-chain — bytes grow linearly with the number of signers. Scriptless multisig, enabled by Schnorr signatures, aggregates everything into one 64-byte signature regardless of how many signers participated.

Use the slider to vary the number of signers and see how the on-chain footprint changes for each approach.

⚙ interactive visualization — coming to this page format soon

Visualization 2: Keypath vs Scriptpath Witness Size

A Taproot output offers two ways to spend:

Keypath: A single 64-byte Schnorr signature. Indistinguishable from any other Taproot single-sig spend.
Scriptpath: Reveal the internal key, the leaf script, every Merkle path hash up to the MAST root, plus any data the script consumes.

Adjust the MAST tree depth and the script size to see how scriptpath bytes pile up while keypath stays flat.

⚙ interactive visualization — coming to this page format soon

Visualization 3: Pay-to-Contract Tweaking

Bob commits to a message by hashing it into a tweak $t$ and paying to $P + t \cdot G$ . On-chain it looks like an ordinary payment. Later anyone given the message and Alice's original key can recompute the tweak and verify the commitment.

Choose a message and watch how the tweak (and resulting tweaked address) change. Notice that any change in the message produces a completely different — but still ordinary-looking — address.

⚙ interactive visualization — coming to this page format soon

Reflect: Switching the message by even one character produces a wildly different tweak and address. Yet on-chain, both look like ordinary single-key payments. What does this property give us that a transaction OP_RETURN memo cannot?

IIIQuiz Questions

Question 1

Three signers cooperate using scriptless multisig to spend a Taproot output via the keypath. Roughly how many bytes does the on-chain signature occupy?

✅ Correct! Scriptless multisig collapses any number of cooperating signers into a single 64-byte Schnorr signature.

❌ Not quite. That answer describes scripted multisig (linear in signers). Scriptless multisig aggregates everything into one signature.

Show solution

Solution:

Scriptless multisig combines partial public keys into a single combined key $P = P_a + P_b + P_c$ and partial signatures into a single Schnorr signature $s$ . The chain sees one key, one signature — about 64 bytes — regardless of whether 3 or 3 million signers contributed.

That is precisely the constant-scaling property visualized above: the on-chain footprint does not grow with the number of cooperating signers.

Question 2

True or False: When Alice, Bob, and Carol use a 2-of-3 scriptless threshold signature to spend a Taproot output via the keypath, an outside observer can determine which two of them actually signed.

✅ Correct! All threshold pairings produce signatures indistinguishable from each other — and from a single-key spend.

❌ Not quite. Scriptless multisig erases the audit trail entirely; the chain records only that the combined key signed.

Show solution

Solution:

In a scriptless threshold signature, every valid pairing — {Alice, Bob}, {Alice, Carol}, {Bob, Carol} — produces a signature that is byte-identical in structure to a single-key spend. The on-chain artifact is just one combined public key and one Schnorr signature.

This is exactly the privacy/accountability tension from the video: outsiders cannot tell who signed (great for privacy), but neither can a participant prove they did not sign (bad for accountability).

Question 3

A Taproot output key is constructed as $Q = P + H(P, \text{root}) \cdot G$ , where $P$ is the internal key and $\text{root}$ is the MAST root.

Which of the following is revealed on-chain during a keypath spend (the cooperative happy path)?

✅ Correct! Only $Q$ and one signature appear on-chain — the script branches and the internal key stay hidden.

❌ Not quite. That information is revealed only on a scriptpath spend. The keypath is deliberately minimal.

Show solution

Solution:

A keypath spend is the cheapest, most private path: the spender already knows the combined private key for $Q$ and signs directly. The chain sees:

the output key $Q$ (already in the previous output's script)
one 64-byte Schnorr signature

The internal key $P$ , the MAST root, leaf scripts, and Merkle paths stay hidden unless someone later takes the scriptpath. That asymmetry is what makes complex contracts indistinguishable from "Alice paying for coffee" when everyone cooperates.

Question 4

Tapscript replaces the legacy OP_CHECKMULTISIG with OP_CHECKSIGADD. What is the primary technical reason for this change?

✅ Correct! No early exit means every signature is verified, which is exactly what Schnorr batch verification requires.

❌ Not quite. The motivation is about batch verification compatibility, not size, signer counts, or thresholds.

Show solution

Solution:

Legacy OP_CHECKMULTISIG short-circuits as soon as enough signatures verify, which is incompatible with Schnorr batch verification (where signatures are verified together as one big check across the entire transaction).

OP_CHECKSIGADD is a simpler, non-short-circuiting opcode:

Pop a signature, a public key, and a counter.
If the signature is valid, push counter + 1; otherwise push the counter unchanged.
Run once per signer; at the end, compare the counter against the threshold.

Because every signature is always checked, batch verification works cleanly across the whole transaction.

Solved: 0 / 4