What is a public key?

A public key is the shareable part of an asymmetric cryptographic key pair. In the digital-signature systems used by many blockchains, a private key produces a signature and the corresponding public key lets other parties check that signature without learning the private key.

That definition is deliberately narrower than saying a public key “proves who someone is.” A successful signature check shows that the signature is valid for particular data under a particular key. Connecting that key to a person, organization or intended transaction requires information outside the signature algorithm. NIST’s Digital Signature Standard similarly separates signature generation with a private key from verification with the public key. NIST FIPS 186-5

From a private value to a verifiable key

The exact mathematics depends on the signature scheme. In an elliptic-curve system, a private key is a number within a permitted range and the public key is a curve point calculated from it and agreed domain parameters. SEC 1 describes this relationship as public key Q = dG, where d is the private key and G is the curve’s base point. It also specifies public-key validation because an arbitrary byte string is not automatically a valid curve point. SEC 1: Elliptic Curve Cryptography

This calculation is designed to be practical in the private-to-public direction while recovering the private value from a properly generated public key is computationally infeasible under the scheme’s assumptions. The assurance still depends on correct key generation, approved parameters, implementation and key handling; “public-key cryptography” is not by itself a guarantee that every wallet or device is implemented correctly.

Public keys can also have different encodings without representing different signing authority. For example, Bitcoin has compressed and uncompressed encodings for elliptic-curve public keys. The serialized bytes differ, and an address derived from those bytes may differ, even though both encodings describe the same curve point. Bitcoin Developer Guide: wallets

What signature verification establishes

A simplified signing flow has four parts:

1. Wallet software prepares the data that the network expects to be authorized.
2. A signing algorithm combines that data with the private key to produce a signature.
3. A verifier applies the matching verification algorithm to the signed data, signature and public key.
4. The network separately checks its other rules, such as transaction format, spend conditions, balances or nonces.

Changing the signed data normally causes the original signature to fail verification. But a valid signature alone does not say whether the action was beneficial, whether the interface showed the full instruction, or whether the key owner intended the real-world consequence. It is one input to network authorization, not a universal statement of identity or trust.

Public key, blockchain address and account

These terms describe different layers:

• Public key: cryptographic material used in verification or other public-key operations.
• Blockchain address: a network-specific identifier, often derived through hashing or encoding rules, or created from other deployment data.
• Account: a network-level record or authorization arrangement associated with an address.

For an Ethereum externally owned account (EOA), the address is the final 20 bytes of the Keccak-256 hash of the public key. Ethereum contract addresses are created under different rules and contract accounts do not have their own private keys. Ethereum also uses BLS keys for validators, which are distinct from the EOA key pair. These examples show why an Ethereum address cannot always be treated as a public key or even as evidence of a one-to-one key pair. Ethereum accounts

Bitcoin illustrates another variation: common address types encode information about a spending script or a hash commitment rather than presenting a raw public key as the address. The public key may only become visible when the relevant output is spent. Address construction and key exposure therefore depend on the network and output type, not on one rule shared by every blockchain.

Ordinary public keys and extended public keys

An ordinary public key represents one member of a key pair. A BIP-32 extended public key combines a public key with a chain code and derivation metadata. It can derive descendant public keys along non-hardened branches without the corresponding private keys. That feature can support receive-only or monitoring systems, but it also reveals a group of related public keys to whoever receives the extended public key. BIP-32: Hierarchical Deterministic Wallets

An extended public key cannot derive hardened children, and it should not be described as harmless merely because it cannot sign. BIP-32 also documents a stronger compromise condition: exposing an extended public key together with a corresponding non-hardened descendant private key can expose ancestor and sibling private keys within that branch. This is a property of that derivation scheme, not of every ordinary public key.

Where public keys do and do not provide privacy

Making an ordinary public key available does not reveal the private key under the assumed hardness of the cryptographic scheme. It may still have privacy consequences. Reusing a key or address, publishing an extended public key, or linking addresses through transaction activity can make otherwise separate activity easier to associate.

Public keys also do not normally hide blockchain transaction contents. Public-key cryptography includes encryption and key-agreement schemes, but a signing key’s role in transaction authorization is signature verification. Whether a network encrypts any data is a separate protocol question.

FAQ

Can two addresses use the same public key?

Possibly, depending on the network and address format. Different encodings or scripts can produce different address representations related to the same key. Applications should follow the rules of the specific network instead of assuming a universal one-address-per-key mapping.

Is a public key enough to spend crypto assets?

Normally no. A public key enables verification; authorizing a key-controlled spend requires a valid signature or satisfaction of the network’s applicable spending rules. Contract-controlled accounts and multisignature arrangements can apply rules that do not reduce to one public key.

Related concepts

For a longer comparison, read Private keys vs public keys.

Explore private keys, blockchain addresses, seed phrases and crypto wallets, or return to the Crypto Glossary.

Sources

• NIST FIPS 186-5: Digital Signature Standard — signature generation, verification and approved signature schemes.
• NIST SP 800-57 Part 1 Rev. 5 — public/private key types and key-management boundaries.
• SEC 1 Version 2.0 — elliptic-curve key-pair generation, public-key validation and signature operations.
• Ethereum: accounts — EOA keys, address derivation, contract accounts and validator keys.
• BIP-32 — ordinary, hardened and extended public-key derivation.
• Bitcoin Developer Guide: wallets — key encodings, address relationships and HD wallet behavior.