Progress pill
Bitcoin Transaction Inner Workings

Bitcoin Transaction Parsing and ECDSA Signatures

Programming Bitcoin

Bitcoin Transaction Parsing and ECDSA Signatures

  • Understanding ECDSA: Bitcoin's Digital Signature Foundation
  • Signature Commitments and the Signing Process
  • Transaction Structure and Inputs/Outputs
  • Fees, Change, and Malleability

Understanding ECDSA: Bitcoin's Digital Signature Foundation

Bitcoin relies on ECDSA, an elliptic curve–based signature scheme offering strong security with far smaller key sizes than RSA. Its security comes from the elliptic curve discrete logarithm problem: given P = eG, computing P is easy, but deriving e from P is computationally infeasible. This asymmetry enables public key cryptography while keeping private keys secure.

DER Encoding of ECDSA Signatures

Bitcoin encodes ECDSA signatures using the DER format:
  • 0x30 (sequence marker)
  • length byte
  • 0x02 + length + R bytes
  • 0x02 + length + S bytes
This adds overhead, expanding a 64‑byte signature to ~71–72 bytes. Taproot eliminates this inefficiency by adopting fixed‑size Schnorr signatures.

Signature Commitments and the Signing Process

ECDSA signatures rely on a commitment equation: UG + VP = KG. The signer selects non‑zero U and V values, and a random nonce K, proving knowledge of the private key without revealing it. The message is hashed into Z, a random K is generated, R is the x‑coordinate of KG, and S = (Z + RE)/K. The signature is the pair (R, S). Security critically depends on using a unique, unpredictable K—if K is reused or leaked, the private key is compromised. Modern implementations use deterministic K generation (RFC 6979) to avoid RNG failures.

Signature Verification

Given Z, (R, S), and public key P, the verifier computes U = Z/S and V = R/S, then checks whether the x‑coordinate of UG + VP equals R. This works because the verification algebra reconstructs KG without needing the private key. Forging signatures would require solving the discrete log problem or breaking the hash function.

Schnorr Signatures and Historical Context

Schnorr signatures are mathematically cleaner and support aggregation features, but were patented when Bitcoin launched. ECDSA offered a free alternative, though with more complexity and larger signatures. With the patents expired, Bitcoin added Schnorr signatures via Taproot, providing fixed 64‑byte signatures and improved privacy. ECDSA remains supported for legacy compatibility.

Transaction Structure and Inputs/Outputs

A Bitcoin transaction consists of:
  • version (4 bytes, little‑endian)
  • input list
  • output list
  • locktime (4 bytes)
Inputs reference previous UTXOs by their transaction hash and output index, and include an unlocking script (scriptSig) and a sequence number used for timelocks or RBF. Outputs specify the amount (8 bytes) and the locking script (scriptPubKey), defining spending conditions. Bitcoin addresses are representations of these scripts.

The UTXO Model

Bitcoin tracks unspent outputs rather than account balances. UTXOs must be spent entirely—partial spending is impossible. To spend 1 BTC from a 100 BTC UTXO, a transaction must include a change output. Forgetting the change output turns the remainder into a miner fee.

Transaction Serialization and Parsing

Transactions use a compact binary format. After the version field, a varint encodes the number of inputs. Inputs include:
  • previous tx hash (32 bytes)
  • output index (4 bytes)
  • scriptSig (varstr)
  • sequence (4 bytes)
Outputs include an 8‑byte amount and scriptPubKey (varstr). Locktime controls when the transaction becomes valid. Serialization uses little‑endian ordering for most integers. Parsers consume bytes sequentially and delegate to specialized classes for inputs, outputs, and scripts.

Fees, Change, and Malleability

Fees are implicit:
fee = sum(input values) – sum(output values).
Any unassigned value becomes the fee, making correct change output construction essential. Before SegWit, signatures allowed malleability—modifying S to N-S produced a new valid transaction with a different ID. Bitcoin now enforces a low‑S rule, and SegWit isolates signatures from the txid calculation, making IDs stable and enabling second‑layer protocols like Lightning.
Quiz
Quiz1/5
What is the primary consequence of forgetting to include a change output when spending a UTXO that contains more Bitcoin than needed?