Introduction to Blockchain Addresses
In the world of decentralized finance and distributed ledgers, an "address" is the public identifier used to receive funds. While we often see them as long strings of alphanumeric characters, these strings are the result of sophisticated encoding schemes designed for human readability, error detection, and space efficiency.
Understanding these encoding schemes—such as Base58, Bech32, and EIP-55—is crucial for developers, security researchers, and power users. This guide provides a deep dive into the technical standards that define how blockchain addresses are constructed and validated.
1. Base58 and Base58Check: The Bitcoin Legacy
Bitcoin's original address format (Legacy addresses starting with 1 or 3) uses Base58 encoding.
Why Base58?
Standard Base64 encoding includes characters that can be easily confused by humans, such as 0 (zero) and O (capital o), or I (capital i) and l (lower-case L). Base58 was specifically designed by Satoshi Nakamoto to eliminate these ambiguous characters.
Base58 Alphabet:
123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz
Base58Check: Adding Error Detection
To prevent users from accidentally sending funds to a mistyped address, Bitcoin uses Base58Check. This adds a 4-byte checksum to the payload before encoding.
The Base58Check Process:
- Version Byte: A prefix is added to indicate the address type (e.g.,
0x00for P2PKH,0x05for P2SH). - Payload: The actual hash of the public key (RIPEMD-160).
- Checksum Calculation:
SHA256(SHA256(Version + Payload))is calculated. The first 4 bytes of the result are the checksum. - Concatenation:
Version + Payload + Checksum. - Base58 Encode: The entire concatenated byte array is converted to a Base58 string.
If a single character is changed, the checksum validation will fail, protecting the user from typos.
2. Bech32 and Bech32m: SegWit and Beyond
As Bitcoin evolved with SegWit (Segregated Witness), a new address format was needed. Bech32 (defined in BIP 173) became the standard for Native SegWit addresses (starting with bc1q).
The Advantages of Bech32
- Case-Insensitive: Bech32 strings are all lowercase (though they can be uppercase, mixing is forbidden). This makes them easier to type and read aloud.
- QR Code Efficiency: Because it uses only lowercase letters and numbers, Bech32 is more efficient in QR codes.
- Better Error Detection: Bech32 uses a BCH code that can detect up to 4 errors and potentially correct them.
- No Base58 Ambiguity: It uses a character set that excludes confusing characters.
Bech32 Alphabet:
qpzry9x8gf2tvdw0s3jn54khce6mua7l (Note the exclusion of 1, b, i, o).
Bech32m: Fixing the "1" character issue
In 2021, Bech32m (BIP 350) was introduced to fix a minor vulnerability in the original Bech32 when used with Taproot (v1 witness programs) and higher. Bech32m is now the standard for Taproot addresses (starting with bc1p).
3. Ethereum Address Formats and EIP-55 Checksums
Unlike Bitcoin, Ethereum addresses are derived directly from the last 20 bytes of the Keccak-256 hash of the public key. They are typically represented as a hexadecimal string starting with 0x.
The Lack of a Built-in Checksum
Originally, Ethereum addresses had no built-in checksum. If you mistyped a character in a standard 0x address, the funds would simply be sent to an invalid or unreachable destination.
EIP-55: Mixed-Case Checksum
To solve this without changing the address length, Vitalik Buterin proposed EIP-55. It uses capitalization to encode a checksum.
EIP-55 Algorithm:
- Lowercase the address (excluding
0x). - Calculate the Keccak-256 hash of the lowercased address string.
- For each character $i$ in the address:
- If the $i$-th nibble of the hash is $\ge 8$, uppercase the $i$-th character of the address.
- Otherwise, keep it lowercase.
Example:
- Standard:
0x5aaeb6053f3e94c9b9a09f33669435e7ef1beaed - EIP-55:
0x5aAeb6053F3E94C9b9A09f33669435E7Ef1BeAed
A Bitcoin address validator or Ethereum address validator must implement these specific algorithms to ensure the integrity of the transaction destination.
4. Summary Table: Address Encoding Comparison
| Feature | Base58Check | Bech32 / Bech32m | EIP-55 (Ethereum) |
|---|---|---|---|
| Blockchain | Bitcoin (Legacy) | Bitcoin (SegWit/Taproot) | Ethereum |
| Prefix | 1 or 3 |
bc1q or bc1p |
0x |
| Character Set | 58 characters (Alphanumeric) | 32 characters (Lowercase + Num) | 16 characters (Hex) |
| Checksum Type | Double SHA-256 (4 bytes) | BCH Code | Keccak-256 (Mixed-case) |
| Case Sensitive | Yes | No (Case-insensitive) | Optional (Recommended) |
FAQ: Common Blockchain Encoding Questions
Q: Why do some Bitcoin addresses start with 1 and others with 3?
A: Addresses starting with 1 are P2PKH (Pay-to-Public-Key-Hash) addresses. Those starting with 3 are P2SH (Pay-to-Script-Hash) addresses, often used for Multi-sig or nested SegWit.
Q: Can I send BTC to an Ethereum address?
A: No. The encoding schemes and underlying cryptographic curves may overlap, but the network protocols are entirely different. Sending assets to an address on a different chain usually results in permanent loss.
Q: What is a "Vanity Address"?
A: A vanity address is a blockchain address that contains a specific word or pattern (e.g., starting with 1Love...). These are generated by brute-forcing millions of key pairs until a matching public hash is found.
Q: How do I fix an "Invalid Address" error?
A: This error usually means the checksum validation failed. Double-check for typos, ensure you aren't mixing up 0 and O, and verify that you are sending to the correct network (e.g., don't send SegWit BTC to a Legacy-only wallet).
Conclusion
Blockchain address encoding is more than just a string of characters; it is a vital security layer. Whether it's the typo-resistance of Base58Check, the efficiency of Bech32, or the clever mixed-case checksum of EIP-55, these standards ensure that billions of dollars can be moved across the globe with confidence. As a developer or user, mastering these formats is the first step toward understanding the technical architecture of the decentralized web.