Module 3 of 4

Using Bitcoin Safely

3.1Evaluate Bitcoin Wallets

Activity TypeDiscussion
ParticipationIndividualWhole class
Description

Participants examine prepared, locally relevant Bitcoin and Lightning wallet information, recording when sources were checked. They compare options using custody, recovery, payment compatibility, privacy, cost, maintenance, support, and open-source inspectability, then explain which option may fit a stated fictional or learner need without presenting a global recommendation.

Objectives
  • Participants practice comparing Bitcoin wallet options against consistent criteria and weighing the trade-offs for a stated need.
Materials
  • Prepared wallet information in print or digital form.
  • Internet access, if checking current local information.

Procedure

Step 1

Review the prepared Bitcoin and Lightning information resources and identify when each source was last checked.

Step 2

Research or compare wallet options using custody, recovery, payment compatibility, privacy, cost, maintenance, safe support, and whether the software is open source and publicly inspectable.

Step 3

Choose a wallet for a fictional or stated beginner need and explain the trade-offs. Prefer a well-established open-source option where appropriate, but do not treat open source as proof of safety or suitability and do not name one wallet as best for everyone.

Discussion Questions

Which wallet best fits the stated need, what trade-offs remain, and what would need to be verified before real use?

Notes

Compare tools; do not recommend or activate one

Use prepared information and fictional needs. Do not ask learners to choose a real service, use personal funds, or disclose private information. A local example is not a global My First Bitcoin recommendation.

Bitcoin Diploma assessment link: May provide the individual-response context for T3 / C4. Use the approved protocol; do not ask a learner to choose a real service, use personal funds, or disclose private information. The educator should help participants navigate the decision path without turning a local example into a My First Bitcoin recommendation.

Additional Resources

3.2Creating Your First Bitcoin Wallet

Activity TypeExperiential learning
ParticipationIndividualWhole class
Description

The educator guides participants through a prepared wallet demonstration or simulation so they can explore how wallet setup, receiving information, and recovery readiness work. Participants follow the clues, compare public and private information, and make safe choices in realistic-looking examples. This is a learning demonstration, not personal wallet setup: no real secrets or funds are used.

Objectives
  • Participants explore wallet setup, receiving information, and recovery readiness through a guided, no-value demonstration.
Materials
  • An educator-guided, nonfunctional wallet simulation, printed screen sequence, or educator-controlled empty test-wallet demonstration
  • Public/secret sorting cards and recovery-readiness sequence cards using placeholders such as WORD 01 through WORD 12
  • Sample receiving information and status screens marked SAMPLE: NONFUNCTIONAL. DO NOT PAY.
  • Official instructions for the exact training environment, if a device demonstration is used

Preparation Notes

Phones are optional. If a device is unavailable, use the paper simulation or educator demonstration.

Setup

Choose a nonfunctional simulation or printed sequence as the default route. An educator-controlled empty test-wallet demonstration may be used after its source, version, network, custody model, and reset method have been checked. Participants explore the prepared route without creating, restoring, signing with, funding, or receiving bitcoin through it.

Keep it a learning demonstration

A test or training wallet is for exploring an interface or process; it contains no real bitcoin and is not a participant's future wallet. Any wallet intended to receive real funds needs private, deliberate setup and a protected recovery plan outside this activity. Keep recovery phrases, private keys, passwords, personal wallets, and funds out of this demonstration.

Procedure

Step 1: Meet the training wallet

Introduce the prepared wallet as a training example. Explain that the class will explore how the screens work, not set up personal wallets. Invite participants to notice which information can be shared and which information must stay private.

Step 2: Open the approved training route

Open the educator-approved simulation, printed sequence, or empty test-wallet demonstration. Ask participants to find the new-wallet, receive, and recovery options. Different wallets use different labels, so explore what this example calls each action.

Step 3: Inspect the prepared wallet interface

Inspect the prepared interface. Participants point out the receiving information, then sort the prepared cards into “may be shared” and “keep private.” Use placeholders for recovery information; participants do not create a wallet or handle a secret.

Step 4: Rehearse recovery readiness without a secret

Give pairs the numbered placeholder cards and ask them to put the backup-and-recovery steps in order. Debrief: what must stay private, why does word order matter, and what would be a good next step if a real recovery phrase were exposed?

