Schnorr vs. ECDSA: Cryptographic Evolution

With the activation of the Taproot soft fork (BIP 340), Bitcoin expanded its cryptographic engine from legacy ECDSA signatures to include modern Schnorr signatures.

Let's compare the underlying mathematics of both schemes and explore why Schnorr represents a monumental leap forward in speed, privacy, and security.

---

🧮 Comparing the Mathematical Formulations

The differences in how signatures are constructed and validated reveal why Schnorr is mathematically superior:

1. The Signing Equation

• ECDSA:

$$s = k_{\text{ephemeral}}^{-1} \cdot (z + r \cdot k) \pmod n$$

• Schnorr:

$$s = k_{\text{ephemeral}} + e \cdot k \pmod n$$

(where $e = SHA256(R_x \parallel K \parallel m)$, combining the ephemeral point $R$, public key $K$, and message $m$)

2. The Verification Equation

• ECDSA: Compute $u_1 = z \cdot s^{-1}$ and $u_2 = r \cdot s^{-1}$, then verify:

$$\text{x-coordinate of } (u_1 \cdot G + u_2 \cdot K) \equiv r \pmod n$$

• Schnorr: Verify directly using linear point operations:

$$s \cdot G = R + e \cdot K$$

📐 Proof of Schnorr Verification

To prove why $s \cdot G = R + e \cdot K$ holds:

$$s \cdot G = (k_{\text{ephemeral}} + e \cdot k) \cdot G$$

$$s \cdot G = k_{\text{ephemeral}} \cdot G + e \cdot (k \cdot G)$$

$$s \cdot G = R + e \cdot K$$

---

📊 Feature Comparison Matrix

Security & Efficiency Metric	Legacy ECDSA	Schnorr (BIP 340)
Signature Size	70 - 72 bytes (DER format)	64 bytes (Fixed size)
Public Key Size	33 bytes (Compressed)	32 bytes (Compressed)
Linearity	No (Non-linear)	Yes (Perfect Linearity)
Native Multi-Signature	No (Requires script validation)	Yes (MuSig2 key aggregation)
Malleability	Naturally malleable	Provably non-malleable
Batch Verification	No (Must verify individually)	Yes (Speed-aggregates block validation)

---

⚡ Key Architectural Advantages of Schnorr

The algebraic simplicity of Schnorr's formulation resolves several long-standing limitations of ECDSA:

1. Elimination of Signature Malleability

ECDSA signatures are naturally malleable: * Because of y-axis symmetry, if $(r, s)$ is a valid ECDSA signature, then $(r, n - s \pmod n)$ is also a valid signature for the exact same transaction preimage. * This allowed relaying nodes to alter signatures, modifying TxIDs before blocks were mined. * Schnorr prevents this natively. By binding the public key and the ephemeral point $R$ directly inside the challenge hash $e = SHA256(R_x \parallel K \parallel m)$, any attempt to modify or reflect the signature components will cause the hash $e$ to mismatch, instantly breaking the signature.

2. Batch Verification Speedups

In ECDSA, verifying a block containing 1,000 transactions requires executing 1,000 individual, slow coordinate-inversion operations. * Because Schnorr is linear, validating nodes can bundle multiple signatures across a block and verify them all in a single, aggregated mathematical operation. * By combining the equations using random scalar weights:

$$\sum (s_i \cdot G) = \sum (R_i + e_i \cdot K_i)$$

Nodes can validate block signatures simultaneously, accelerating block validation speeds by up to 2.5x and lowering full node system overhead.