Some people learn to swim by reading a book. Others get pushed into the deep end. Today was both. Somewhere in the middle, a lifeguard(Polar) showed up.
Today the goal was simple on paper. Learn the Lightning Network, understand how it works and continue with the setup. The CLI came first. No shortcuts. No GUIs. Just a terminal and a lot of commands.
The LND binaries for version 0.20.1-beta were downloaded and extracted. After that, lnd and lncli were moved into /usr/local/bin so the system could actually find them.
Then came the first real friction point.
LND was executed, but it immediately threw errors.
At first, it looked like a simple config issue. It was not.
LND does not just run, it needs to be explicitly told what environment it is living in
So it had to be run with the correct flags
--bitcoin.active
--bitcoin.regtest
--bitcoin.node=bitcoind
`
Without those, LND defaults to btcd which was not even running. That mismatch alone broke everything.
Once it was pointed to bitcoind, things finally started behaving.
That was the first real lesson LND is strict. If the environment is not described properly it refuses to guess.
Next came Bitcoin Core configuration
That meant editing bitcoin.conf and adding ZMQ
bash id="wtthwk"
zmqpubrawblock=tcp://127.0.0.1:28332
zmqpubrawtx=tcp://127.0.0.1:28333
The file was saved. Everything looked right. Nothing worked.
LND kept failing silently until the real issue surfaced. bitcoind was still running the old config.
Restarting it fixed everything instantly.
Three terminal windows were opened Alice, Bob and a general workspace
Wallets were created
bash
alice create
bob create
Passwords were set. Seed phrases were skipped since this was regtest.
At first both nodes showed synced_to_chain=false Still catching up on 101 blocks from yesterday.
Then suddenly true
That moment when everything just clicks into place.
Alice was funded next
A new address was generated
bash
alice newaddress p2wkh
1 BTC was sent from the regtest wallet then blocks were mined
bash
bitcoin-cli generatetoaddress 6
100,000,000 sats appeared
Still one of the most satisfying moments in the stack
Lightning setup came next
Bob’s pubkey was grabbed and nodes were connected
bash
alice connect <bob_pubkey>@localhost:9736
Then a channel was opened
bash
alice openchannel --node_key=<bob_pubkey> --local_amt=1000000
A few blocks later the channel became active
Alice had 1M sats Bob had 0
For now
First payment
An invoice was created
bash
bob addinvoice --amt=50000 --memo="Lightning Coffee"
Payment went through using payinvoice
And it worked
Nothing moved in the channel. Only the state changed.
That is the system in one line.
Alice Bob Charlie
A simple chain formed next
Alice had no direct channel to Charlie but payment still flowed
Bob became the router
A tiny fee was earned for forwarding it
That is when Lightning stopped feeling like nodes and started feeling like a network
Polar came next
After surviving the CLI setup, polar felt like the easy mode reward
It was not
Polar depends on Docker containers. Without Docker running properly nothing starts
So Docker had to be installed and healthy first
Only then did Polar work
Two LND nodes were dragged onto a canvas and started
Everything came up instantly
No config files, no flags, no terminal juggling
But under the hood it was still Docker running LND exactly like before
Polar does not remove complexity. It wraps it
The Problem Lightning Solves
Bitcoin on chain does 2-7 transactions per second.Visa does tens of thousands. Blocks take on average 10 minutes to be mined and added to the chain
That makes real time payments impossible
Lightning fixes this by moving transactions off chain
One on chain transaction opens a channel After that payments are instant and nearly free
Think bar tab You do not swipe for every drink You settle at the end
How a Channel Actually Works
A Lightning channel is a 2 of 2 multisig wallet
Both participants control it Neither can move funds alone
Every payment updates shared state Old states are invalidated using revocation keys If someone cheats they lose everything
That is the enforcement layer
So when sats moved between Alice and Bob nothing changed on chain Only state moved
Invoices and the Preimage
Invoices are hash locks
A secret preimage is generated and only its hash is shared
Payment locks funds to that hash
Reveal the preimage and funds are claimed
It was verified manually by hashing and matching the invoice hash
It matched exactly
That is the moment cryptography stops being abstract and starts being real
Multi Hop Routing
Alice Bob Charlie
Alice does not know Charlie Charlie does not know Alice Bob just forwards payments
Bob earns a small fee
Each node only sees one hop That is onion routing
Forwarding history showed the fee instantly
Small but real
That is the incentive system working
Channel Close Options
Cooperative close is clean both parties agree funds settle on chain
Force close is fallback one party disappears and state is broadcast then locked by timelock
Both were tested Cooperative was instant Force close felt like waiting for the chain to settle a dispute
Both are necessary
Why This Matters
Lightning is already live
- Strike enables global Bitcoin payments
- Bitnob enables cross border remittances
- Cash App supports Lightning at scale
- Pick n Pay accepts Bitcoin in stores
What used to feel experimental is already infrastructure
Day 3 Summary
CLI forced everything to be understood flags btcd vs bitcoind ZMQ wallets channels failures
Polar showed what happens when all of that runs inside Docker with a UI on top
Both mattered
Lightning channels are multisig with evolving state Payments are hash locked Routing is trustless Timelocks enforce fairness
Somewhere between broken configs and running containers money moved without banks without intermediaries and without permission
Just math doing its job
