# secp256k1

secp256k1 is the elliptic curve used by Bitcoin, Ethereum, and hundreds of other cryptocurrencies for digital signatures and public-key cryptography. It is defined in the [SEC 2](https://www.secg.org/sec2-v2.pdf) standard published by Certicom Research (now part of BlackBerry). Since Satoshi Nakamoto chose it for Bitcoin in 2009, secp256k1 has become the most economically significant elliptic curve in existence, securing hundreds of billions of dollars in digital assets.

## Name Breakdown

The name `secp256k1` encodes exactly what the curve is:

| Segment | Meaning |
|---------|---------|
| **sec** | Standards for Efficient Cryptography |
| **p** | Prime field (F_p), as opposed to binary field (F_2^m) |
| **256** | The bit length of the field prime |
| **k** | Koblitz curve (a = 0), as opposed to random (r) curves |
| **1** | First (and only) curve with these parameters in the standard |

## Curve Definition

secp256k1 is defined by the short Weierstrass equation:

```
y^2 = x^3 + 7  (mod p)
```

This is a special case of `y^2 = x^3 + ax + b` where `a = 0` and `b = 7`. The simplicity of `a = 0` is what makes it a Koblitz curve and enables the GLV endomorphism optimization.

## Quick Facts

| Property | Value |
|----------|-------|
| **Type** | Koblitz elliptic curve over a prime field |
| **Equation** | y^2 = x^3 + 7 |
| **Field prime (p)** | 2^256 - 2^32 - 977 = `FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFC2F` |
| **Generator point (G)** | (`79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798`, `483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8`) |
| **Group order (n)** | `FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141` |
| **Cofactor (h)** | 1 |
| **Private key size** | 32 bytes (256 bits) |
| **Public key (compressed)** | 33 bytes (02/03 prefix + 32-byte x-coordinate) |
| **Public key (uncompressed)** | 65 bytes (04 prefix + 32-byte x + 32-byte y) |
| **Public key (x-only, BIP-340)** | 32 bytes |
| **ECDSA signature** | 64 bytes (r, s) or 70-72 bytes DER-encoded |
| **Schnorr signature (BIP-340)** | 64 bytes |
| **Hash function** | SHA-256 (for Bitcoin), Keccak-256 (for Ethereum) |
| **Standards** | SEC 2 v2, ANSI X9.62, FIPS 186-4 |
| **Security level** | ~128 bits |
| **Reference implementation** | [libsecp256k1](https://github.com/bitcoin-core/secp256k1) (Bitcoin Core) |

## Why secp256k1 Matters

In 2008, Satoshi Nakamoto selected secp256k1 for Bitcoin's digital signature scheme. This was an unconventional choice -- at the time, the NIST P-256 curve was the standard recommendation and secp256k1 was rarely used. Satoshi never publicly explained the choice, but the curve's properties suggest deliberate reasoning:

- **No suspicious constants.** Unlike NIST curves, whose parameters were generated by processes that the NSA influenced, secp256k1's parameters are nearly the simplest possible values (a = 0, b = 7) with no unexplained seed values. This makes a cryptographic backdoor far less plausible.
- **Performance advantages.** The Koblitz structure and special prime form enable optimizations not available on random curves.
- **Cofactor of 1.** Every point on the curve (except the point at infinity) is in the generator's subgroup, eliminating an entire class of implementation vulnerabilities.

Today secp256k1 secures the private keys behind:

- **Bitcoin** -- ~$1 trillion+ market cap
- **Ethereum** -- ~$300 billion+ market cap
- **Litecoin, Dogecoin, Bitcoin Cash**, and hundreds of other chains
- **Lightning Network** -- Bitcoin's layer-2 payment network
- **Nostr** -- decentralized social protocol

## Key Properties

### Koblitz Curve and the GLV Endomorphism

Because `a = 0`, secp256k1 has an efficiently computable endomorphism (the GLV endomorphism). For a point P on the curve, there exists a value `lambda` such that:

```
lambda * P = (beta * x, y)
```

where `beta` is a cube root of unity modulo p. This allows scalar multiplication `k * G` to be decomposed into two half-size multiplications that can be computed simultaneously, yielding approximately 33% faster operations compared to generic curves.

### Special Prime Structure

The field prime `p = 2^256 - 2^32 - 977` has a structure that permits highly efficient modular reduction. The small "tail" (`2^32 + 977`) means that reduction modulo p can be performed with a few additions and shifts rather than general-purpose division, making field arithmetic significantly faster than curves over arbitrary primes.

### Cofactor 1

The cofactor `h = 1` means the group of rational points on the curve has prime order equal to n. Every non-identity point generates the full group. This eliminates small-subgroup attacks and simplifies protocol design -- there is no need for cofactor multiplication or point validation beyond confirming the point is on the curve.

## Signature Schemes

secp256k1 supports two signature schemes in widespread use:

### ECDSA (Elliptic Curve Digital Signature Algorithm)

ECDSA is the original signature scheme used by Bitcoin since its launch in 2009. A signature consists of two 256-bit integers (r, s).

- **Standard**: ANSI X9.62, FIPS 186-4
- **Deterministic nonces**: RFC 6979 eliminates the catastrophic risk of nonce reuse by deriving the nonce deterministically from the private key and message hash
- **Signature size**: 64 bytes raw (r, s), or 70-72 bytes DER-encoded
- **Malleability**: Given a valid signature (r, s), the pair (r, n - s) is also valid. Bitcoin enforces low-s normalization (BIP-62/BIP-146) to mitigate this.

### Schnorr Signatures (BIP-340)

Schnorr signatures were activated on Bitcoin via the Taproot soft fork (November 2021). They offer several advantages over ECDSA:

- **Linearity**: Schnorr signatures are linearly composable, enabling native multisignature schemes (MuSig2) and adaptor signatures
- **Provable security**: Provably secure in the random oracle model under the discrete logarithm assumption (no generic group model needed as with ECDSA)
- **Batch verification**: Multiple Schnorr signatures can be verified together faster than individually
- **Signature size**: 64 bytes (32-byte R x-coordinate + 32-byte s)
- **Key format**: Uses x-only public keys (32 bytes), assuming even y-coordinate
- **Standard**: [BIP-340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki)

## Key Formats

| Format | Size | Prefix | Description |
|--------|------|--------|-------------|
| **Uncompressed** | 65 bytes | `04` | Full x and y coordinates |
| **Compressed** | 33 bytes | `02` or `03` | x-coordinate + parity of y |
| **X-only (BIP-340)** | 32 bytes | none | x-coordinate only, y is implicitly even |
| **DER-encoded (public)** | ~88 bytes | `30` | ASN.1 DER with OID |

Compressed keys are standard in Bitcoin since 2012. Ethereum uses uncompressed keys internally but represents addresses as the last 20 bytes of the Keccak-256 hash of the uncompressed public key (without the 04 prefix).

## Performance

Approximate operations per second on modern hardware (single core, x86-64, libsecp256k1):

| Operation | Throughput |
|-----------|-----------|
| Key generation | ~50,000 ops/s |
| ECDSA signing | ~40,000 ops/s |
| ECDSA verification | ~15,000 ops/s |
| Schnorr signing | ~40,000 ops/s |
| Schnorr verification | ~17,000 ops/s |
| Schnorr batch verification (64 sigs) | ~30,000 ops/s |
| ECDH key exchange | ~25,000 ops/s |

libsecp256k1 achieves this performance through constant-time algorithms, the GLV endomorphism, and wNAF (windowed Non-Adjacent Form) scalar multiplication with precomputed tables.

## Comparison with Other Curves

| Property | secp256k1 | Ed25519 | NIST P-256 | RSA-2048 |
|----------|-----------|---------|------------|----------|
| **Type** | Weierstrass / Koblitz | Twisted Edwards | Weierstrass / random | Integer factorization |
| **Security level** | ~128 bits | ~128 bits | ~128 bits | ~112 bits |
| **Private key** | 32 bytes | 32 bytes | 32 bytes | ~256 bytes |
| **Public key** | 33 bytes (compressed) | 32 bytes | 33 bytes (compressed) | 256 bytes |
| **Signature** | 64-72 bytes | 64 bytes | 64-72 bytes | 256 bytes |
| **Verification speed** | Fast | Fastest | Fast | Slow |
| **Batch verification** | Schnorr only | Yes | No | No |
| **Cofactor** | 1 | 8 | 1 | N/A |
| **Parameter origin** | Deterministic (a=0, b=7) | Deterministic | NSA-seeded | N/A |
| **Primary use** | Cryptocurrencies | SSH, TLS, age | TLS, government | Legacy TLS, PKI |
| **Quantum resistant** | No | No | No | No |

## Where secp256k1 Is Used

### Cryptocurrencies

- **Bitcoin (BTC)** -- ECDSA (since 2009) and Schnorr (since 2021, Taproot)
- **Ethereum (ETH)** -- ECDSA with Keccak-256 hashing, ecrecover precompile
- **Litecoin (LTC)** -- ECDSA, same key derivation as Bitcoin
- **Dogecoin (DOGE)** -- ECDSA, Bitcoin-derived
- **Bitcoin Cash (BCH)**, **Bitcoin SV (BSV)**, **Zcash (ZEC)**, **Tezos (XTZ)**
- Hundreds of Bitcoin and Ethereum forks and derivatives

### Protocols

- **Lightning Network** -- payment channels, HTLCs, point-time-locked contracts
- **Nostr** -- decentralized social protocol, uses Schnorr signatures (BIP-340) for event signing
- **DLCs (Discreet Log Contracts)** -- adaptor signatures on secp256k1
- **RGB Protocol** -- smart contracts on Bitcoin using secp256k1

### Standards

- **BIP-32** -- Hierarchical Deterministic wallets (HD wallets)
- **BIP-39** -- Mnemonic seed phrases mapped to secp256k1 keys
- **BIP-340** -- Schnorr signatures for secp256k1
- **BIP-341/342** -- Taproot and Tapscript
- **EIP-155** -- Ethereum replay protection via chain ID in ECDSA
- **EIP-712** -- Typed structured data signing with secp256k1 ECDSA

## History

| Year | Event |
|------|-------|
| 2000 | Certicom publishes SEC 2 v1, defining secp256k1 among other curves |
| 2008 | Satoshi Nakamoto publishes the Bitcoin whitepaper |
| 2009 | Bitcoin launches with secp256k1 ECDSA as its signature scheme |
| 2010 | SEC 2 v2 published with minor editorial updates |
| 2013 | Pieter Wuille begins libsecp256k1 for Bitcoin Core, replacing OpenSSL |
| 2015 | Ethereum launches, adopting secp256k1 with Keccak-256 |
| 2015 | libsecp256k1 integrated into Bitcoin Core v0.10.0 |
| 2018 | BIP-340 (Schnorr) proposal drafted by Pieter Wuille, Jonas Nick, Tim Ruffing |
| 2020 | Taproot (BIP-341) soft fork locked in |
| 2021 | Taproot activates on Bitcoin (block 709,632, November 14) |
| 2021 | MuSig2 specification finalized for multi-party Schnorr signatures |
| 2023 | Nostr protocol gains adoption, bringing secp256k1 Schnorr to social media |

## Reference Implementation

[libsecp256k1](https://github.com/bitcoin-core/secp256k1) is the authoritative C library maintained by Bitcoin Core contributors. It is:

- **Constant-time**: All secret-dependent operations run in constant time to prevent side-channel attacks
- **Formally reviewed**: Extensively audited and reviewed by cryptographers
- **Optimized**: Uses the GLV endomorphism, efficient field arithmetic, and precomputed tables
- **Widely wrapped**: Bindings exist for Rust, Python, JavaScript, Go, Java, and most other languages

Other notable implementations include [noble-secp256k1](https://github.com/paulmillr/noble-secp256k1) (JavaScript/TypeScript), the [k256](https://crates.io/crates/k256) crate (Rust), and [btcec](https://pkg.go.dev/github.com/btcsuite/btcd/btcec/v2) (Go).

## Recipes (Copy-Paste Ready)

Task-oriented guides with runnable commands and code. See [all recipes](/recipes/index.md).

| Task | Command |
|------|---------|
| Generate Ethereum wallet | `cast wallet new` |
| Get address from key | `cast wallet address --private-key 0x...` |
| Sign message | `cast wallet sign "hello" --private-key 0x...` |
| Send transaction | `cast send <TO> --value 0.1ether --private-key 0x...` |
| Generate HD wallet | `cast wallet new-mnemonic` |
| Generate Nostr keypair | `nak key generate` |

## Site Navigation

### Recipes
- [Recipes Overview](recipes/index.md) -- Task-oriented, copy-paste-ready guides
- [Ethereum Wallet](recipes/ethereum-wallet.md) | [Sign Transaction](recipes/ethereum-sign-tx.md) | [Sign Message](recipes/ethereum-sign-message.md) | [Verify in Solidity](recipes/ethereum-verify-solidity.md)
- [Bitcoin Address](recipes/bitcoin-address.md) | [Sign Transaction](recipes/bitcoin-sign-tx.md)
- [HD Wallet](recipes/hd-wallet.md) | [Nostr](recipes/nostr.md) | [Key Conversion](recipes/key-conversion.md) | [Cast Cheatsheet](recipes/cast-cheatsheet.md)

### Specification
- [Specification Overview](specification/index.md) -- Full mathematical definition
- [Curve Equation](specification/curve.md) -- Weierstrass form and field arithmetic
- [Domain Parameters](specification/parameters.md) -- p, G, n, h and their derivation
- [ECDSA](specification/ecdsa.md) -- Signing and verification algorithms
- [Schnorr Signatures](specification/schnorr.md) -- BIP-340 specification
- [Encoding Formats](specification/encoding.md) -- SEC 1 point serialization

### Practical Guides
- [Guide Overview](guide/index.md) -- Getting started with secp256k1
- [Key Generation](guide/key-generation.md) -- Secure private and public key creation
- [ECDSA Signing](guide/signing-ecdsa.md) -- How to sign with ECDSA
- [Schnorr Signing](guide/signing-schnorr.md) -- How to sign with BIP-340 Schnorr
- [Signature Verification](guide/verification.md) -- Verifying signatures correctly
- [Key Formats](guide/key-formats.md) -- Compressed, uncompressed, x-only

### Bitcoin
- [Bitcoin Overview](bitcoin/index.md) -- secp256k1 in Bitcoin
- [Bitcoin Addresses](bitcoin/addresses.md) -- From public key to address
- [Transactions](bitcoin/transactions.md) -- Signing Bitcoin transactions
- [Taproot](bitcoin/taproot.md) -- BIP-341 and Schnorr in Bitcoin
- [HD Wallets](bitcoin/hd-wallets.md) -- BIP-32 hierarchical deterministic keys
- [MuSig2](bitcoin/musig2.md) -- Multi-party Schnorr signing
- [Schnorr in Bitcoin](bitcoin/schnorr.md) -- BIP-340 adoption and usage

### Ethereum
- [Ethereum Overview](ethereum/index.md) -- secp256k1 in Ethereum
- [Ethereum Addresses](ethereum/addresses.md) -- Keccak-256 derivation
- [Transactions](ethereum/transactions.md) -- Signing Ethereum transactions
- [ecrecover](ethereum/ecrecover.md) -- On-chain signature recovery
- [EIP-712](ethereum/eip712.md) -- Typed structured data signing
- [Smart Contracts](ethereum/smart-contracts.md) -- On-chain signature verification

### Comparison
- [Comparison Overview](comparison/index.md) -- secp256k1 vs other curves
- [vs Ed25519](comparison/vs-ed25519.md) -- Detailed comparison
- [vs NIST P-256](comparison/vs-p256.md) -- Detailed comparison
- [ECDSA vs Schnorr](comparison/ecdsa-vs-schnorr.md) -- Signature scheme tradeoffs

### Security
- [Security Overview](security/index.md) -- Security properties and threat model
- [Strengths](security/strengths.md) -- Why secp256k1 is considered secure
- [Nonce Vulnerabilities](security/nonce-vulnerabilities.md) -- The critical role of nonce generation
- [Signature Malleability](security/malleability.md) -- Transaction malleability and mitigations
- [Implementation Pitfalls](security/implementation-pitfalls.md) -- Common developer mistakes
- [Quantum Computing](security/quantum.md) -- Post-quantum threat analysis

### Implementations
- [Implementations Overview](implementations/index.md) -- Library landscape
- [libsecp256k1 (C)](implementations/libsecp256k1.md) -- Bitcoin Core's reference library
- [Rust](implementations/rust.md) -- k256, secp256k1-rs
- [JavaScript](implementations/javascript.md) -- noble-secp256k1, elliptic
- [Python](implementations/python.md) -- coincurve, ecdsa
- [Go](implementations/go.md) -- btcec, go-ethereum/crypto
- [Java](implementations/java.md) -- BouncyCastle, web3j

### Adoption
- [Adoption Overview](adoption/index.md) -- Ecosystem map
- [Bitcoin](adoption/bitcoin.md) -- Adoption in Bitcoin
- [Ethereum](adoption/ethereum.md) -- Adoption in Ethereum
- [Other Chains](adoption/other-chains.md) -- Litecoin, Dogecoin, Zcash, and more
- [Nostr](adoption/nostr.md) -- Decentralized social protocol
- [Lightning Network](adoption/lightning.md) -- Layer-2 payment channels

### Advanced Topics
- [Advanced Overview](advanced/index.md) -- Deep technical topics
- [GLV Endomorphism](advanced/glv-endomorphism.md) -- Performance optimization
- [Batch Verification](advanced/batch-verification.md) -- Verifying multiple signatures efficiently
- [Adaptor Signatures](advanced/adaptor-signatures.md) -- Scriptless scripts
- [Threshold Signatures](advanced/threshold-signatures.md) -- Distributed key generation

### History and Resources
- [History](history/index.md) -- Timeline from Certicom to Taproot
- [Origins](history/origins.md) -- Why Satoshi chose secp256k1
- [Resources](resources/index.md) -- Further reading
- [Academic Papers](resources/papers.md) -- Key research papers
- [Glossary](resources/glossary.md) -- Terminology reference