What is the Bitcoin Lightning Network?

Why does Bitcoin need a Lightning Network?

Bitcoin was designed, in Satoshi Nakamoto's 2008 whitepaper, as electronic cash sent directly between people without a financial institution. Each payment, however, has to be included in a block, and blocks arrive on average every ten minutes with limited space. When the Lightning whitepaper was drafted in January 2016, its authors put Bitcoin's capacity at under 7 transactions per second with 1 MB blocks, against a Visa peak of 47,000 per second during the 2013 holidays.

Simply making blocks bigger was not attractive. The paper estimated that matching that Visa peak on-chain would need blocks of nearly 8 GB every ten minutes, which only a few large operators could process — undermining the decentralisation that gives Bitcoin its value. Lightning's answer is to keep most payments off the chain entirely, making it a layer 2 on top of Bitcoin's layer 1.

How does a payment channel work?

A channel is like a bar tab that both sides sign. Two parties, say Alice and Bob, create a funding transaction that locks bitcoin in an output needing both their signatures — a 2-of-2 multisig. That transaction goes on the blockchain.

From then on, every payment is a new commitment transaction: a fully signed transaction that would pay out the current balances if broadcast. The parties keep it to themselves and simply replace it with a newer one after each payment. Under the Lightning specification (BOLT 2), each side must also keep a small reserve in the channel, so neither can drain it to zero.

When they are done, they close the channel. A cooperative close publishes one final transaction with the agreed balances. If one side disappears, the other can close unilaterally by broadcasting the latest commitment transaction, but must then wait a set number of blocks before spending its own share.

How can you pay someone you have no channel with?

Opening a channel with every shop would defeat the purpose. Lightning links channels into a network and routes payments across them using hashed timelock contracts (HTLCs). The receiver creates a secret and shares only its hash. Each hop along the route promises to pay the next one if it can reveal the secret before a deadline.

The whitepaper's own example routes Alice to Dave through Bob and Carol, with deadlines that shrink at each hop: three days for Alice's promise to Bob, two for Bob's to Carol, one for Carol's to Dave. When Dave reveals the secret to collect, it travels back along the route and every hop gets paid. Shrinking deadlines mean no middle hop can be left out of pocket.

In practice the receiver starts by sending an invoice. Under the BOLT 11 specification, a Bitcoin mainnet invoice begins with lnbc, carries the payment hash and, unless it says otherwise, expires after one hour.

How does Lightning compare with paying on-chain?

What can go wrong on Lightning?

Lightning swaps one big trust assumption for several smaller duties. Its security rests on penalties: when you update a channel, you hand your partner the key to revoke your old state. If you later broadcast that old state to claim more, your partner can take all the channel's funds. But that only works if your partner notices in time — the paper stresses that participants must watch the blockchain during the timelock window.

The whitepaper itself lists risks: losing your channel data (so you cannot prove the latest state), failing to act before a timeout, private keys stolen from an always-online node, mass channel closures that flood the blockchain, and miners refusing to include penalty transactions.

What mistakes do beginners make with Lightning?

• Expecting to receive without capacity. A channel can only pay you up to the balance your partner has on their side.
• Paying an expired invoice. Invoices expire — an hour by default under BOLT 11 — so ask for a new one rather than retrying an old one.
• Confusing a Lightning invoice with a Bitcoin address. An lnbc invoice and an on-chain address are different things; wallets that support only one cannot pay the other.
• Forgetting on-chain fees. Opening and closing channels are ordinary Bitcoin transactions with ordinary network fees.