Path: blob/main/foundations/06-elliptic-curves/connect/ecdsa-bitcoin-ethereum.ipynb
483 views
Connect: ECDSA in Bitcoin and Ethereum
Module 06 | Real-World Connections
Every Bitcoin and Ethereum transaction is authorized by an ECDSA signature on the secp256k1 curve. The key generation, signing, and verification you learned in Notebook 06f are exactly what happens when you send cryptocurrency.
Introduction
Bitcoin (2009) chose ECDSA on secp256k1 as its transaction authorization mechanism. Ethereum (2015) adopted the same curve with minor modifications. As of 2025, over $1 trillion in assets are secured by this exact combination of curve and signature scheme.
The flow is:
Key generation: A private key (256 random bits) generates a public key .
Address derivation: The public key is hashed to produce a Bitcoin/Ethereum address.
Transaction signing: To spend coins, the owner signs the transaction hash with ECDSA.
Verification: Every node in the network verifies the signature before accepting the transaction.
Let's trace each step.
The secp256k1 Curve
secp256k1 is defined by:
where . This is a short Weierstrass curve with .
The curve has a generator of prime order , with cofactor (every point other than generates the full group).
Why secp256k1? Satoshi Nakamoto chose it over the more common P-256 (secp256r1). The coefficient makes point doubling slightly faster, and the curve parameters are "nothing up my sleeve" numbers (the simplest curve over that prime).
Step 1: Key Generation
A Bitcoin private key is simply a random integer . The corresponding public key is .
In Bitcoin:
The private key is 32 bytes (256 bits), often encoded in WIF (Wallet Import Format).
The public key is the point , encoded as 33 bytes (compressed: x-coordinate + parity bit) or 65 bytes (uncompressed: both coordinates).
The Bitcoin address is derived by hashing the public key:
RIPEMD160(SHA256(Q)).
Let's demonstrate on a small curve (so the numbers fit on screen), then show the real secp256k1.
Step 2: Transaction Signing
When you send Bitcoin, you create a transaction that says "transfer X BTC from address A to address B." To prove you own address A, you sign the transaction hash with your private key using ECDSA.
The signing process (from Notebook 06f):
Hash the transaction: (Bitcoin uses double-SHA256)
Pick random nonce , compute ,
Compute
Output signature
Ethereum Addition: Public Key Recovery
Ethereum uses the same curve (secp256k1) and the same ECDSA, but adds a feature: public key recovery from the signature.
An Ethereum signature includes a recovery parameter (encoded as 27 or 28). This allows the verifier to recover the signer's public key from just the message and signature, without needing the public key in advance.
The recovery works as follows:
From , compute the point where is chosen based on .
Compute .
The Ethereum address is
keccak256(Q)[12:](last 20 bytes of the hash).
Concept Map: Module 06 in Bitcoin and Ethereum
| Module 06 Concept | Blockchain Application |
|---|---|
| Point multiplication | Private key public key |
| ECDSA signing | Transaction authorization |
| ECDSA verification | Network consensus on valid transactions |
| ECDLP hardness | Cannot forge signatures or derive private key from address |
| Nonce security (Break notebook) | PS3 hack, Android wallet thefts |
| secp256k1 () | Industry-standard curve for blockchain |
| Public key recovery | Ethereum derives sender address from signature |
Summary
| Concept | Key idea |
|---|---|
| secp256k1 | The curve over a 256-bit prime, chosen by Bitcoin and adopted by Ethereum. |
| Key generation | Scalar multiplication turns a private key into a public key . |
| Transaction signing | ECDSA produces a signature that proves ownership of the private key. |
| Network verification | Every node independently verifies the signature, requiring only the public key. |
| Public key recovery | Ethereum adds a recovery parameter , allowing the signer's public key to be derived from the signature alone. |
| ECDLP security | Given , finding is computationally infeasible (roughly operations on secp256k1). |
| Nonce reuse danger | The nonce-reuse attack from the Break notebook has stolen real Bitcoin. Wallets must use RFC 6979 deterministic nonces. |
The nonce-reuse attack from the Break notebook is not theoretical: it has stolen real Bitcoin. Wallet implementations must use RFC 6979 deterministic nonces or risk catastrophic key leakage.
Back to Module 06: Elliptic Curves