Public Key vs Private Key in Crypto: Addresses, Wallets and Control

Public key vs private key: what each does

A private key is secret cryptographic information used by a signing process. A public key is mathematically related information that supports verification. The security design aims to make deriving the private key from the public key computationally infeasible with appropriate parameters and implementations.

For an ordinary key-controlled Ethereum account, the Ethereum accounts documentation describes the relationship among private keys, public keys and addresses. The secret signs the transaction; the network checks the resulting authorisation. The private key itself is not included as a transaction field for everyone to read.

A signature is also different from a private key. It is evidence produced for particular data. What that signature authorises depends on the message format and the receiving protocol. A request described as “just sign a message” deserves attention to the actual content and permissions.

For a conceptual exercise, imagine a document labelled Instruction A and a separate result labelled Signature A. Verification asks whether that signature matches the instruction and the appropriate key relationship. It does not ask the reader to reveal the secret. No live signing exercise is necessary to understand the distinction.

Separate an address from the public key

An address is an encoded identifier used by a network’s transaction or account system. Its construction depends on the network and address type. It may incorporate a public-key hash, a script-related commitment or other key-derived information. The phrase “public address” does not mean the address is the raw public key.

The same visible length or prefix is insufficient to establish every property of a destination. Network identity, supported address format and the intended asset still matter. Even where networks use similar address forms, their balances and transaction histories are separate records.

Ethereum’s ordinary key-controlled account addressing provides one example: its address is derived from the public key. Contract addresses have their own creation rules and do not imply that a matching private key sits inside the contract. Contract-wallet authorisation follows programmed conditions, often involving one or more signers.

Avoid a universal drawing with “one address equals one private key” underneath it. That can be a limited teaching model for a specified simple arrangement, but it does not describe every script, multisignature policy or contract wallet. The correct question is which conditions authorise the relevant operation.

The Ethereum introduction gives broader account and application context. Here the essential habit is to label a key, address, account and contract separately whenever they appear in the same explanation.

Understand what the wallet contains and displays

Blockchain records describe the relevant assets and spending conditions. A wallet helps the user view and interact with those records. It does not place physical coins into the application file. The Bitcoin wallet developer guide describes wallet functions and the distinction between key-management and network-facing roles.

A watch-only arrangement can track public information without possessing the private material needed to spend. A signing device can hold secrets while another application prepares requests and displays balances. A custodial account can show a balance while the provider controls the underlying signing arrangement.

These examples explain why a balance screenshot cannot prove control. The image may show a public record, a service’s internal ledger or an interface connected to a separate signer. Determining the arrangement requires more evidence than the fact that an amount appears on screen.

A wallet application can also show several networks or assets together. That display convenience does not turn their records into one shared blockchain balance. Keep network and asset labels attached when comparing screens, restoring a view or explaining why one account appears different from another.

For Bitcoin’s underlying transaction model, see the Bitcoin network and transaction guide. The present guide focuses on authorisation and representation rather than repeating the network introduction.

Why one backup can relate to many keys

Many wallets use deterministic key derivation: a defined starting point and derivation rules produce a hierarchy of keys. BIP32, the hierarchical deterministic wallet specification documents one widely used design. This helps explain how one wallet arrangement can contain many receiving addresses.

Different derivation paths can lead to different keys, and software must know which paths and address types to examine. The fact that an application displays fewer addresses than expected is therefore not evidence that the blockchain erased the others. A display and a derivation configuration are separate from the underlying records.

An extended public key can allow derivation of a family of non-hardened descendant public keys without supplying the corresponding private keys. This supports some watching and receiving workflows, but can expose a broader view of activity than a single address. “Public” should not be read as “contains no privacy-sensitive relationships.”

The specification also has important security conditions involving extended keys and leaked descendant private keys. An introductory research exercise has no reason to collect either. Use descriptive labels in notes rather than copying key material to make a diagram look more technical.

Not every wallet follows the same backup standard or derivation convention. A useful explanation names the design it covers and leaves unsupported restoration claims out.

Map one wallet to three invented addresses

Consider a simplified Bitcoin-style teaching wallet whose backup can derive three key pairs. Each key pair corresponds to one receiving address in this exercise: Address A, Address B and Address C. These names are placeholders and cannot be used to receive funds.

Address A is associated with two unspent outputs of 60,000 and 15,000 satoshis. Address B has one output of 25,000 satoshis. Address C has none. The watched quantity is 60,000 + 15,000 + 25,000 = 100,000 satoshis, assuming these are the only relevant outputs in the exercise.

The count of addresses is three. The count of positive-value unspent outputs is also three, but only by coincidence: two belong to A and one to B. The count of wallet applications is one. None of these counts establishes that there are three separate people.

