Installs into .claude/skills of the current project.
Are you the author of Ecdsa?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/claude-dev-suite-ecdsa)
---
name: bitcoin-ecdsa
description: |
ECDSA signatures over secp256k1: sign/verify, deterministic-k (RFC6979),
low-s (BIP146), DER encoding, malleability, recoverable signatures.
USE WHEN: signing legacy/SegWit-v0 inputs, verifying legacy signatures,
debugging "non-canonical signature" errors.
allowed-tools: Read, Grep, Glob
---
# ECDSA on secp256k1
ECDSA is the original Bitcoin signature scheme. Used for legacy P2PKH,
P2SH, and SegWit v0 (P2WPKH/P2WSH). Replaced by Schnorr in Taproot.
## Sign (private key d, message hash h)
```
1. Generate nonce k ∈ [1, n-1].
2. R = k * G
3. r = R.x mod n. if r == 0, retry.
4. s = k^(-1) * (h + r*d) mod n. if s == 0, retry.
5. Apply low-s normalization: if s > n/2, s = n - s. (BIP146)
6. Output (r, s).
```
The signature is `(r, s)` ∈ Z_n × Z_n.
## Verify (public key Q, message hash h, signature (r, s))
```
1. Check r, s ∈ [1, n-1].
2. w = s^(-1) mod n.
3. u1 = h * w mod n, u2 = r * w mod n.
4. P = u1*G + u2*Q.
5. Verify P.x mod n == r.
```
## Deterministic k (RFC6979)
**CRITICAL**: never reuse k. If you sign two different messages with
the same k, the private key leaks.
```
d * (s1 - s2) = k * (h2 - h1) (mod n)
→ d = (s1 - s2)^(-1) * (h2 - h1) * k (mod n)
```
RFC6979 derives `k` deterministically from `(d, h)` via HMAC-SHA256.
Bitcoin libraries default to RFC6979 — never accept "user-provided"
k unless you implement extra randomness mixing (RFC6979 + extra entropy
pattern, used by some hardware wallets to defeat fault attacks).
## DER encoding (for tx witness)
Bitcoin Script uses ASN.1 DER:
```
30 LL 02 LR <r> 02 LS <s>
```
Where:
- `30` = SEQUENCE tag.
- `LL` = total length following.
- `02` = INTEGER tag.
- `LR` / `LS` = length of r / s.
- `<r>` / `<s>` = big-endian, with leading 0x00 byte if high bit set
(DER strict).
Followed by 1-byte sighash flag in tx witness:
```
<DER signature> <sighash byte>
```
Total length typically 71-72 bytes.
## Strict DER (BIP66)
Bitcoin Core enforces strict DER since 2015 to defeat malleability:
- No extra leading bytes.
- Length fields exactly minimal.
- Integers must be DER-canonical.
Non-DER signatures are rejected at script execution.
## Low-s (BIP146)
Both `(r, s)` and `(r, n-s)` verify against the same message and key.
This is malleability. BIP146 enforces `s ≤ n/2` as standard policy
(strictly enforced in Tapscript and as standard in segwit; mempool
rejects but consensus historically accepts both forms).
## Recoverable signatures
A 65-byte ECDSA encoding `<header byte> r s` lets verifier recover the
public key from the signature alone:
- `header` byte = `27 + recovery_id + (4 if compressed pubkey)`.
- `recovery_id ∈ [0, 3]`: encodes which of (R, -R, R+n, -R+n) to use.
Used by:
- BIP137 message signing.
- Lightning gossip messages (signed announcements).
- Some Ethereum-bridge tools (`ecrecover`).
Not used in raw tx witness (regular DER is more compact for that).
## Common errors
- Reusing k → key leak. **Never** accept an external nonce.
- Skipping low-s normalization → mempool rejection.
- Including a high-s signature in standardness-strict mempools → tx
goes nowhere.
- Off-by-one in DER length encoding (the most common DER bug).
- Confusing nonce `k` with private key `d` in code reviews.
## See also
- [secp256k1/SKILL.md](../secp256k1/SKILL.md)
- [schnorr/SKILL.md](../schnorr/SKILL.md)
- [../../protocol/transactions/quick-ref/sighash.md](../../protocol/transactions/quick-ref/sighash.md)