Step 5: Identify the safe recovery path

Use the prepared scenario cards to identify the wallet's stated recovery method, the compatibility checks a person would make, and the point at which they should pause and seek help. The educator observes the participant's explanation and safe decisions, not a secret or a completed recovery.

Step 6: Check prepared receiving information

Show the prepared receiving information and status screen. Participants check the labelled network, destination, amount, unit, and status, then play “spot the mismatch” with a deliberately changed example. The class explains why pausing is the best next step. All examples are nonfunctional; no payment is made.

Step 7: Close the temporary environment

Close the simulation or return the paper materials. Invite participants to name one thing they can share and one thing they would keep private. If an educator-controlled test-wallet demonstration was used, the educator follows the pre-checked reset process.

Key Points

Public receiving information and private spending information have different roles. A test wallet is a learning environment; a wallet intended to receive real funds needs private, deliberate setup outside the classroom.

Notes

Bitcoin Diploma assessment link: May support T3 / C4, P6a / C6, and P6b / C6 when the educator observes safe recovery-readiness decisions using prepared placeholder materials. Record the participant's demonstrated decision or explanation, never wallet secrets or personal financial information.

Public addresses can be shared to receive bitcoin; private information should not be shared.

3.3Transactions in action

Activity TypeExperiential learning
Duration30 min
ParticipationWhole class
Description

Participants use real Bitcoin wallets to create a fresh on-chain receiving address, check the payment details, approve a small real payment, and check its status. The educator connects the observed wallet steps to the distinct roles of a sender, recipient, node, and miner. Learners do not try to create invalid transactions or expose wallet information in order to learn why those transactions are rejected.

Objectives
  • Participants use real Bitcoin wallets and a low-stakes on-chain payment to practise verifying a destination, amount, network, fee, and payment result.
  • Participants distinguish wallet authorization, recipient verification, node validation, and a miner's candidate-block role while observing an actual transaction.
Materials
  • An educator-checked on-chain Bitcoin wallet and connection for each participating sender and receiver.
  • A small amount of real bitcoin that the educator has approved for the activity, including enough for the expected network fee.
  • A planned payment order and final return destination.
  • A whiteboard or projected screen for the educator's general role explanation. Do not display learner wallet details.

Setup

Before class, test the exact wallet, source, network, amount, expected fee, payment destination, and receipt path. State who provides the funds, the planned payment order, the final return destination, the expected result, and when to stop. Do not screen-share or collect a learner's wallet details.

Procedure

Step 1: Create and check receiving information

The receiver creates a fresh on-chain receiving address for the educator-approved amount. The sender checks the destination, amount, unit, network, expected fee, and final summary before approving. Stop if anything is unclear or does not match.

Step 2: Authorize and broadcast the transaction

The sender approves the transaction on their own device. Explain that the wallet signs under the sender's authority and broadcasts the transaction; the recipient does not approve it for the Bitcoin network. The learner's approval screen is not evidence that all network checks have already occurred.

Step 3: Check the payment status

The receiver checks the result on their own device. Explain the difference between broadcast, pending, and confirmed status. Do not ask either learner to show a seed phrase, private key, password, balance, transaction history, or other unnecessary personal information.

Step 4: Connect the live transaction to Bitcoin roles

Explain that nodes independently validate transactions and blocks against Bitcoin's rules. Miners may choose valid transactions for candidate blocks and attempt proof of work; nodes decide whether to accept the resulting block. The live payment can show a wallet approval and payment status, but it does not expose every signature, input, or network check.

Step 5: Return funds and debrief

Where the planned route permits, return the funds to the educator's final destination. Discuss the actual fee, status, relevant privacy considerations, and why a successful low-stakes payment does not make a learner ready to hold or use significant funds. If the payment fails, pause to understand the message; do not retry by guessing.

Key Points

  1. A sender authorizes a transaction with a signature. A recipient can provide a destination and check for a payment, but recipient approval is not a consensus rule.
  2. Nodes independently validate transactions and blocks against Bitcoin's rules.
  3. Miners build candidate blocks from transactions and try to find proof of work. They do not set the validation rules.
  4. A confirmation means that a transaction appears in a block that a node accepts. Confirmation and finality involve risk and context, not an absolute promise that nothing can change.
  5. A carefully supervised low-stakes real payment can make verification concrete, but it is not a test of readiness to hold or use significant funds.

