A public key is the shareable half of a cryptographic key pair. It is calculated from your private key, and it lets anyone check that a transaction was signed by whoever holds that private key. In Bitcoin and Ethereum you usually don't hand out the public key itself. You hand out an address, which is a shortened, hashed and encoded form of the public key. Deriving the public key from the private key is easy. Going back from a public key to the private key is not feasible, so you can share the public key and address freely but must never share the private key.
Public key, private key and address
| Item | What it is | Share it? |
|---|---|---|
| Private key | 256 bits of random data (on Ethereum, written as 64 hex characters) | Never |
| Public key | Calculated from the private key on an elliptic curve | Safe to share |
| Address | Usually a hash of the public key, encoded with a checksum | Safe to share; this is what you give people to pay you |
The original version of this article said a public key "is" the address of 26 to 34 characters. That is the address, not the key. The difference matters when you read wallet software or documentation.
How a key pair is created
Bitcoin
Bitcoin's developer documentation describes secp256k1 private keys as "256 bits of random data." A copy of that data is "deterministically transformed into an secp256k1 public key." Because the same private key always gives the same public key, a wallet doesn't need to store the public key. It can recompute it whenever needed.
Bitcoin signs transactions with the Elliptic Curve Digital Signature Algorithm (ECDSA) on the secp256k1 curve. A signature proves that the signer controls the private key without revealing it.
A compressed Bitcoin public key is 33 bytes: a prefix byte that says whether the y-coordinate is even or odd, followed by the 32-byte x-coordinate.
Ethereum
Ethereum's documentation says the public key "is generated from the private key using the Elliptic Curve Digital Signature Algorithm." It also says: "It is possible to derive new public keys from your private key, but you cannot derive a private key from public keys."
From public key to address
Bitcoin legacy addresses (start with 1)
- Hash the public key with SHA-256, then hash the result with RIPEMD-160. This gives a 160-bit (20-byte) hash.
- Add a version byte (0x00 on mainnet).
- Add a 4-byte checksum, made by running SHA-256 twice over the version byte and the hash.
- Encode the result in Base58.
Base58 leaves out the characters 0, O, I and l. The original Bitcoin client source explains why: "Don't want 0OIl characters that look the same in some fonts." Mainnet addresses made this way are 25 to 34 characters long, and most are 33 or 34.
Pay-to-script-hash addresses (start with 3)
Addresses that start with 3 use version byte 0x05 and commit to the hash of a script, not of a single key. A common example is m-of-n multisig, where "m is the minimum number of signatures which must match a public key." In a 2-of-3 setup, any two of three keys can spend. The old article called this a "multi-signature public key." In fact it is a script that can hold several public keys.
SegWit and Taproot addresses (start with bc1)
BIP 173 (assigned 20 March 2017) defined Bech32 for native SegWit addresses. They use the human-readable part "bc" on mainnet and "tb" on testnet. The data part leaves out "1", "b", "i" and "o".
Taproot (BIP 341) changes one detail: "The public key is directly included in the output" as a 32-byte key in the BIP 340 format, not as a hash. Taproot addresses use Bech32m (BIP 350) and start with bc1p on mainnet. Taproot signatures are 64-byte Schnorr signatures defined in BIP 340.
Ethereum addresses
An Ethereum address is the last 20 bytes of the Keccak-256 hash of the public key, with 0x added in front.
What are you about to share, and is it safe?
Pick what you are about to paste or send to see what it is and whether you can share it.
What are you about to share or paste?
- An address someone can pay (starts with 1, 3, bc1 or 0x) → next question
- A raw public key → Safe to share, but rarely needed
- An extended public key (xpub) → Treat it as private financial data
- A private key or seed phrase → Never share it
What does the address start with?
Never type, photograph or paste a private key or seed phrase into a website, chat or support form. A private key is 256 bits of random data, and whoever holds it controls the funds.
An extended public key cannot spend funds by itself, but anyone who has it can see the wallet's whole transaction history. A parent xpub plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key.
A public key is calculated from your private key and lets anyone check your signatures; going back to the private key is not feasible. To receive funds, give people your address instead.
A hash of one public key (SHA-256, then RIPEMD-160) with version byte 0x00 and a 4-byte checksum, encoded in Base58. Mainnet addresses are 25 to 34 characters. Check the first and last characters before sending.
It uses version byte 0x05 and commits to the hash of a script, not a single key, such as a 2-of-3 multisig where any two of three keys can spend. Check that the receiving software supports this type.
A Bech32 address defined in BIP 173, with the human-readable part "bc" on mainnet. Its checksum catches typos but not a wrong address that is still valid.
A Bech32m address (BIP 350). Unlike the other Bitcoin types, the 32-byte public key is included directly in the output rather than as a hash. Check that the receiving software supports bc1p addresses.
The last 20 bytes of the Keccak-256 hash of the public key, with 0x added in front. Check the first and last characters before sending.
This sorts common Bitcoin and Ethereum formats by their first characters only: it cannot verify that an address is valid, belongs to the right person or is supported by your wallet, and it is not security advice.
Where public-key cryptography came from
Whitfield Diffie and Martin Hellman proposed public-key cryptography in "New Directions in Cryptography," published in IEEE Transactions on Information Theory, vol. IT-22, no. 6, November 1976, pp. 644–654. The paper also proposed a digital equivalent of a written signature. In 2016 the ACM gave them the A. M. Turing Award for inventing public-key cryptography.
Cryptocurrencies mainly use the signature side of this idea. Bitcoin transactions are signed, not encrypted. The old article said public keys are used "to encrypt messages" and transactions, which is wrong for Bitcoin.
Extended public keys (xpub): useful and risky
Hierarchical deterministic wallets (BIP 32) can share an extended public key. It lets software create new receiving addresses without access to private keys. BIP 32 gives two examples: a webshop server can generate fresh addresses "without giving the webserver access to the corresponding private keys," and an auditor can "see all transactions from and to the wallet."
Two cautions follow from the specification:
- Privacy: anyone with your extended public key can see the wallet's whole transaction history.
- Security: a parent extended public key "plus any non-hardened private key descending from it" is "equivalent to knowing the parent extended private key." This is why wallets use hardened derivation at the account level.
Practical checklist
- Give people your address to receive funds. You rarely need to share a raw public key.
- Never type, photograph or paste your private key or seed phrase into a website, chat or support form.
- Check the first and last characters of an address before sending. The checksum catches typos but not a wrong address that is still valid.
- Treat an xpub as private financial data, even though it cannot spend funds by itself.
- Check that the address type matches what the receiving software supports (1…, 3…, bc1q…, bc1p…, or 0x… on Ethereum).
What about quantum computers?
NIST describes quantum computers as "machines that may be years or decades away but could eventually break many of today's widely used cryptographic systems." In August 2024 it published its first post-quantum standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA). This matters for public keys because elliptic-curve schemes such as ECDSA are among the systems at risk. Neither Bitcoin nor Ethereum has adopted these standards, according to the sources cited here.
Limitations: this is a technical explainer based on protocol documentation and standards, not security or investment advice; wallet software varies, so check your wallet's own documentation.
