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

One Signature, Many Signers: Schnorr Multisig and Threshold Signing

IKey Formulas

Formula	Name	Description
$s = k + c \cdot x$	Schnorr signature scalar	Signer with private key $x$ , nonce $k$ , challenge $c$
$sG = kG + c \cdot xG$	Verification equation	Confirms knowledge of $x$
$x = y + z$	Key aggregation	Combined private key (kept secret)
$s = s_A + s_B = (a+b) + c(y+z)$	Signature aggregation	Sum of partial signatures
$c = H(kG \,\Vert\, xG \,\Vert\, m)$	Challenge	Hash of aggregate nonce, key, message

IIVisualization 1: The Linearity of Schnorr Signatures

Schnorr signatures aggregate cleanly because every operation is linear. Two signers each produce a partial scalar; those partials simply add to a valid joint signature.

Adjust Alice's and Bob's private keys, their nonces, and the challenge. Watch the partial signatures combine and confirm that $s_A + s_B = k + c \cdot x$ — always.

(All scalars are reduced modulo the group order $n$ . We use $n = 23$ for visualization clarity; real Schnorr uses a 256-bit prime order.)

⚙ interactive visualization — coming to this page format soon

Notice: No matter what values you pick for the private keys, nonces, or challenge, the sum of partial signatures always equals the signature computed directly from the aggregate key and aggregate nonce. The blockchain sees only the final pair $(kG, s)$ — it cannot distinguish a Schnorr signature made by one signer from one made by a million.

IIIVisualization 2: The Key Cancellation Attack

Linearity is a gift, but it can be weaponized. If Bob is allowed to choose his public key after seeing Alice's, he can subtract Alice out of the aggregate.

Toggle between honest and malicious Bob. When malicious, Bob declares his public key as $zG - yG$ instead of $zG$ . The naive sum then collapses $yG + (zG - yG) = zG$ — Bob alone controls the aggregate.

⚙ interactive visualization — coming to this page format soon

Reflect: When malicious Bob publishes $zG - yG$ , the aggregate becomes $yG + (zG - yG) = zG$ . Bob alone can sign — Alice was written out of her own multisig.

The fix is commit-then-reveal: every party first publishes a hash of their public key, then reveals the key only after seeing everyone else's commitment. Bob can no longer pick his key in response to Alice's.

IVVisualization 3: Threshold Signing — t-of-k

A t-of-k threshold signature lets any $t$ of $k$ signers produce a valid signature, even if the others are offline. The on-chain output looks identical to a $k$ -of- $k$ aggregate.

Adjust $t$ and $k$ , then choose how many signers are online. Watch when the protocol succeeds — and remember: the chain cannot tell who actually signed.

⚙ interactive visualization — coming to this page format soon

Notice: When the threshold is met, partial signatures combine into a single Schnorr signature — the chain sees no difference between $t$ -of- $k$ and a single signer. Accountability is gone.

Beware also the manipulation attack: a malicious participant who runs parallel signing sessions (claiming different members are offline in each) can harvest enough reconstructed shares to sign alone. The mitigation is a broadcast channel where every protocol message is visible to all participants, so inconsistent parallel sessions cannot exist undetected.

VQuiz Questions

Question 1

Alice has private key $y = 3$ and Bob has private key $z = 4$ . They run a Schnorr two-party signing protocol. Alice picks nonce $a = 2$ , Bob picks nonce $b = 5$ , and the challenge is $c = 2$ .

What is the combined signature scalar $s = s_A + s_B$ ?

(Recall: $s_A = a + c \cdot y$ and $s_B = b + c \cdot z$ . Values are small enough that no modular reduction is needed.)

✅ Correct! $s_A = 8$ , $s_B = 13$ , and $s_A + s_B = 21$ .

❌ Not quite. Make sure you compute both partials ( $s_A$ and $s_B$ ) and sum them. Don't forget that the challenge $c$ multiplies the private key in each partial.

Show solution

Solution:

Compute each partial signature:

