Module 3: Using Bitcoin Safely

Module 3 moves from explanation into safe beginner performance. It does not make every learner ready for high-value self-custody. It helps learners distinguish public information from secrets, compare custody choices, practise recovery readiness, verify payment details, recognize unsafe conditions, and demonstrate required actions under approved support conditions.

Guiding question:

How do I take responsibility for using and securing Bitcoin?

Learner promise:

I can explain beginner custody and safety concepts and demonstrate the required actions safely under supported conditions.

If this is your first time teaching Module 3: Practise the complete safe process yourself before class. Use an empty training wallet, printed screens, or a simulation. Never learn a new wallet or recovery procedure at the same time as learners, and never ask learners to show real secrets. Slow, visible checking is more important than completing a live transaction.

The Bitcoin Diploma is for learning and practice. It may involve creating a wallet, handling prepared recovery words, or completing a simulated receive or recovery path. In a class, however, a screen, device, recovery phrase, or wallet detail can be accidentally seen, copied, shared, or compromised. Training wallets are the default; they are not personal wallets for securing meaningful funds.

Use this distinction consistently:

• A training wallet is normally empty, simulated, or in a test environment. It is used to learn a process, is clearly labelled, and is not used to secure meaningful funds. Do not let its recovery information later protect meaningful funds.
• A personal wallet is created for a learner who independently chooses to receive or hold meaningful funds after the Bitcoin Diploma. It needs a new wallet, new recovery information, a private setup, and more careful attention to privacy and security.

Plan to retire training wallets by the end of the Bitcoin Diploma wherever practical: clear or reset the temporary device, return shared equipment, and destroy or securely return prepared recovery materials. Never retain material that could later give access to a learner's funds.

An educator may select a low-stakes live activity when it is appropriate for the local context and the learners. Before it begins, explain the difference from a training wallet: real funds can be lost, a live wallet and transaction history can reveal personal information, and recovery information needs stronger private handling. Explain the specific route, amount, and stop conditions; make participation voluntary; and offer a no-funds equivalent that preserves the learning outcome.

An educator may choose to offer optional support to a learner who wants to create a personal wallet for use after the Bitcoin Diploma. Keep this separate from class practice and certification: it must be voluntary, must not be required to pass, and must begin with a new wallet and new recovery information. Give the learner private control of their device and secret information. Do not watch, collect, copy, photograph, message, store, or retain a personal recovery phrase, private key, password, balance, or wallet history. Pause or refer the learner to appropriate local support if private setup cannot be maintained or the educator cannot safely explain the process.

Record one result for each assessed competency. Decimal C IDs are competency criteria and rubric look-fors, not separate pass/fail rows.

Use guided discussions to develop and notice the formative competency F1 through clear explanation, relevant evidence, respectful listening, and basic reasoning. F1 is not a certification gate.

This module needs more individual observation than Modules 1 and 2. A two-hour session may introduce and practise the content, but it may not provide enough time to assess every learner reliably.

Before class, estimate:

• the number of individual tasks requiring observation
• the realistic time per learner
• device-sharing delays
• accessibility and language support
• the number of educators or assessors; and
• time for feedback and reassessment.

Use smaller stations, another educator, or additional sessions when helpful. Group practice is valuable, but give each learner an individual opportunity to show the competency. A follow-up appointment or class is acceptable when a learner needs more time.

• Read the Module 3 Student Guide and practise every demonstration.
• Select the exact prepared wallet, simulation, test environment, or printed sequence.
• Verify the tool's source, version, network, custody model, recovery process, and reset process.
• Decide whether learners will use a simulation, test environment, empty training wallet, physical model, or an educator-approved low-stakes live setting. For any live setting, prepare the risk explanation, voluntary-choice process, and no-funds equivalent.
• Prepare sample on-chain addresses, Lightning invoices, *txid*s, QR codes, and screenshots marked SAMPLE — DO NOT PAY.
• Prepare public/secret sorting cards.
• Prepare a deliberately public address or historical transaction for the address-history activity. Never use learner-linked data.
• Prepare a fake seed phrase or disposable empty training wallet for recovery practice.
• Prepare scam and clipboard-replacement scenarios.
• Review the Activity Library for suitable practice ideas, adapting any wallet or payment activity to the safety and assessment conditions here.
• Prepare an acquisition-pathway comparison relevant to the location without naming a preferred provider.
• Define the helpful steps, support, safety boundaries, reset method, and any optional notes for each activity used for assessment.
• Arrange a private space where learner screens and evidence cannot be observed unnecessarily.
• Ensure every live task has a printed or no-funds equivalent.

When possible, use two learning parts and a separate assessment window.

Part A: custody foundations

Part B: verification and safety

Schedule formal observation only after supported practice.

Use the sentence:

A Bitcoin wallet manages keys and transaction information. It does not store bitcoin inside the phone or device.

