Course 4 took you from understanding the Lightning Network as an idea to running your own full node and Lightning node, and keeping the money in its channels safe. This review, Lesson 4.10, brings the nine lessons together, checks the ideas that matter most, and points you to Course 5: Advanced Bitcoin Security & Privacy.
Read the summary of each lesson below. If any part feels unclear, follow the link back to the full lesson. Then try the ten questions at the end: if you can answer them without looking, you have the essentials.
Course 4 Review
The course has two halves. Lessons 4.1 to 4.4 are about using Lightning: how it works, how payments find their way, which wallet to choose and how to pay. Lessons 4.5 to 4.9 are about running your own infrastructure: why a node matters, which platform to pick, how to set one up, how to run a Lightning node on it, and how to keep its channels safe.
Lesson 4.1 — Lightning Network Explained
Lightning is a second layer on top of Bitcoin. Bitcoin’s blocks hold only a few thousand transactions each (about 8 transactions per second worldwide in October 2026), so Lightning moves payments into channels: balances shared by two parties and backed by bitcoin locked in a 2-of-2 address on the blockchain. Opening a channel takes one on-chain transaction and closing it cooperatively one more; every payment in between is a new balance that both sides sign. Revocation keys punish anyone who publishes an old balance, provided their partner’s node or a watchtower notices before the cheater’s waiting period ends. A force close, when one side closes alone, costs more in fees and makes the closer wait for its share. Hash Time-Locked Contracts (HTLCs) let a payment cross several channels so that either every hop completes or none does. Review Lesson 4.1
Lesson 4.2 — Lightning Channels and Routing
A channel’s capacity is split between your local balance (what you can send) and the remote balance (roughly what you can receive), minus a reserve, money set aside for closing fees and any payments in flight. A channel you fund yourself can’t receive until there is inbound liquidity. Payments find a path through other people’s channels using onion routing: nodes in the middle of a route usually can’t tell the sender or the recipient, but every hop sees the amount it forwards, close to the full amount unless the payment is split across several routes. The exception is your wallet’s Lightning Service Provider (LSP), the company that opens its channels: it can see that a payment came from you, and with Phoenix, ACINQ also sees where it goes. You also met BOLT11 invoices, which name the node being paid, BOLT12 offers, and the difference between a payment that timed out (retry once it no longer shows as pending) and one stuck pending (wait). Review Lesson 4.2
Lesson 4.3 — Lightning Wallets Compared
Four questions separate Lightning wallets: who holds the keys, where the Lightning node runs, who manages the channels, and how you recover. Phoenix keeps your keys on your phone and manages one channel with ACINQ for you, resized by splicing, at published fees (as of November 2026: 0.4% + 4 sat per payment sent, 1% plus the mining fee for new liquidity, 1,000 sat to create the channel), but ACINQ sees the destination and amount of your payments. Zeus connects to your own node or runs a Lightning node on your phone, and it finds routes on the phone, so by Zeus’s account its LSP doesn’t learn where your payments go. Fedimint spreads custody across a group of guardians. Wallet of Satoshi is the simplest; new users get its custodial mode where that mode is offered, and we have not verified its Spark mode, which the company calls self-custodial, so check which mode you have and keep only small amounts in it. Before the first deposit, write down the recovery words, and never run the same wallet on two devices. Review Lesson 4.3
Lesson 4.4 — Lightning Payments in Practice
You made your first payment: write down the recovery words before funding, deposit (Phoenix waits for 3 confirmations, and an on-chain deposit stays “sleeping” until the mining fee drops below your maximum), scan an invoice and confirm. The first deposit carries a fixed cost, so a very small one loses a large share to fees. You saw why receiving needs inbound liquidity, how lightning addresses work (their provider learns each time you are paid), how submarine swaps move money between on-chain and Lightning, why tiny payments are cheap in sats but expensive as a percentage, how to read the common error messages, and why the payment preimage is your receipt. Review Lesson 4.4
Lesson 4.5 — Why Run a Bitcoin Node?
Your own full node checks every block and transaction itself, so nobody can lie to you about your payments. It protects your privacy once your wallet is set to use it instead of someone else’s server. Nodes don’t vote: each one refuses blocks that break its rules, and the software you run decides which rules those are (Who Enforces Bitcoin’s Rules tells the rest of that story). Plan for a 2 TB SSD: as of November 2026 the blocks take about 800 GB and Bitcoin Core plans for about 900 GB of disk. A pruned node is just as secure but can’t run the Electrum servers most wallets use, and a light client checks far less and trusts the miners for the rest. Switching Tor on hides your IP address only once your node also stops connecting over the ordinary internet, or sends that traffic through Tor. Review Lesson 4.5
Lesson 4.6 — Umbrel vs. Start9: Bitcoin Node Platforms
You compared four node platforms. Umbrel is the easiest, with hundreds of apps. Start9 puts control first: services on your home network by default, Tor as an optional add-on. RaspiBlitz is built for learning, myNode for simplicity. RaspiBlitz and StartOS are open source; umbrelOS and myNode are published under non-commercial licences. On Umbrel and StartOS alike, nothing updates by itself: you install updates, and our security advisories tell you when one is urgent. Before you switch platforms, close your Lightning channels and keep a fresh channel backup until every one has closed. Review Lesson 4.6
Lesson 4.7 — Setting Up Your Bitcoin Node
The hands-on lesson: umbrelOS on a Raspberry Pi 5 with a 2 TB SSD. You checked the download’s SHA-256 checksum, which proves the file arrived intact but not that it is genuine (only a signature does that), moved Bitcoin Core to the SSD and let it sync for a few days. You connected your wallet to your node: Sparrow straight to Bitcoin Core over Tor on a Raspberry Pi, or through an Electrum server on a mini-PC. Then you added Lightning, saw why a new node can send but not receive, and learned which backup protects channel money (channel.backup, copied off the node after every channel you open or close) and which copy must never be restored (channel.db). On Umbrel you install every update yourself. Review Lesson 4.7
Lesson 4.8 — Running a Lightning Node
You learned the main Lightning implementations (LND, Core Lightning, Eclair, LDK), how to open a channel step by step, and how to use your node for your own payments with Zeus as a remote control. For routing, channels of 1 to 10 million sats are common, and the fees are small: at 100 ppm (parts per million), a node earns 100 sats for every million sats it forwards, so most small nodes earn little once the costs of opening, closing and rebalancing channels are counted. You also saw how to switch on LND’s watchtower client, which is off by default, and how to rebalance channels. Review Lesson 4.8
Lesson 4.9 — Lightning Backups and Watchtowers
Two jobs keep the money in your channels safe. First, someone must watch. A peer who publishes an old balance can be punished only within a waiting period your node sets when the channel opens: with LND’s defaults, 144 blocks (about a day) on channels under about 1.2 million sats, up to 2,016 blocks (about two weeks) on the largest. Without a watchtower, never leave your node off longer than your shortest window. Switch the watchtower client on from your first channel, because a tower only guards the balances revoked after that. Second, keep the right backups: your 24 words for on-chain funds, a fresh channel.backup for channel funds, and never an old channel.db, including one inside a snapshot of the whole machine. A restore closes every channel and brings back settled balances through each peer. Moving to new hardware is not a restore, and two nodes must never share a seed. Finally, you priced channels from real transactions of August 2026, at about 1 sat/vB: about 150 sats to open a channel and 190 to close it cooperatively, while a force close of a 2,000,000-sat channel cost 1,210 sats in all. As of November 2026, 1 to 3 sat/vB is usually enough; at 300 sat/vB, as in December 2023, each step costs tens of thousands of sats. Review Lesson 4.9
Your Infrastructure Stack
After this course, a self-hosted Bitcoin setup looks like this. The figure shows it from the top down, and the table below lists it from the bottom up.
| Layer | Component | Purpose |
|---|---|---|
| Platform | Umbrel, Start9, RaspiBlitz, myNode or a manual setup | Operating system and dashboard that install and run everything else |
| Base Layer | Bitcoin full node (usually Bitcoin Core) | Checks every block and transaction itself |
| Wallet Connection | Electrum server (Electrs or Fulcrum), or a direct connection to Bitcoin Core | Lets on-chain wallets ask your node, not a stranger’s server |
| Payment Layer | Lightning node (LND or Core Lightning) and its channels | Sends, receives and routes instant payments through channels with other nodes |
| Remote Control | Zeus on your phone | Pays and receives from your own Lightning node while you’re away |
| Node Management | ThunderHub or RTL (Ride The Lightning) | Web dashboards to manage channels, fees and rebalancing |
| Protection | Watchtower client on from the first channel, a fresh channel.backup, updates you install |
Responds to cheating while you’re offline, recovers channel funds, fixes security problems |
Your wallet connection and your Lightning node each rely directly on the full node, and your wallets and apps connect to your nodes, not to anyone else’s. Self-hosting removes the wallet company from your payments. Others still see part of your activity: your channel partners and routing nodes see what passes through their own channels, every BOLT11 invoice you hand out names your node, and channel openings and closings are public on the blockchain.
Key Concepts from This Course
- Lightning is Bitcoin’s second layer: it makes payments fast and cheap by moving them into channels, touching the blockchain only to open, resize (splice) and close them.
- HTLCs make routing safe: a multi-hop payment either completes fully or fails entirely, and nobody in the middle can keep it.
- Someone has to watch: the penalty for cheating only works if your node or a watchtower sees the old balance in time, and a tower only guards balances revoked after its client is switched on.
- Receiving needs inbound liquidity: a channel you fund yourself starts able to send, not to receive.
- Routing hides who pays whom, not how much: hops in the middle see the amount they forward, and your wallet’s LSP and your invoices reveal more.
- Wallets range from custodial to fully self-hosted: choose your balance of convenience, privacy and control, knowing who can see your payments.
- A full node means verifying, not trusting, and it protects your privacy once your wallet uses it. The software you run decides which rules it enforces.
- Node platforms make setup simple, and you install their updates yourself.
- Back up the right file: the recovery words restore on-chain funds,
channel.backuprecovers channel funds, and an oldchannel.dbis never restored. - Channels cost on-chain fees to open and close: open the ones you mean to keep, when fees are low, and close cooperatively whenever your peer is online.
- Peer choice beats channel count: a few channels to reliable, well-connected nodes work better than many small ones.
- Routing fees are real but modest: most small nodes earn little once channel and rebalancing costs are counted.
What’s Next?
You now know how to run your own infrastructure: a full node that checks every block, a Lightning node that holds your channels, wallets that connect to them on your terms, and the backups and watchtower that keep channel funds safe.
Infrastructure is only as strong as the way you protect and use it. Course 5: Advanced Bitcoin Security & Privacy covers how blockchain analysis works and how to resist it, coin control, CoinJoin, buying bitcoin without handing over your identity, multisig wallets from theory to practice, network privacy with Tor and VPNs, verifying the software you install, physical security, inheritance planning, and finally how to put it all together into your own sovereignty plan.
The node you built here is the base that Course 5 works from.
Key Takeaways
- Course 4 took you from Lightning as an idea to running your own full node and Lightning node, and keeping its channel funds safe.
- A self-hosted stack: a full node on your platform, with your on-chain wallets and your Lightning node each connected to it, plus a remote-control wallet, a watchtower, backups and updates.
- Running your own infrastructure gives you verification, control and more privacy, though channel partners and routing nodes still see part of your activity.
- Three habits protect a new node operator: arranging inbound liquidity, backing up the right file after every channel you open or close, and running the watchtower client from the first channel.
- Course 5 covers the security and privacy techniques that protect what you built in this course.
Check Your Understanding
1. You open a channel, pay through it 200 times over a month, then close it cooperatively. How many on-chain transactions did that take, and what would a force close have changed?
Answer
Two: the funding transaction that opened the channel and the transaction that closed it. The 200 payments were new balances that you and your partner signed, with no block needed; that is how Lightning scales. In a force close, one side publishes its latest commitment transaction alone. That takes more on-chain transactions (the closing transaction, then a sweep of each side’s share), so it costs more in fees, and the side that closed waits a set number of blocks before it can spend its share (Lessons 4.1 and 4.9).
2. A routing node in the middle of your payment’s route forwards it toward the recipient. What stops it from keeping your money, and what can it learn about the payment?
Answer
The payment reaches it as an HTLC that unlocks only with the preimage, the secret behind the hash in the recipient’s invoice. The routing node learns that secret only when the next hop reveals it to collect, which happens only once the recipient has been paid. If the payment never completes, the HTLC expires and the money returns to the hop before it. Onion routing tells the node the previous hop, the next hop and how much to pass on. It usually can’t tell who sent the payment or who receives it, but the amount it forwards is close to the full payment unless the payment was split across several routes (Lessons 4.1 and 4.2).
3. You pay a shop with Phoenix, and later pay the same shop with Zeus connected to your own node. Who can see what in each case?
Answer
With Phoenix, ACINQ’s node finds the route for you, so ACINQ sees where the payment goes and how much; it still can’t spend or freeze your bitcoin. With Zeus on your own node, no wallet company sits in the middle: your channel partner sees what passes through its channel, and routing nodes further on see roughly the amount but usually not who pays whom. In both cases the shop’s BOLT11 invoice names its node, and the transactions that open and close channels are public on the blockchain (Lessons 4.2, 4.3 and 4.8).
4. You move from Phoenix to your own node and open a 1,000,000-sat channel. A friend’s 50,000-sat payment to you fails, although Phoenix always received without trouble. Why, and how can you fix it?
Answer
Whenever a payment didn’t fit, Phoenix made room for it, resizing your channel and charging 1% plus the mining fee. On your own node nobody does that, and a channel you fund starts with its whole balance on your side, so nothing can move toward you. Spend some sats through it first, ask another node to open a channel to you, buy inbound liquidity from a Lightning Service Provider, or swap part of your balance out on-chain. Each of these puts sats on the far side of a channel (Lessons 4.2, 4.7 and 4.8).
5. One payment says “payment timed out”. Another has shown “pending” for two days. What do you do about each?
Answer
A timeout means your wallet stopped trying new routes: once the payment no longer shows as pending, nothing is locked and you can retry. A payment stuck pending is locked in HTLCs along a route until it completes or its deadline passes, which on LND can take up to about two weeks. Retrying doesn’t help, so keep your wallet or node online and wait. If it can’t fail cleanly, a channel on the route is force-closed, and any of your money in that channel comes back on-chain (Lessons 4.2 and 4.4).
6. A friend wants to start with Phoenix by receiving 5,000 sats over Lightning. What should they do before that, and why is it a poor first deposit?
Answer
First, write down the 12 recovery words on paper and keep them offline: they are the only way back to the wallet if the phone is lost, stolen or broken. Second, that first payment has to create the channel, which costs 1,000 sats plus 1% of the payment plus the day’s mining fee: more than a fifth of 5,000 sats, before the mining fee. The fixed part weighs less on a bigger first deposit, and once the channel has room, receiving is free (Lessons 4.3 and 4.4; Phoenix’s fees as of November 2026).
7. You set up a full node at home and leave your wallets as they were. A miner with most of the network’s hash power then publishes a block paying itself 100 BTC. What does your node do, and has your privacy improved?
Answer
Your node rejects the block, because it breaks the reward rule your node enforces; hash power only decides between chains that are valid under your node’s rules, and nodes don’t vote. Your privacy hasn’t changed yet: your wallets still send your addresses and IP address to their default servers. It improves once each wallet uses your node, through an Electrum server running on it or, with Sparrow, straight to Bitcoin Core (Lessons 4.5 and 4.7).
8. Your umbrelOS download’s SHA-256 checksum matched, and you haven’t touched the node in six months. What did the checksum prove, and is your node up to date?
Answer
It proved your copy is complete and undamaged. It can’t prove the file is genuine: Umbrel’s list of checksums comes from the same server as the image and isn’t signed, so anyone able to swap one could swap the other; only a signature closes that gap. And the node is probably out of date: umbrelOS never installs updates automatically, and apps don’t update themselves either. Check Settings → Software update and the App Store’s Updates, and look at our security advisories for anything urgent (Lessons 4.6 and 4.7).
9. Next month you’ll be away for a week with your LND node switched off. Your channels hold 500,000 sats each, and you have never used a watchtower. What is the risk, and what should you do?
Answer
On LND’s defaults, channels under about 1.2 million sats make a peer wait only 144 blocks, about a day, so a peer who published an old balance early in your trip could collect it long before you got back. The sure fix is to leave the node running, with your Bitcoin node in sync. Switching the watchtower client on now, with a tower on another machine, guards only the balances revoked from now on; the older ones stay unguarded, and a cheating peer can pick any of them. That is why the client belongs on from the first channel. Once it runs, lncli wtclient towers --include_sessions shows whether the tower is acknowledging backups (Lessons 4.8 and 4.9).
10. Your node’s SSD dies. You have your 24 words, a channel.backup copied after your latest channel opened, and a copy of channel.db that a script made last night. What do you restore, and what comes back?
Answer
Restore the 24 words with the channel.backup. Never start a node on last night’s channel.db: it may hold a revoked balance, which would make your node the cheater and let a peer take the whole channel. Your new node rebuilds the on-chain wallet from the words, then asks each peer in the backup to force-close its channel, and your settled balances return on-chain, minus fees. The channels themselves end, payments in flight at the moment of failure are lost, and the money in a channel whose peer never comes back stays stuck while that peer is gone (Lessons 4.7 and 4.9).