Now imagine a second application watches only Address A. It can display 75,000 satoshis without receiving any private key. It has a narrower view of the same public records. The difference from 100,000 is explained by coverage, rather than by any movement of funds.

This example isolates two common mistakes: adding interface balances without checking overlap, and assuming a viewer controls everything it can display. Keep the derivation map, observed outputs and signing authority in separate parts of the note.

Keep recovery material distinct from app passwords

A recovery phrase is a backup representation used by some wallet designs to regenerate key material. BIP39 describes a mnemonic-to-seed process, including the role of an optional passphrase. The derived seed can then support a deterministic wallet design.

A recovery phrase, an optional recovery passphrase and an application password can therefore perform different jobs. An application password may protect local access or an encrypted file. It should not automatically be described as changing the underlying blockchain key or replacing the required recovery material.

Changing a local login password does not, by itself, make a disclosed blockchain private key cease to work. Likewise, reinstalling an interface does not erase records from the chain. These distinctions are conceptual boundaries, not a recovery procedure for a particular wallet.

Treat recovery material as control-sensitive. Do not photograph it for a support ticket, paste it into a block explorer or include it in an educational example. A request to “validate” a phrase in an unrelated form changes a reading task into disclosure of a secret.

If an actual recovery problem arises, the exact wallet design and official support documentation matter. This article intentionally provides no secret-entry exercise, sample phrase or live import instructions.

Read public evidence without expanding the task

For public transaction research, an appropriate public identifier and the named network are usually the relevant inputs. Learning what an address means does not require granting token allowances, approving a signature or connecting an account to an unfamiliar service.

Before sharing a screenshot, inspect what it reveals beyond the amount: account names, address relationships, browser details or other personal information. A public blockchain record can still become more identifying when someone attaches a name or a location to it.

A useful three-line research note says what is being observed, what that observation establishes and what remains unknown. For the worked example: “Address A shows 75,000 satoshis in two outputs. The viewer can read those records. Signing control and the identity of the controller are not established.”

The market-news verification guide applies the same evidence discipline to claims made about large wallets or named holders. Match the conclusion to the evidence rather than treating a visible balance as proof of identity, custody or intention.

Frequently asked questions

1. Is a public key the same as a wallet address?

They are distinct concepts. An address is an identifier constructed under the network’s addressing rules; a public key supports cryptographic verification. Some addresses use key-derived information, while other designs represent script or contract conditions. Identify the network and address type before describing the relationship.

2. Does a wallet store the coins themselves?

The blockchain carries the relevant asset records. A wallet provides ways to view and interact with them and may manage signing material. A watch-only application can display records without the ability to spend. The interface and the underlying ledger serve different roles.

3. Can someone spend using only an ordinary public address?

Knowing a public address alone does not satisfy the corresponding spending conditions. It can reveal activity and balances, so privacy still matters. Avoid upgrading that basic statement into a guarantee about every wallet implementation, signature request or contract authorisation arrangement.

4. Does sharing a public key have no consequences?

Public information can expose relationships among transactions and accounts. Extended public keys can reveal a wider derived set of addresses, and their security properties have additional caveats. Share only what the actual task requires; learning the terminology does not require sharing any real key.

5. Is a recovery phrase simply one private key written as words?

That description is too narrow for common deterministic wallets. A phrase can help derive a seed from which many keys are generated. Its exact meaning depends on the backup standard and any additional passphrase. Keep the entire recovery arrangement private.

6. Can changing an app password revoke a private key?

A local password may protect access to an application or file. Changing it does not inherently change the blockchain authorisation key. Distinguish the local security setting from the underlying signing material when reading a wallet’s documentation or assessing an access problem.

7. Why might two apps show different balances for the same wallet?

Their network selection, address coverage, derivation settings or refresh state may differ. In the invented example, a viewer watching only Address A shows 75,000 satoshis while the broader view shows 100,000. Compare scope before concluding that funds moved.

8. Does a transaction signature reveal the private key?

A properly implemented signature scheme is designed to prove authorisation without revealing the secret. That does not make every request to sign harmless. The signed content may authorise a consequential operation. Reading this guide or public chain records requires no signature.

9. Does every address correspond to one person?

No. One person or arrangement can use many addresses, and one address can operate under conditions involving multiple signers or an organisation. Address counts are address counts unless a separate, defensible method supports an estimate of people.

10. What should an educational wallet diagram contain?

Use plain labels for secrets, public keys, addresses and records, with the relevant network stated. Show what the example assumes. Avoid usable keys, seed words, destination strings or personal identifiers. A good diagram teaches relationships without creating an opportunity for accidental disclosure or transfer.