In the world of blockchain and cryptography, a single number can open the door to profound insights. This journey begins with one such number—27—and leads deep into the heart of ECDSA (Elliptic Curve Digital Signature Algorithm), the cryptographic backbone behind FISCO BCOS, Bitcoin, and Ethereum.
We’ll explore how a seemingly arbitrary constant ties into broader concepts like elliptic curve cryptography (ECC), signature recovery, and transaction security, while uncovering the elegant design choices that make modern blockchains efficient and secure.
The Mysterious Number 27
It all starts in the Ethereum Yellow Paper, where two magic numbers—27 and 28—appear in the context of transaction signatures. At first glance, they seem arbitrary. But dig deeper, and you'll find that these values are derived by adding 27 to 0 or 1. So why 27?
This odd constant sparked speculation: was it a bug? A quirk? Or part of a deliberate cryptographic design?
A quick search reveals discussions on Stack Exchange and GitHub issues labeled as type:bug. One code snippet shows a function fromRpcSig that adds 27 to low v values (like 0–3) to convert them into valid recovery identifiers. This suggests that 27 is used to distinguish raw ECDSA output from Ethereum’s extended signature format.
But is this really a bug?
👉 Discover how blockchain systems turn cryptographic quirks into powerful features.
Not a Bug—But a Design Choice
Looking deeper into Ethereum’s EIP-155, we uncover the role of ChainID—a mechanism introduced to prevent replay attacks across different networks. While NetworkID isolates nodes at the peer-to-peer level, ChainID operates at the transaction level, ensuring a transaction on one chain (e.g., Ethereum) can’t be reused on another (e.g., Ethereum Classic).
Now recall the line from Ethereum’s source code:
v = chainId ? recovery + (chainId * 2 + 35) : recovery + 27Here, 27 and 35 emerge as structural constants. When no ChainID is used, v = recovery + 27. With ChainID, it shifts to recovery + 35 + chainId * 2.
So where do 27 and 35 come from?
The trail leads back to Bitcoin.
In Bitcoin’s SignCompact function (and in Electrum’s wallet implementation), the recovery ID (recid), which normally ranges from 0 to 3, is offset by 27. If the public key is compressed, an additional 4 is added—resulting in values from 27 to 34.
Thus, Ethereum inherited this convention from Bitcoin. But why did Bitcoin choose 27? The historical reason remains unclear—possibly a placeholder or identifier to distinguish compact signatures from standard ones.
ECDSA: More Than Just Signing
While the origin of 27 is now demystified, it opens the door to a more fundamental question: What is the recovery ID?
To answer this, we must dive into ECDSA itself.
What Is ECDSA?
ECDSA (Elliptic Curve Digital Signature Algorithm) is a public-key digital signature scheme based on elliptic curve cryptography (ECC). It offers strong security with smaller key sizes compared to RSA or DSA, making it ideal for resource-constrained environments like blockchains.
Common elliptic curves include:
- secp256k1 (used by Bitcoin and Ethereum)
- secp256r1
- Curve25519
The security of ECDSA relies on the elliptic curve discrete logarithm problem (ECDLP)—a mathematical challenge considered computationally infeasible with current technology.
Core Components of ECDSA
1. Key Generation (GenKey)
- Choose an elliptic curve and base point $ G $ of order $ n $
- Pick a random private key $ d \in [1, n-1] $
- Compute public key $ Q = d \cdot G $
2. Signing (Sign)
- Hash message $ m $ → $ z = \text{hash}(m) $
- Generate random $ k $, compute point $ (x, y) = k \cdot G $
- $ r = x \mod n $ (if $ r = 0 $, pick new $ k $)
- $ s = k^{-1}(z + r \cdot d) \mod n $ (if $ s = 0 $, pick new $ k $)
- Signature is $ (r, s) $
3. Verification (Verify)
Using public key $ Q $, verify:
- $ u_1 = z \cdot s^{-1} \mod n $
- $ u_2 = r \cdot s^{-1} \mod n $
- Compute $ (x, y) = u_1 \cdot G + u_2 \cdot Q $
- Check if $ r \equiv x \mod n $
4. Recovery (Recover)
Given only message $ m $ and signature $ (r, s) $, recover possible public keys.
This is where recovery ID (recid) becomes crucial.
Why Recovery Matters in Blockchain
In traditional systems using Verify, the verifier must already know the signer’s public key. But in blockchain, including FISCO BCOS and Ethereum, transactions don’t carry public keys—they carry only signatures.
So how do nodes know who sent a transaction?
Answer: Public key recovery.
From the signature $ (r, s) $ and message $ m $, nodes run the Recover algorithm to derive possible public keys. But here’s the catch: multiple candidates exist because:
- $ r = x \mod n $, so possible x-values include $ r, r+n $
- Each x corresponds to two y-values (positive/negative)
For secp256k1, this gives up to four possible points for $ R = k \cdot G $. Hence, four potential public keys.
To avoid brute-forcing all options, ECDSA includes a recovery ID (v) in the signature—telling nodes exactly which combination to use.
This tiny value enables fast recovery—turning what could be a slow trial-and-error process into a direct computation.
👉 See how advanced crypto algorithms power real-world blockchain performance.
Calculating the Recovery ID
The recovery ID isn't random—it's calculated during signing:
id = y & 1 # bit 0: y-coordinate parity
id |= (x != r ? 2 : 0) # bit 1: whether x was adjusted by n
if s > n / 2:
id ^= 1 # flip parity if s was normalizedLet’s break it down:
- Bit 0: Indicates if the y-coordinate of $ kG $ is odd/even
- Bit 1: Flags whether $ x > n $, so we use $ x - n $
- Final adjustment: If $ s > n/2 $, we negate it; hence flip bit 0
This clever encoding allows full reconstruction of the correct public key—without bloating transaction data.
FAQ: Common Questions About ECDSA and Recovery
Q: Why don’t blockchains just include public keys in transactions?
Including public keys would increase transaction size by ~65 bytes per transaction—hurting scalability. Recovery saves bandwidth and storage while maintaining security.
Q: Is public key recovery less secure than direct verification?
No—it’s equally secure. The recovered key must still match the expected address. There's no compromise in cryptographic strength.
Q: Can recovery fail?
Yes—if the signature is invalid or tampered with. In such cases, none of the four candidate keys will produce a valid address match.
Q: Why is secp256k1 used so widely?
It offers strong security with predictable performance. Though some argue other curves may be safer, secp256k1 benefits from extensive real-world testing in Bitcoin and Ethereum.
Q: What happens if two valid recovery IDs produce the same address?
Extremely unlikely due to hash uniqueness. Even if possible, both would correspond to equivalent private keys under modular arithmetic.
Q: How does ChainID prevent replay attacks?
By binding transactions to a specific chain via v = recid + chainId * 2 + 35, signatures become invalid on other chains—even if NetworkID matches.
The Philosophy Behind Efficient Design
FISCO BCOS leverages ECDSA recovery not just for efficiency—but for elegance. By allowing nodes to reconstruct identities from signatures alone, it reduces data overhead and aligns with decentralized principles: trust through computation, not transmission.
This design reflects a deeper philosophy: optimize not just for speed, but for minimalism, verifiability, and resilience.
Final Thoughts: From Doubt to Clarity
What began as curiosity about a magic number—27—led us through layers of cryptographic design, historical precedent, and mathematical insight. We uncovered how ECDSA’s recovery mechanism transforms a potential performance bottleneck into a scalable solution.
As developers building on blockchain platforms like FISCO BCOS, understanding these low-level details empowers us to write better code, optimize performance (as seen in Java SDK improvements), and appreciate the ingenuity behind every transaction.
Blockchain development demands rigor—a willingness to question every byte and trace every dependency. But for those willing to dig deep?
👉 Unlock the future of decentralized innovation today.
There’s clarity on the other side.