Show the separation among:

• the shared Bitcoin ledger
• the wallet's keys and signing function
• the wallet's interface and network connection; and
• any external service the wallet depends on.

Ask:

• If the phone breaks, what still exists?
• What makes access recoverable or unrecoverable?
• Does an application called a “wallet” always give the user control of the keys?

When comparing wallets, use consistent criteria:

• custody
• verified source and open-source status
• recovery and compatibility
• privacy and server dependence
• supported payment types
• continuity and maintenance
• cost and device fit; and
• available safe support.

Prefer well-established open-source wallet software where it fits the learner's needs because publicly inspectable code can improve transparency. Treat that preference as one part of a contextual judgment, not a rule or guarantee. Every wallet has trade-offs, and open source does not prove that a tool is safe, maintained, correctly installed, or suitable for a learner. Help learners identify whether the code is publicly inspectable and compare that with custody, recovery, compatibility, privacy, cost, maintenance, and safe local support. Do not create a global approved-wallet list inside the course or present one wallet as the universal choice.

Teach an on-chain Bitcoin address as public receiving information generated from wallet keys. It is not a password, account login, or proof that the person requesting payment is trustworthy.

Teach these beginner habits:

• obtain the address from the intended receiving wallet
• confirm Bitcoin and the correct network
• distinguish an on-chain address from a Lightning invoice or address
• copy or scan rather than type manually
• compare after copying
• verify the full address on a trusted display for important payments
• use a fresh address for a new receipt when the wallet provides one; and
• use a small test when the amount or process is unfamiliar.

Do not tell learners that matching only the first and last characters is sufficient for every risk. It is a useful quick check, while full verification on a trusted display gives stronger assurance for important payments.

Activity: public or secret?

Prepare cards for:

• on-chain address
• address QR code
• Lightning invoice
• txid
• public key
• private key
• seed phrase
• wallet password or PIN
• balance screenshot; and
• security or recovery plan.

Learners sort them into:

• public receiving or ledger information
• secret spending or access information; and
• context-dependent information that may be public technically but private personally.

Debrief that “public on the protocol” does not mean “safe to associate with a person's identity.” A txid or address can reveal activity and relationships.

This activity makes public-ledger privacy visible.

Purpose: Show that address activity may be visible and that repeated address use can make transactions easier to link.

Materials: A deliberately public, educator-prepared address or transaction; a local-node interface, optional explorer, or dated printed screenshots; privacy questions.

Safety boundary: Never ask learners to search, display, or share an address or transaction belonging to them, a classmate, a private individual, or an unconsenting organization. Searching an address through a third-party explorer can itself reveal interest in that address.

Facilitation:

1. State why the example is safe and public.
2. Ask learners what they expect an observer can see.
3. Identify transactions, amounts, timing, or reuse visible in the prepared example.
4. Ask whether the address appears to have received more than once.
5. Discuss what an observer can infer and what they cannot know with certainty.
6. Show that many wallets generate a fresh receiving address.
7. Explain that old addresses may remain valid, but fresh addresses improve privacy by reducing easy linkage.

Debrief:

• Does an address reveal a legal identity by itself?
• How could combining public data with other information change the answer?
• Does using a fresh address make Bitcoin private in every respect?
• Why should an educator avoid searching a learner's address on a public website?

Offline fallback: Use a printed sequence showing one address used once and another reused across several receipts.

Keep the practical rule central:

Public receiving information may be shared. Private spending information must remain secret.

Teach:

• a private key authorizes spending through a digital signature
• a public key supports verification without revealing the private key
• modern wallets manage many keys automatically; and
• beginners should not copy or handle raw private-key strings.

Do not use “the private key proves who you are.” It proves authorization by the key, not a legal identity.

No legitimate educator, wallet company, exchange employee, developer, support worker, or public figure needs a learner's private key or seed phrase.

A seed phrase, also called a recovery phrase, is one recovery method used by many wallets. It is an ordered list of words that can recreate the keys for compatible wallet designs. It is not a universal feature of every wallet and is more powerful than an ordinary account password.

Teach the consequences:

• correct words in the correct order can restore control
• anyone who obtains the phrase may gain control
• losing it can remove the recovery path
• wallet compatibility matters; and
• a seed that may have been exposed should be treated as compromised.

Never do this in class

• Do not ask a learner to read recovery words aloud.
• Do not walk around while learners record real words.
• Do not let learners photograph, message, email, print, cloud-store, or submit a phrase.
• Do not use one learner's real funded wallet for a public recovery demonstration.
• Do not enter a hardware-wallet phrase into a website or ordinary computer form.
• Do not retain training phrases that later protect learner funds.

Activity: recovery-readiness simulation

Presentation: Show a complete recovery check using prepared recovery words or a disposable empty training wallet. The words may restore that empty training wallet, but must not protect a personal or funded wallet. Explain compatibility, privacy, expected result, and reset.