$s_A = a + c \cdot y = 2 + 2 \cdot 3 = 2 + 6 = 8$

$s_B = b + c \cdot z = 5 + 2 \cdot 4 = 5 + 8 = 13$

Sum the partials:

$s = s_A + s_B = 8 + 13 = 21$

We can verify with the aggregate form: $x = y + z = 7$ , $k = a + b = 7$ , so $s = k + c \cdot x = 7 + 2 \cdot 7 = 21$ . The two computations agree — linearity holds.

Question 2

In a naive Schnorr multisig, Alice publishes her public key $yG$ first. Bob, who is malicious and sees Alice's key before committing, wants to execute a key cancellation attack so that he alone controls the aggregate public key.

What public key should Bob publish?

✅ Correct! Publishing $zG - yG$ makes the aggregate $yG + (zG - yG) = zG$ , cancelling Alice.

❌ Not quite. The attack exploits linearity: Bob picks his key so that adding it to Alice's leaves only Bob's secret. What value, when added to $yG$ , gives $zG$ ?

Show solution

Solution:

Bob wants the aggregate (the naive sum of public keys) to equal only his own key $zG$ . If he publishes $zG - yG$ , then the aggregate becomes:

$yG + (zG - yG) = zG$

Alice's contribution cancels out. Bob alone holds the corresponding private key $z$ , so he alone can sign — even though Alice still believes she's a co-signer.

Mitigation: A commit-then-reveal step. Every signer first publishes a hash of their public key. Only after all commitments are gathered does each party reveal the actual key. Bob can no longer choose his key in response to Alice's.

Question 3

Three friends, Alice, Bob, and Carol, set up a 2-of-3 threshold signature scheme. They successfully produce a signature on a Bitcoin transaction and broadcast it.

What can a third-party verifier examining the on-chain signature determine?

✅ Correct! The chain only sees a single Schnorr signature verifying against the aggregate key. Privacy is gained; accountability is lost.

❌ Not quite. Recall that aggregated signatures look identical to single-signer signatures on-chain — the blockchain has no way to identify individual signers.

Show solution

Solution:

A correctly executed threshold signature looks identical to a single Schnorr signature on-chain. The verifier checks the standard equation $sG = kG + c \cdot xG$ against the aggregate public key $xG$ — and that is all the chain reveals.

The verifier learns:

The signature is valid against the aggregate key.

The verifier does not learn:

❌ How many people signed
❌ Which specific signers participated
❌ Whether it was a threshold scheme at all (vs. a single signer)

This is excellent for privacy: a multisig wallet looks identical to a single-key wallet. But it is also why accountability is lost — there's no on-chain evidence of who authorized the transaction.

Question 4

In threshold signing, Bob mounts the manipulation attack by running parallel signing sessions: in one session he tells Alice that Carol is offline, and in another he tells Carol that Alice is offline. By doing so he reconstructs Alice's and Carol's partial keys and ends up holding all three.

What is the standard mitigation?

✅ Correct! A shared broadcast channel makes inconsistent parallel sessions impossible to hide.

❌ Not quite. The attack relies on Bob being able to tell different stories to different signers in private. What protocol property would prevent that?

Show solution

Solution:

The manipulation attack succeeds because Bob can run two inconsistent parallel sessions that the other participants cannot see. The defense is to make every protocol message visible to all participants:

A shared broadcast channel ensures that no two participants can hold contradictory views of who is online. If Bob tries to claim "Carol is offline" to Alice while simultaneously claiming "Alice is offline" to Carol, both inconsistencies become visible and the protocol aborts.

Why the others don't fix it:

Deterministic nonces (MuSig-DN) protect against nonce reuse, not against parallel-session manipulation.
Commit-then-reveal addresses the key cancellation attack at setup time, not session-level manipulation.
Requiring all signers (t = k) defeats the purpose of a threshold scheme — the attack still works against any t < k anyway.

Implementing a reliable broadcast channel over an adversarial network is genuinely hard, and is one of the open engineering challenges in threshold signing.

Solved: 0 / 4