BA-02 · LESSON 05

ECDSA signatures

KEY DEFINITIONS

Terms used in this lesson

ECDSA: Elliptic Curve Digital Signature Algorithm, the signature scheme used by pre-Taproot Bitcoin outputs.
Low-s: A canonical ECDSA rule selecting the lower of two related s scalar forms.
DER: Distinguished Encoding Rules: the structured byte encoding historically used for ECDSA signatures in Bitcoin Script.
SegWit: Segregated Witness: a Bitcoin upgrade that separates authorization data from the transaction identifier and introduces versioned witness programs.
Signature malleability: The possibility that related signature representations can authorize the same message unless a scheme and its rules enforce a canonical form.
Witness: Signatures, scripts, or other data supplied to satisfy a Bitcoin output’s spending condition.
Sighash: The exact transaction digest and signature mode that determine which fields a Bitcoin signature authorizes.

The Elliptic Curve Digital Signature Algorithm, called ECDSA, lets a private key authorize a message without revealing the key. Safe signing also depends on a unique secret nonce.

35 min Difficulty 1/5 Not started

VISUAL MODEL

See the whole mechanism before going step by step

Use the diagrams to orient yourself. Then the guided explanation below teaches every part in depth.

4 explanatory views

CONCEPT-SPECIFIC MAP · ecdsa signatureECDSA binds a signature to a message and public keySelect any state to inspect its exact role.

RELATIONSHIP MAPOrdered mechanism flow

01
MESSAGESighash z1
Bitcoin first constructs and hashes the transaction commitment selected by the sighash type.
02
NONCEDeterministic secret k
Nonce reuse or bias can reveal the private key, so production signing derives it safely.
03
SIGNr = x(kG), s = k^-1(z + rd)
The private scalar d contributes to s without appearing in the signature.
04
DER30 len 02 r 02 s
Legacy and SegWit v0 Bitcoin signatures encode r and s as strict DER integers plus a sighash byte.
05
VERIFYpasses for z1 and Q=dG
A valid signature authorizes the committed transaction data; it does not prove identity or ownership.

Rule shown: Verification checks the curve equation using the message digest, public key, and signature pair; changing any one must fail.

STAGE 1 OF 5MESSAGE: Sighash z1

Bitcoin first constructs and hashes the transaction commitment selected by the sighash type.

Governing relationship: Verification checks the curve equation using the message digest, public key, and signature pair; changing any one must fail. Complete path: 1. MESSAGE, Sighash z1. Bitcoin first constructs and hashes the transaction commitment selected by the sighash type. 2. NONCE, Deterministic secret k. Nonce reuse or bias can reveal the private key, so production signing derives it safely. 3. SIGN, r = x(kG), s = k^-1(z + rd). The private scalar d contributes to s without appearing in the signature. 4. DER, 30 len 02 r 02 s. Legacy and SegWit v0 Bitcoin signatures encode r and s as strict DER integers plus a sighash byte. 5. VERIFY, passes for z1 and Q=dG. A valid signature authorizes the committed transaction data; it does not prove identity or ownership.

1. State transitionWhat exists, what changes, and what results

BEFORE

A signer uses the same nonce k for two different message digests z1 and z2, producing signatures with the same r and values s1 and s2.

MECHANISM

Bitcoin's signature-hash rules serialize selected transaction data into a digest. The signature authorizes that digest, not an informal payment description.

AFTER

Nonce uniqueness and secrecy are part of signature security, not an optional implementation detail.

Text equivalent: Starting from A signer uses the same nonce k for two different message digests z1 and z2, producing signatures with the same r and values s1 and s2. The mechanism begins when Bitcoin's signature-hash rules serialize selected transaction data into a digest. The signature authorizes that digest, not an informal payment description. The resulting lesson is Nonce uniqueness and secrecy are part of signature security, not an optional implementation detail.

2. Mechanism pathSelect a stage to inspect its job

STAGE 1 OF 6

Compute the transaction message

Bitcoin's signature-hash rules serialize selected transaction data into a digest. The signature authorizes that digest, not an informal payment description.

Complete path: 1. Compute the transaction message: Bitcoin's signature-hash rules serialize selected transaction data into a digest. The signature authorizes that digest, not an informal payment description. 2. Choose a nonce: The signer derives a unique unpredictable nonce k. Deterministic nonce generation can avoid dependence on fresh external randomness when implemented correctly. 3. Create r and s: ECDSA combines the nonce point, message digest, and private scalar into two signature values commonly encoded using DER in Bitcoin scripts. 4. Verify the complete equation: A verifier computes w=s^-1 mod n, u1=zw mod n, u2=rw mod n, and X=u1G+u2P. The signature is mathematically valid only when X is not infinity and X.x mod n equals r. 5. Parse strict DER: Bitcoin script signatures serialize positive r and s integers inside a DER sequence. A mathematically valid pair can still fail an applicable strict-encoding rule. 6. Separate low-s contexts: High-s ECDSA is nonstandard under relay policy. For legacy script it is not universally a consensus failure, while SegWit version 0 consensus requires low-s. The applicable spending context decides the rule layer.

3. Rule and failure boundaryWhat accepts the result and where it can stop

ACCEPTED PATH

Real secp256k1 verification, strict DER serialization, and low-s form are inspected separately under legacy-script consensus, SegWit v0 consensus, and relay policy.

CHANGED CONDITION

A changed digest rejects authorization; a high-s counterpart remains mathematically valid but is accepted only in the explicitly modeled legacy consensus context.

Important distinction: A signature proves the signer approved every possible interpretation of a transaction. It authorizes the exact digest selected by serialization and sighash rules. Software must show the user what those committed fields mean.

Text equivalent: The accepted path is enforced by Real secp256k1 verification, strict DER serialization, and low-s form are inspected separately under legacy-script consensus, SegWit v0 consensus, and relay policy. If the required condition changes, A changed digest rejects authorization; a high-s counterpart remains mathematically valid but is accepted only in the explicitly modeled legacy consensus context.

Loading lesson visuals...

Learn the idea

ECDSA is the Elliptic Curve Digital Signature Algorithm used by traditional Bitcoin signature checks. A signature proves that a private-key holder authorized a specific message digest. ECDSA signing also needs a secret per-signature nonce, and exposing or reusing that nonce can reveal the private key. Signature malleability means more than one encoding or scalar form can represent related valid authorization. DER, the Distinguished Encoding Rules, is the strict byte format Bitcoin uses for ECDSA's two integers. Low-s normalization chooses the smaller equivalent s scalar. Consensus decides block validity, relay policy is a node's local admission rule, and SegWit (Segregated Witness) version 0 applies its own signature rules.

GUIDED EXPLANATION1/6 ideas inspected

Compute the transaction message

Bitcoin's signature-hash rules serialize selected transaction data into a digest. The signature authorizes that digest, not an informal payment description.

The worked example follows the explanation

Inspect every idea above to open it.

Important distinction“A signature proves the signer approved every possible interpretation of a transaction.”

It authorizes the exact digest selected by serialization and sighash rules. Software must show the user what those committed fields mean.

FINISH LEARNING FIRST

The questions unlock after every required learning activity

Inspect every guided idea, open the worked example, rebuild its mechanism, and complete the deterministic lesson tool. Your progress is saved automatically.