Practice: Learners sequence prepared cards or restore a disposable training wallet in a private, controlled environment. They must keep the material out of view and identify unsafe requests.

Production: The learner explains or demonstrates how to:

1. use official instructions for the exact wallet.
2. confirm recovery compatibility.
3. work privately without cameras or observers.
4. use the trusted backup-check or recovery method.
5. verify the expected receiving information or training history.
6. clear the temporary device; and
7. return the fictional material securely or destroy it as instructed.

Treat an exposed seed phrase as compromised

If a real seed may have been exposed, stop using it as a safe backup, create a new trusted wallet with new recovery information, and move funds after carefully verifying the destination. The learner should seek help without revealing either phrase.

Inheritance, multisignature design, advanced passphrases, and high-value recovery planning may require advanced security and professional legal advice. They are outside required Bitcoin Diploma performance.

Custody asks one question:

Who controls the keys required to spend the bitcoin?

Make the verification distinction explicit in plain language: Bitcoin's rules and total supply can be independently checked, but a learner who does not control the keys cannot independently check that an account balance corresponds to bitcoin the service holds and will make available to them. The public blockchain can show bitcoin controlled by keys; it cannot show that a service owes a particular customer the balance displayed in an account. Before withdrawal into self-custody, that balance is the service's promise to provide bitcoin, not bitcoin the learner can directly verify and spend. Do not suggest that an account balance proves a service's reserves or solvency.

Use guided scenarios rather than identity labels. A learner should compare:

• who can authorize a payment
• who can restrict access
• who handles recovery
• what happens if the service disappears
• what happens if the user loses recovery information
• which privacy or identity data are held; and
• when convenience creates counterparty dependence.

Do not treat self-custody as a moral test. A beginner may choose a small custodial balance while learning. The educational requirement is to recognize the trust model and risk.

Avoid a common category error:

• Custodial / self-custodial describes who controls the keys.
• Hot / cold describes whether signing keys are exposed to an internet-connected general-purpose environment.
• Hardware wallet describes a dedicated device design.
• On-chain / Lightning describes a payment path, not custody by itself.

A Lightning wallet can be custodial or self-custodial. A hardware wallet still needs a recovery process. A cold arrangement can be badly designed. A hot wallet can be appropriate for small everyday use.

Ask learners to select a tool for an invented purpose, then require them to state the benefit and new risk. Do not ask them to choose for their real holdings.

Receiving still requires verification even though it does not authorize funds to leave.

Demonstrate:

1. Open the intended wallet.
2. Select Receive.
3. Confirm on-chain versus Lightning and the intended network.
4. Display or copy only the payment request.
5. Confirm the amount and any relevant fee arrangement.
6. Verify the pending payment in the receiving wallet or trusted view.
7. Interpret confirmation or payment status appropriately.

Explain that a message or screenshot saying “sent” is not proof of receipt. The receiver should verify within their own wallet or trusted view.

Practice: receive-screen walkthrough

Use printed screens or a training wallet. Ask learners to:

• locate the receive function
• identify whether the request is on-chain or Lightning
• point to what can be shared
• explain what must remain secret
• check the amount if present; and
• state how receipt will be verified.

When using the activity for assessment, observe the learner individually enough to make a confident judgement.

Use a pause-and-check sequence:

1. Confirm recipient and purpose through a trusted channel.
2. Request fresh payment information when appropriate.
3. Confirm on-chain or Lightning and the correct network.
4. Scan or enter the destination.
5. Compare it with the trusted receiving display after entry.
6. Confirm the amount and unit.
7. Review the fee, timing, expiry, and final summary as relevant.
8. Use a small test when the process or amount is unfamiliar.
9. Approve only after all information matches.
10. Verify the result in the appropriate wallet or transaction view.

Teach learners to stop if the recipient changes the destination unexpectedly, discourages verification, creates urgency, or asks for recovery information.

Activity: clipboard substitution

Give learners an intended address card and a pasted-address screen with a mismatch. The correct outcome is to detect the mismatch and stop, not to complete the transaction.

Change the scenario:

• Only the middle differs.
• A support message says the change is normal.
• The recipient claims the payment is urgent.
• The QR code and written address disagree.

Ask what independent channel can verify the destination.

Explain that an on-chain fee is based mainly on transaction data and demand for block space, not simply the value sent. Wallet estimates can be inaccurate or become stale.

A transaction:

• is unconfirmed after broadcast and before inclusion in a valid block
• receives its first confirmation when included in a valid block; and
• gains more settlement confidence as additional valid blocks build on that history.

Confirmations do not repair an incorrect destination, reverse a scam, prove the recipient's identity, or make an unwanted purchase appropriate.

There is no one confirmation count suitable for every value and risk. Teach the reasoning rather than a universal number.