Discussion Questions

  • Which role authorizes the transaction?
  • Which role checks the stated transaction rules?
  • Which parts of the live payment are visible to the sender and receiver, and which happen elsewhere in the network?
  • Why does Bitcoin use cryptography to sign transactions?

Notes

Use real wallets and funds only for this learning activity

Before beginning, follow the Educator Guide's live-practice guidance. Explain the route and risks in advance; use an amount whose loss is not significant; make participation voluntary; protect all secrets and unnecessary payment information; and define stop conditions. Use educator-prepared funds where possible. Do not pressure learners to use their own funds or recommend a wallet or service.

Bitcoin Diploma assessment link: May provide the individual-response context for T2 / C2 and direct practical learning where an approved route calls for it. Use the approved protocol and record only the individual evidence needed for the relevant criteria; otherwise, this activity is formative. It is not an assessment route for significant funds.

Invite learners to explain the checks they made before approval and the difference between wallet authorization, recipient verification, node validation, and mining.

Tip: Rotate learners through sending and receiving roles where the planned funds and available time allow.

Video

Book

Additional Resources

3.4Exploring the mempool

Activity TypeExperiential learning
Duration30 min
ParticipationWhole classSmall groupsPairs
Description

Participants examine an educator-prepared public block, transaction, or screenshot. They identify confirmation status, inputs, outputs, fee information, and block information without using personal financial data. A live explorer can support the activity, but the printed route is equivalent and should be the default when connectivity, devices, or privacy are a concern.

Objectives
  • Participants distinguish a node's mempool from a block explorer and interpret basic, deliberately public block or transaction information.
Materials
  • A printed screenshot or worksheet for one deliberately public block or transaction.
  • A board or paper for recording observations.
  • Optional: a shared, educator-operated block explorer that has been checked immediately before class.

Setup

Choose one public example with no connection to learners. Label the example's source, date, and network. If a live explorer is used, prepare the same screenshot or worksheet as the no-internet route.

Explain that each node has its own mempool, which is the set of unconfirmed transactions that node has received and accepted under its current policy. A block explorer is a separate service that makes some network data easier to view. Neither an explorer nor its display is the Bitcoin network itself.

Procedure

Step 1: Identify the example

Give participants the prepared example. Ask them to find the transaction or block identifier, confirmation status, time shown, and any fee information. Ask what information the page does not prove about the people behind the transaction.

Step 2: Trace a transaction carefully

Ask participants to identify inputs and outputs. Explain that an input spends a prior output and that an output specifies conditions for later spending. Do not describe an address history as a person's complete financial history.

Step 3: Read a block summary

Use the prepared block example to identify its height, transaction count, and displayed fee information. Explain that Bitcoin limits block weight to 4,000,000 weight units. Do not treat a visual display or a simple megabyte label as a complete explanation of that limit.

Step 4: Compare mempool and explorer

Ask learners to sort these statements into “node mempool,” “block explorer,” or “both”: receives unconfirmed transactions, has a chosen display interface, may differ from another node, and can be used to view a prepared public example. Discuss why different nodes may not have exactly the same unconfirmed-transaction set.

Step 5: Discuss verification and privacy

Ask when an explorer is useful, what privacy trade-off a public query can create, and what a person would need to do to check Bitcoin's rules more independently. Keep the answer proportionate: a beginner can learn from a public example without being expected to run software or use a personal wallet.

Key Points

  1. A mempool is maintained by an individual node. There is no single universal mempool.
  2. A block explorer is a third-party viewing tool, not the Bitcoin network or a substitute for independent validation.
  3. Public ledger information can reveal links and patterns. Use only educator-prepared public examples in class.
  4. Live interfaces, fees, and displayed network data change. Check them immediately before use.

Discussion Questions

  1. What is the difference between a node's mempool and a block explorer?
  2. What did the prepared example show, and what could it not tell us?
  3. Why might two nodes have different unconfirmed-transaction sets?
  4. What privacy risks can arise when someone searches an address or transaction?

Notes

Use prepared public examples only

