Wallets addresses and keys

EN source master · P01-L03 · 30 minutes estimated · needs_review

Read-only study. No wallet connection, real money, seed phrase, private key, signature or live trade. Duration is an editorial estimate; visual assets are specifications, not deployed components.

Confusing a wallet application with the authority behind an account makes both investigation and security decisions unreliable. A read-only task should not become a request for signing material.

Three different objects

A wallet interface displays and helps manage accounts. An address identifies a network-scoped object. A private key can authorize actions for a key-controlled account. Ethereum also has contract-controlled accounts [ACCT]. One screen may display several accounts, and several interfaces may display the same account. Counting screens therefore does not count independent authorities.

An address is public information used for locating state, not a password. Public does not mean privacy-free: sharing an address can connect a conversation with a visible history. This lesson uses invalid labels so no student's actual account needs to be disclosed.

Keys are authority, not identity papers

A valid signature can establish authorization under a specified cryptographic or contract rule. It does not reveal the signer's legal name, how the key was obtained or whether the action was informed. Do not request a test signature to settle an identity claim in this course. Treat mechanism and person as separate questions.

For a shared account, several people might access one secret. For a multisignature policy, several signing keys need not represent independent humans. A public display cannot resolve these possibilities. Describe the observed policy or supplied role and leave unsupported human attribution open.

Recovery material is a different layer

Some deterministic wallets derive many keys from seed material. BIP-39 defines one mnemonic-to-seed scheme [BIP39]; it is not a rule covering every wallet product. A recovery phrase is not merely a password for the current application. Do not enter one into a lesson, support form, screenshot or practice tool.

Replacing an interface does not by itself change the authority that controls an account. Likewise, a watch-only view can show balances without being able to authorize spending. The interface's visible features and the underlying permission need separate inspection.

Draw typed relationships

Use arrows labelled ‘displays’, ‘identifies’ and ‘authorizes’. Do not use a single vague ‘owns’ line. A diagram should make it possible to answer which observation is public, which component is secret and which authority relationship is only stipulated. If the exercise has no human evidence, say so even when a name would make the story easier to tell.

Evidence-state classification

OBSERVED in the fixture: which views display X/Y and the stated placeholder authority. INFERRED: two displayed accounts, not three independent authorities. UNKNOWN: actual human controllers. INSUFFICIENT EVIDENCE: one key or multiple interfaces establishes one human owner.

• Wallet interface: viewing/interaction software.
• Address: public network-scoped identifier.
• Private key: secret authorization material.
• Watch-only: observation without local signing authority.
• Mnemonic: a word sequence used by some recovery schemes to derive seed material; it is confidential recovery material.

ILLUSTRATIVE. VIEW-A and VIEW-B both display ACCOUNT-X on SIM-NET. VIEW-C is watch-only for ACCOUNT-Y. SECRET-PLACEHOLDER authorizes ACCOUNT-X in the model; it is a label, not a key. No human controller is supplied.

Wallet graph with VIEW-A/B display arrows to ACCOUNT-X, VIEW-C to ACCOUNT-Y, and separate secret-authority edge to X. Alt: two interfaces share one fictional account; watch-only observation grants no signing authority.

The model separates two views of one account from authority.

A person's identity, independent signers or actual access to any wallet.

• Counting applications as wallets with independent secrets.
• Treating public visibility as permission.
• Requesting recovery material to verify a balance.

Draw the three kinds of edges. Can VIEW-C spend? Does installing VIEW-B create a new ACCOUNT-X? What evidence would be required to identify a human?

Submit a short evidence table and reasoning, using only the provided material. Suggested allocation: study 12 min, inspection/calculation 8 min, correction/quiz 10 min.

• Name interface versus account.
• Mark authorization separately.
• Keep secrets out of evidence.
• Leave human identity unsupported unless independently established.

Confusing a wallet application with the authority behind an account makes both investigation and security decisions unreliable. A read-only task should not become a request for signing material. The supplied material supports the model separates two views of one account from authority. It does not establish a person's identity, independent signers or actual access to any wallet.

• Separate interface, address and authorization.
• Explain why public observation needs no secret.
• Distinguish key control from human identity.

P01-L04 after reviewing this exercise and its prerequisites.

NONE. The authoritative catalog requires no product access for this lesson. Use the frozen/offline material.

• [ACCT] Ethereum accounts — Accounts and signing authority, separate from wallet interfaces and human identity. Checked 2026-10-01.
• [BIP39] BIP-39 — Mnemonic-to-seed construction; not every wallet uses this scheme. Checked 2026-10-01.

Synthetic values are author-created exercise inputs. Historical values, if any, must use the linked dataset and its narrower provenance. Source inspection is not independent editorial acceptance.