A block explorer is an interface to public Bitcoin information, not an authority over Bitcoin's rules.

Using a prepared txid, show:

• transaction status
• inputs and outputs at beginner depth
• amount and fee display
• block inclusion and confirmation count; and
• information that becomes public.

Then ask:

• What can the explorer show?
• What can it not prove about legal identity, purpose, honesty, or ownership?
• What information does the explorer operator learn from the search?
• How does a local node change the trust and privacy relationship?

Avoid live searches containing learner-linked data.

Teach patterns rather than a list of brands:

• impersonation of support, educator, friend, public figure, or official
• urgency and pressure
• guaranteed or unusually easy returns
• giveaways requiring payment first
• recovery offers requesting words, keys, remote access, or advance fees
• fake wallet applications and updates
• phishing domains, advertisements, or direct-message links
• relationship or romance manipulation
• address replacement; and
• requests for secrecy.

Use the default response:

Pause. Share nothing. Send nothing. Close the channel. Verify independently through a known source. Ask for help without revealing secrets.

Activity: scam stations

Place short invented scenarios around the room. At each station, learners record:

• the warning sign
• what information or money is at risk
• the immediate safe response
• an independent verification route; and
• when to seek help.

Include one legitimate-looking message with no obvious spelling error. Scams should not be taught as easy to spot only because they look unprofessional.

The learner should compare possible routes, not receive a recommendation.

Compare:

• earning bitcoin
• direct peer-to-peer exchange
• a centralized exchange or broker
• an ATM or kiosk
• receiving through a merchant, donation, refund, or remittance; and
• a service that converts between bitcoin and fiat.

For every route, ask:

• What total amount is received after price, spread, and fees?
• Who controls the bitcoin before and after the exchange?
• What identity data are collected?
• Can the fiat side be reversed?
• Can the bitcoin be withdrawn to self-custody?
• What counterparty and fraud risk exists?
• What physical-safety risk exists?
• Which local law, tax, or reporting rule may apply?

Use no-KYC consistently for a path collecting less or no standard identity information. Do not imply that no-KYC removes fraud, legal, counterparty, or physical risk. Do not advise evasion of local law.

Use a comparison that separates payment path from custody.

Lightning is not a separate coin. A successful Lightning payment does not prove the wallet is safe for a larger balance. Channel operation, routing infrastructure, and liquidity management are Advanced Learning outside the Bitcoin Diploma.

C6.1 is a competency criterion within C6. The learner gains access to bitcoin in an approved low-stakes or simulated environment, receives it or safely simulates receipt, and checks the relevant information as part of the observed wallet, payment, and verification performance.

Plan the route carefully:

1. State whether the environment is custodial, self-custodial, simulated, testnet, or real low-stakes.
2. Demonstrate the complete first-access process.
3. Explain any account, identity, recovery, network, or service dependency.
4. Have the learner open or access the prepared environment.
5. Have the learner locate and verify receive information.
6. Complete or simulate receipt.
7. Have the learner verify balance or payment status and explain what that evidence means.
8. Have the learner identify the recovery path and stop conditions.

Do not require learners to purchase bitcoin. A prepared training balance, educator-provided low-stakes receipt, test environment, or approved simulation may satisfy the competency when the assessment variant permits it.

Use stations after learners have seen each process.

Do not use the stations as formal assessment unless the exact tasks, variants, criteria, and records are approved.

For practical assessment, observe whether the learner can complete the relevant activity safely and can:

• open or safely access the prepared environment
• navigate without exposing unrelated information
• identify the custody model
• distinguish receiving information from secrets
• select the intended payment path and network
• locate and verify an address or invoice
• check recipient, amount, unit, fee, expiry, and final summary as relevant
• complete or safely simulate a receive or send flow
• interpret pending, confirmed, failed, or received status
• protect recovery information throughout a recovery-readiness task
• respond safely to exposure, mismatch, impersonation, urgency, or fraud
• explain the reason for important checks; and
• stop or seek help when the process exceeds their competence.

Safety-critical behavior cannot be averaged away. Revealing recovery information, approving a known mismatch, proceeding through an apparent scam, or bypassing a required verification results in Not yet until focused remediation and reassessment.

Use an integrated scenario. A learner or pair must:

1. identify the custody model of a prepared wallet.
2. locate receiving information.
3. distinguish on-chain from Lightning.
4. prepare a send and detect a changed destination.
5. read a prepared payment status.
6. respond to a fake support request; and
7. explain recovery readiness without revealing words.

Ask:

What does direct control require from the user, and which risks remain even after following a safe process?

Then use the Module 3 Student Guide closing question. Keep the response private or optional, following the light module-closing reflection guidance above.

Bridge:

Module 4 asks whether these tools and responsibilities solve a real need in this community. The answer may be yes, no, or only under particular conditions.