TECHNICAL_DOC // CRYPTOGRAPHY / ECDSA
ECDSA
ECDSA (Elliptic Curve signature/">Digital Signature Algorithm) is Bitcoin's original signing
algorithm, used for P2PKH, P2SH, and P2WPKH outputs. A signature consists of two
integers (r, s) encoded in DER format. The signature proves the signer knows the private
key corresponding to the public key — without revealing the private key. schnorr-signatures/">Schnorr signatures
replaced ECDSA for P2TR outputs in Taproot.
SIGNING_AND_VERIFICATION
ECDSA SIGNING
Inputs:
privkey = x (256-bit integer)
message = tx sighash (32-byte hash)
Steps:
1. Generate nonce: k = RFC6979(privkey, message)
(deterministic, unique, unpredictable)
2. R = k × G (curve point)
3. r = R.x mod n (x-coordinate only)
4. s = k⁻¹ × (hash + x × r) mod n
Output: signature (r, s) where r,s are 32 bytes each
DER encoded: ~71–72 bytes total
Sighash types (appended as 1 byte):
0x01 SIGHASH_ALL: commit to all inputs + outputs
0x02 SIGHASH_NONE: commit to all inputs only
0x03 SIGHASH_SINGLE: commit to matching output
VERIFICATION
ECDSA VERIFICATION
Inputs:
pubkey = P (curve point)
message = tx sighash (32 bytes)
signature = (r, s)
Steps:
1. w = s⁻¹ mod n
2. u1 = hash × w mod n
3. u2 = r × w mod n
4. X = u1×G + u2×P (curve computation)
5. Check: X.x mod n == r
If check passes: signature is valid for this pubkey + message.
Anyone can verify — no private key needed.
WIRE FORMAT
Bitcoin ECDSA signatures are DER (Distinguished Encoding Rules) encoded — a specific ASN.1 format for encoding the (r, s) pair with a length prefix.
DER-encoded ECDSA signature structure:
0x30 SEQUENCE marker
<len> total remaining length
0x02 INTEGER marker (for r)
<rlen> length of r (32 or 33 bytes)
<r> r value (padded with 0x00 if high bit set)
0x02 INTEGER marker (for s)
<slen> length of s
<s> s value
<sighash_type> appended (not part of DER itself)
Total: typically 71–72 bytes (+ 1 byte sighash type)
Maximum: 73 bytes
BIP 66 (2015): strict DER encoding required
→ Eliminated malleability via non-canonical encodings
TERMINOLOGY_INDEX
ECDSA
Elliptic Curve Digital Signature Algorithm. Bitcoin's original signing algorithm, producing (r,s) pairs.
Nonce k
A per-signature random value. Must be unique — reuse leaks the private key. nonce/">RFC 6979 makes it deterministic.
DER Encoding
Sighash Type
1-byte flag appended to signature specifying which parts of the transaction are signed (ALL/NONE/SINGLE).
RFC 6979
Deterministic nonce generation: k = HMAC-SHA256(privkey, message). Eliminates catastrophic nonce reuse.
INTERACTIVE — TRY IT YOURSELF
CRYPTOGRAPHY / SIGNATURES
ECDSA
ECDSA (Elliptic Curve Digital Signature Algorithm) is how Bitcoin transactions are authorized. A signature proves you know the private key corresponding to a public key — without revealing the key itself. The algorithm produces two integers
(r, s) where r is the x-coordinate of a random EC point and s is a linear combination of the message hash, nonce, and private key. Anyone can verify the signature using only the public key.
SIGNING — THE MATH
To sign message hash
z with private key d: choose a random nonce k, compute R = k·G, then r = R.x mod n and s = k⁻¹(z + r·d) mod n. The pair (r, s) is the signature. The security of this entire scheme rests on k being truly random and never reused.
ECDSA SIGN & VERIFYreal secp256k1 via WebCrypto
VERIFICATION — THE MATH
To verify signature
(r, s) against message hash z and public key Q: compute w = s⁻¹ mod n, then u₁ = z·w mod n, u₂ = r·w mod n, and check if (u₁·G + u₂·Q).x mod n == r. This works because substituting the sign equation back shows both sides reduce to k·G.
VERIFY EXISTING SIGNATUREpaste r, s, pubkey, message
THE NONCE REUSE CATASTROPHE
If the same nonce
k is used for two different messages, an attacker who observes both signatures can algebraically recover the private key. This isn't theoretical — it has happened in practice (PlayStation 3 hack, 2010). Bitcoin uses RFC 6979 deterministic nonce generation to make this impossible.
NONCE REUSE ATTACK DEMOwatch private key get extracted
⚠ ATTACK SCENARIO — SAME k USED TWICE
RFC 6979 deterministic nonces: Bitcoin Core generates the signing nonce as
k = HMAC-SHA256(privkey, hash) — a deterministic function of the private key and message hash. This guarantees k is never reused across different messages and never predictable, eliminating the nonce-reuse attack entirely.
DER encoding: Bitcoin signatures are DER-encoded before being placed in transaction scripts. DER wraps each of r and s as ASN.1 INTEGER values, prepending length bytes. A DER signature is 70–72 bytes (r and s can be 32 or 33 bytes each; a leading 0x00 byte is added if the high bit is set to avoid confusion with negative numbers in ASN.1).