Do not search a learner's or another person's address, transaction, balance, or payment history on a public explorer. Public searches can expose financial information and reveal interest in that data to the explorer operator.

Bitcoin Diploma assessment link: May provide the individual-response context for T3 / C5, especially on-chain confirmation and verification. Use the approved protocol and record individual evidence; otherwise, this activity is formative.

Additional Resources

3.5Watch: Future of Bitcoin: Lightning Network

Activity TypeDiscussion
Description

Participants watch “Future of Bitcoin: Lightning Network” on the Hard Money show as an introduction to Lightning’s role in Bitcoin payments. After viewing, the educator can invite participants to identify the claims, questions, or examples in the video that relate to the course discussion of payment networks.

Objectives
  • Participants identify an idea from the video about the Lightning Network’s role in Bitcoin payments.
Materials
  • Internet access and video playback.

Procedure

Step 1

Open the video.

Step 2

Watch the video.

Step 3

Additional Resources

3.6Lightning payment relay

Activity TypeExperiential learning
Duration30–45 min
ParticipationWhole classSmall groups
Description

Participants create fresh Lightning invoices, receive a small real payment, and relay the funds to the next participant. Before every payment, they check the invoice, amount, unit, destination, expiry, and status. The activity supports a discussion of routing, fees, and payment failure through the actual payment experience.

Objectives
  • Participants use real Lightning wallets and a low-stakes real payment to practise the information checks involved in a Lightning payment relay.
Materials
  • An educator-checked Lightning wallet and connection for each participating sender and receiver.
  • A small amount of real bitcoin that the educator has approved for the activity, including enough for any expected fees.
  • A planned relay order and a final return destination.
  • A paper tracking sheet and pencils for learning observations, not wallet or personal financial information.

Setup

Test the exact wallet, network, invoice process, amount, and receipt path before class. State who provides the funds, whether any fee applies, the relay order, the intended final destination, the expected result, and when to stop. Do not screen-share or collect a learner's wallet details.

Procedure

Step 1: Create and check the first Lightning invoice

The first receiver creates a fresh Lightning invoice for the educator-approved amount. The sender checks the destination, amount, unit, expiry, and network before approving. If any required detail is unclear or mismatched, stop.

Step 2: Send and confirm receipt

The sender approves the payment on their own device. The receiver checks the result on their own device. Neither learner needs to show a seed phrase, private key, password, full balance, or payment history. Record only the learning observation needed for the activity.

Step 3: Relay the real payment

The receiver becomes the next sender. Continue until every planned participant has received and sent the educator-approved amount. The final participant returns the funds to the planned destination. If a payment fails, pause to understand the message; do not retry by guessing or changing details without understanding why.

Step 4: Debrief the live payment

Discuss the actual result, any fee, the information checked before approval, the limits of what the wallet display shows, and why a successful small payment does not make a wallet suitable for significant funds. Compare a Lightning payment path with an on-chain confirmation without claiming that one is always better.

Key Points

  1. A payment request needs careful checks before action, including destination, amount, unit, network, and status.
  2. Lightning payments can fail for reasons such as an expired request or an unavailable route. A failure is a reason to pause and understand the message, not to guess.
  3. A carefully supervised low-stakes live payment can teach checks and trade-offs. It does not make a learner ready to use a wallet with significant funds.

Discussion Questions

  1. Which details did your group check before approving the payment?
  2. What did the actual payment result show, and what did it not show?
  3. What should someone do when a payment request is unclear or fails?
  4. Which questions would need local, current information before a future real payment is considered?

Notes

Use real wallets and funds only for this learning activity

Before beginning, follow the Educator Guide's live-practice guidance: make the route and risks clear, use an amount whose loss is not significant, make participation voluntary, protect every secret and unnecessary payment detail, and define stop conditions. Use educator-prepared funds where possible. Do not pressure learners to use their own funds or turn this into a recommendation of a wallet or service.

Bitcoin Diploma assessment link: This activity is formative unless the educator has selected an approved practical route. It may support discussion of payment-path trade-offs for T3 / C5, and it may support directly observed practical learning, only when the educator uses the approved protocol and records an individual explanation or performance. It is not an assessment route for significant funds.

Additional Resources

↑ Back to table of contents