Capstone
Blockchain & Web3 Fundamentals
Course 1 · Chapter 10 · Capstone: Tracing a Real Transaction End to End
Nine chapters built up every real piece of the picture separately: the trust problem, hashing and signatures, blocks and Merkle trees, consensus, Bitcoin's own UTXO mechanics, Ethereum's genuinely different account model, wallets and keys, tokens and NFTs, and scaling. This capstone puts all of it together, tracing one single, complete payment — Alice sending Bob 0.5 BTC — from the moment Alice decides to pay through final, deeply-confirmed settlement, applying every prior chapter's own real mechanism in the order it actually happens.
The Scenario
Alice owes Bob 0.5 BTC for some freelance work. They've never met, don't share a bank, and don't want to involve one. Alice's wallet currently holds a single UTXO worth 0.62 BTC.
1
Why no bank is needed at all
Alice and Bob are exactly the two mutually distrusting strangers Chapter 1 opened with.
Without blockchain, they'd need a trusted third party — a bank, a payment processor
— to prevent Alice from double-spending the same 0.5 BTC elsewhere. Bitcoin's whole
design exists so they don't need one.
Chapter 1
2
Alice's wallet holds the key, not the coin
Alice's 0.62 BTC UTXO is really just a ledger entry on the chain itself, locked to her own
public key. Her wallet, deterministically derived from a single backed-up seed phrase, is
what lets her produce a valid signature for it whenever she chooses to spend it.
Chapter 7
3
Building and signing the transaction
The wallet constructs a transaction consuming the whole 0.62 BTC UTXO as its input, and
creates two outputs: 0.5 BTC to Bob's address, and 0.1199 BTC "change" back to Alice
(with 0.0001 BTC left over as the miner's fee). Alice's wallet then signs the transaction
with her private key, using ECDSA over the secp256k1 curve.
Chapter 5 · Chapter 2
4
Broadcast and independent verification
The signed transaction propagates across the network. Every node that receives it
independently checks the signature against Alice's public key before relaying it further
— nobody needs to trust the node that told them about it; they can verify it
themselves.
Chapter 2
5
Included in a block, hashed into a Merkle tree
A miner picks up Alice's transaction, along with thousands of others, and includes it in a
candidate block. Every transaction in that block is hashed into a Merkle tree; the single
resulting Merkle root gets stored in the block's own header, letting anyone later prove
Alice's transaction is really in this block using only a short handful of sibling hashes.
Chapter 3
6
Mining: finding a valid nonce
The miner repeatedly hashes the candidate block's header with SHA-256, trying different
nonce values, until the result falls below the network's current difficulty target
— a target recalibrated every 2016 blocks to keep the real average block time near
10 minutes regardless of total network mining power.
Chapter 4
7
Confirmation deepens over time
The block is broadcast and accepted by the network. As more blocks are mined on top of it,
Alice's payment to Bob becomes progressively harder to reverse — an attacker would
need to out-mine the entire honest network's own accumulated proof-of-work since that block,
an economically extreme proposition per Chapter 4's own real cost estimates.
Chapter 3 · Chapter 4
8
Bob now owns a new, independent UTXO
Bob's own real balance is simply whatever total his wallet finds by scanning the chain for
UTXOs locked to his public key — and it now includes a fresh 0.5 BTC UTXO from Alice.
No bank updated a number anywhere; the ledger itself is the update.
Chapter 5
9
What if Alice and Bob paid each other constantly?
If this were one of many frequent, small payments between the same two people, broadcasting
every single one to the base chain would be unnecessarily slow and costly at real network
scale. They could instead open a Lightning Network payment channel, transact instantly and
privately off-chain as many times as they like, and only settle the final balance to the
base chain once, when they eventually close the channel.
Chapter 9
Meanwhile, on Ethereum: the Same Payment, a Genuinely Different Mechanism
If Alice instead wanted to pay Bob using an ERC-20 token on Ethereum rather than bitcoin itself, several real, structural pieces of this story would change:
- There's no UTXO to consume at all. Alice's balance is simply a number tracked inside the token's own smart contract state, associated with her Externally Owned Account (Chapter 6).
-
Sending the payment means calling the token contract's own standardized
transferfunction (Chapter 8's own ERC-20 interface), which directly decreases Alice's tracked balance and increases Bob's, rather than creating and consuming discrete output objects. - Alice still signs the transaction with her own private key (Chapter 2 applies identically here — ECDSA/secp256k1 signing isn't Bitcoin-specific), and still pays a fee — gas, in Ethereum's case — for the computation the network performs on her behalf.
- If Bob were instead receiving a unique collectible rather than an interchangeable currency amount, the same account-based transfer mechanism would apply, but it would update an NFT's own recorded owner address (Chapter 8's ERC-721) rather than a balance number.
The Real Takeaway
Bitcoin and Ethereum solve the exact same underlying problem — letting two people who
don't trust each other exchange value without a bank — using two genuinely different
accounting models (UTXOs vs. accounts). Neither is simply "the same thing with different names";
this course has deliberately built up both, chapter by chapter, precisely so the real
differences are visible rather than assumed away.
Chapter-by-Chapter Attribution
| Chapter | What It Contributed to This Capstone |
|---|---|
| 1 | Why Alice and Bob need no trusted third party at all |
| 2 | SHA-256 hashing; ECDSA signing and independent verification |
| 3 | The block header, the Merkle tree, and the chaining that deepens confirmation over time |
| 4 | Mining, difficulty adjustment, and why deeper confirmations are harder to reverse |
| 5 | Consuming Alice's UTXO, creating Bob's new one and Alice's change |
| 6 | The account-based alternative underlying the Ethereum comparison |
| 7 | What Alice's wallet actually stores and does |
| 8 | ERC-20 and ERC-721 as the Ethereum-side equivalents of this same payment |
| 9 | Why a Lightning Network channel would suit frequent, repeated payments better |
What This Course Doesn't Cover
This capstone deliberately stops at the conceptual level. It doesn't write or deploy a single
line of Solidity, doesn't touch decentralized finance mechanics (lending, liquidity pools,
automated market makers), doesn't cover smart contract security vulnerabilities or real,
documented exploits, and doesn't address the genuinely important regulatory and custody
questions around holding and using crypto assets in practice. All of that is deliberately
reserved for Course 2, Smart Contracts, DeFi & Web3 Security, which builds
directly on everything established here.
Hands-On Exercises
Three closing exercises applying the full nine-chapter toolkit to fresh scenarios, before moving on to Course 2.
Exercise 1
Rewrite this chapter's own Alice-to-Bob scenario for a payment of exactly 0.62 BTC (Alice's
entire UTXO, with no change left over except the fee). Which specific output from Step 3 of
the flow disappears, and why?
Exercise 2
A colleague asks: "If Alice and Bob's payment is confirmed after Step 7, why would anyone ever
wait for more than one confirmation?" Using this chapter's own reasoning (and Chapter 4's own
51%-attack cost economics), write an accurate answer.
Exercise 3
Using this chapter's own Ethereum comparison, explain specifically what would need to happen
differently if Bob's payment were 0.5 BTC worth of a fungible ERC-20 token instead of native
ETH — is there still a "consuming a UTXO" step anywhere in that version of the story?
Quick Reference — Course Complete
- Chapters 1–10 — the trust problem, hashing and signatures, blocks and Merkle trees, consensus (PoW/PoS), Bitcoin's UTXO model, Ethereum's account model and smart contracts, wallets and keys, tokens and NFTs, scaling and Layer 2, and this capstone tying every piece together.
- Course complete — Blockchain & Web3 Fundamentals is now finished, 10/10 chapters.
- Next — Course 2, Smart Contracts, DeFi & Web3 Security, builds directly on this course: writing real Solidity, understanding gas and the EVM in depth, DeFi mechanics, common vulnerabilities, real documented exploits, and the genuine risks and regulatory questions around Web3 in practice.