Bitcoin for Builders Lightning and Fedimint

Lightning: channels, invoices and routing basics

How two Bitcoin transactions can carry thousands of payments: channels, BOLT11 invoices, routing and liquidity, with a local Polar network.

60 minIntermediate4 / 8

Draft: this lesson is still waiting for review.

What you'll learn

Explain how a channel is opened, used and closed
Decode a BOLT11 invoice and name its main fields
Pay across a three-node route and explain inbound vs outbound liquidity

Key terms

Lightning Network (mtandao wa Lightning): A network on top of Bitcoin for fast payments with very small fees.
channel (chaneli): A payment link between two Lightning nodes, locked by a Bitcoin transaction.
invoice (ankara): A Lightning payment request, often shown as a QR code, with an amount and an expiry time.
node (nodi): A computer running Bitcoin or Lightning software that checks every rule for itself.
multisig: A setup where several signatures are needed to spend bitcoin, for example 2 of 3.

The Lightning Network moves payments off-chain. Two parties lock bitcoin into a shared output once, then update who owns how much as often as they like, settling on-chain only when they're done.

Step 1: Channels in three moves

Open. Alice and Bob create a funding transaction paying into a 2-of-2 multisig output. It is mined like any other transaction.
Update. For every payment they sign a new commitment transaction that splits the funds differently. Old states are revoked, so publishing one would let the other side take everything.
Close. Either side publishes the latest commitment, or both sign a cooperative close. The final balances go on-chain.

A channel has a capacity (the funding amount) split into outbound liquidity (what you can send) and inbound liquidity (what you can receive).

Done when: you can explain why a brand-new channel funded only by Alice can't receive.

Step 2: Routing

Alice doesn't need a channel to everyone. If Alice→Bob and Bob→Carol channels exist, Alice can pay Carol through Bob. HTLCs (hash time-locked contracts) make each hop conditional on revealing a secret, the preimage, so either the whole route settles or none of it does. Bob earns a small routing fee.

Step 3: Invoices

A BOLT11 invoice such as lnbcrt10u1p... encodes:

Field	Meaning
`lnbcrt`	Lightning, regtest network
`10u`	Amount: 10 micro-bitcoin = 1,000 sats
payment hash	Hash of the preimage that unlocks the payment
description	Human-readable purpose
expiry	Seconds until it can't be paid
signature	Proves which node issued it

Step 4: Lab with Polar

Install Polar and create a network with three LND nodes: Alice, Bob and Carol.
Start it, then mine a few blocks and fund Alice from Polar's UI.
Open channels Alice→Bob and Bob→Carol (for example 1,000,000 sats each). Mine 6 blocks.
On Carol, create an invoice for 10,000 sats. In Alice's terminal:

lncli decodepayreq <invoice>
lncli payinvoice <invoice>

Expected: decodepayreq shows the amount, description and expiry; payinvoice succeeds with a route through Bob.

Now try paying Alice from Carol. If it fails, look at each channel's local and remote balance and explain why.

Lab evidence

Decoded invoice with amount, description and expiry marked.
Successful payment output showing the route.
One sentence explaining the failure (or success) of the reverse payment in terms of liquidity.

Practise this concept

Lightning channel balances
Move example sats between Alice and Bob and watch the direction-dependent balance change.

Reflect

Write your answer down, or talk it over with a friend or your chama.

Why can't Alice receive a payment on a channel she just opened with all the funds on her side?
Which parts of a Lightning payment are on-chain, and which are not?