A vocabulary before a transaction
A glossary is easier to use when each term has its own example. Put address, transaction, signature and confirmation on separate lines rather than treating them as interchangeable labels. In Bitcoin, an address is a destination identifier, while a transaction describes a transfer recorded under the network rules. Other systems may use these words differently.
Try a reading card with four fields: the term, the system being described, the explanation in your own words and a question for later. If a paragraph moves between a wallet interface, an exchange account and a network record, mark that change. It is often the missing piece in a confusing explanation.
What a public ledger records
A blockchain is a sequence of blocks containing records; the Bitcoin developer glossary offers a starting point for its particular terminology. That description alone does not explain every system called a blockchain. Look for the rules that decide which entries are accepted and for the actors who can propose or verify them.
When taking notes, separate what a record says from what a website claims about it. A displayed balance, a transaction reference and a service account are different pieces of information. Write down where each came from and what you have not checked. A clear record of uncertainty is more useful than a confident guess.
Keys, copies and everyday caution
Public-key cryptography uses related public and private keys. As NIST explains, the private member of that pair is kept secret. The role of a key depends on the system and operation being described. A wallet, an exchange login and a recovery phrase are not simply three names for the same thing.
This notebook is not a storage or recovery service. Do not put passwords, private keys or recovery phrases into a reading log or send them here. Keep fictional examples visibly labelled, and avoid copying live account details into a screenshot just to illustrate a term. Questions about a particular product belong with its authenticated documentation.
Questions to take into further reading
Choose one narrow question before opening another explanation. Does the author mean the software interface, a company account or the underlying network? Which terms are defined, and which are assumed? Collecting those questions can make a second reading more productive without turning the session into a decision to buy or transfer anything.
Keep a short source list beside your notes: page title, system, date consulted and the specific question it helped with. If two descriptions disagree, retain both until the difference is understood. Familiar visual design, copied logos and confident prose cannot by themselves establish who controls a website or whether its claims are accurate.
