How Bitcoin's Lightning Network Works Under the Hood

The Times 03/Jan/2009: Chancellor on the brink of second bailout for banks.Satoshi Nakamoto put that headline in Bitcoin's genesis block on January 3rd, 2009, not as metadata. not as a timestamp. but as a statement. The idea behind Bitcoin was simple: money should not require trust, not trust in a bank, not in a government, not in any institution, and since the first block, Bitcoin has operated exactly as designed which is without permission and without authority. Every participant on the network holds their Bitcoin under their own keys, subject to rules enforced by mathematics rather than policy. However decentralization isn’t free, it comes with a cost, and for Bitcoin that cost was speed. A new block is found roughly every ten minutes, so a payment waits around that long for its first confirmation, and often longer. To see why, we need to look at what the network actually does. When you send a transaction, it does not go straight through. It first gets broadcast to the network, where thousands of nodes independently validate the transaction: checking that the sender has the funds, that the signature is correct, and that the rules are met. Only after that does it land in a waiting area called mempool, waiting to get added to a block, and eventually get mined. This is Bitcoin's design, and to a degree it is fair. If you want a ledger that nobody controls, then every participant in the network has to agree on its state (all or nothing). That also means writing to the ledger has to be expensive because cheap writes can invite spam, attacks, and data bloat. That is part of what gives Bitcoin's security model its teeth, but it also makes Bitcoin feel unusable for everyday payments majorly because we live in a world where transaction speed is expected. Nobody wants to wait ten minutes for payment confirmation for a cup of coffee. So the question became: how do you keep everything that makes Bitcoin what it is, while making it actually usable at scale? The answer, at least the most adopted one so far, is the Lightning Network. The lightning network is a second layer protocol built on top of Bitcoin that enables near instant payments between participants without touching the blockchain for every transaction. The keyword is ‘on top’, Lightning does not replace Bitcoin's base layer, it sits above it. It takes a confirmed on-chain transaction as its foundation and builds from there, allowing participants to transact freely off-chain and only settling the final state back to the blockchain when they are done. The chain does the heavy lifting at the start and at the end, while everything in between moves at a completely different speed. Under the hood, the lightning network is a clever combination of cryptographic commitments, time locked contracts, and a routing network that lets payments travel through intermediary nodes. To give a foundation, we’d summarize some basics terminologies of Bitcoin, and how all of them come together to build payment channels, HTLCs, and how it all comes together to achieve a routed payment network called the Lightning Network. Bitcoin Transaction At the protocol level, a Bitcoin transaction is a data structure: a bundle of bytes broadcast to the network and validated independently by every node, which either accepts it into its mempool or rejects it. Every full node runs the same rules and reaches the same conclusion. A transaction consists of a version number, one or more inputs, and one or more outputs. An output describes where value goes. It carries two things: an amount and a locking script. The amount is the value being sent, denominated in satoshis. The locking script (the scriptPubKey) defines the exact condition that must be met before anyone can spend that output. In the most common case, the condition is: "provide a public key that hashes to this value, and a valid signature from the matching private key." The output does not care who you are. If you can satisfy the condition, the money is yours. Until then, the output sits in the UTXO set, the record every node keeps of all outputs not yet spent. An input does two things: it points at an existing output, and it proves the right to spend it. An input does not contain money. It is a reference to money that already exists, paired with proof of authorization. Each input carries: Outpoint: the output being spent, identified by a transaction ID and an output index (vout). scriptSig: the data that satisfies the output's locking script. In SegWit transactions this data moves to the witness instead. nSequence: a number field whose role comes up again under timelocks. Witness: signatures and other spending data, kept separate from the rest of the transaction since SegWit. Bitcoin Script As we already established, every output in Bitcoin transaction isn’t just an amount, it also contain a program that defines the exact conditions under which the output can be spent. That program is written in a language called Script. Unlike most programming language, Bitcoin script was not designed to build applications or run arbitrary logic, it was designed to evaluate spending conditions on Bitcoin outputs and to determine whether a given input satisfies them. Script is stack based. A quick reminder, a stack is a data structure that follows the last-in first-out (LIFO) principle, meaning that the last item you put in is the first item you take out. You can only push (add) and pop (remove) items from the top. Bitcoin script execution works by processing instruction from left to right. Each instruction either pushes data onto the stack or performs an operation on what is already there. At the end of the execution, the result is whatever sits on the top of the stack. If it is non-zero value (true) then the script passes. If it is zero or empty (false) the script fails. The instructions are called opcodes, and they fall into a few families: Arithmetic: OP_ADD, OP_SUB, OP_ABS. Flow control: OP_IF, OP_ELSE, OP_ENDIF. Stack manipulation: OP_DUP, OP_DROP, OP_SWAP. Cryptographic: OP_SHA256 hashes the top item with SHA-256. OP_HASH160 hashes it with SHA-256 and then RIPEMD-160. OP_CHECKSIG takes a public key and a signature off the stack and pushes true if the signature is valid for this transaction under that key. Timelocks: OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY, which check the spending transaction against time or block-height constraints. Multi-Signature Scripts A standard output has one lock and one key: one locking script, one public key hash, one signature to spend it. Its entire security rests on a single private key. Whoever controls that key controls the output. A multisignature script changes that. Instead of one key opening one lock, the lock needs several keys turned at once. The output is controlled by a threshold of signers drawn from a defined set, written M-of-N: N is the number of keys allowed to sign, and M is how many of them must sign for the output to move, with M never larger than N. A 2-of-2 needs both parties. A 2-of-3 needs any two of three keys. A 3-of-5 needs any three of five. Timelocks Timelocks prevent an output from being spent until a certain time or block height has passed. They come in two flavours, absolute and relative, each with a transaction-level field and a script-level opcode. nLockTime is a field on every transaction. It tells the network: do not accept this transaction before this point. A transaction with nLockTime set to block 900,000 is invalid until block 900,000 exists. Miners will not include it, and nodes will not relay it before then. CheckLockTimeVerify (CLTV) CLTV does what nLockTime does, but the time condition is now sitting at the output level rather than the transaction level making the condition becomes part of the coin itself. nSequence: Every input in a Bitcoin transaction carries a field called nSequence. Satoshi included it for an early idea of updating transactions before they confirmed, but it sat at a default value for years doing nothing. In 2016, BIP 68 repurposed it to encode a relative delay. Instead of a fixed block number, it holds a number of blocks that must pass after the output being spent was confirmed. The clock starts from the output's own birthday, not from a date chosen in advance. CheckSequenceVerify (CSV) is the opcode that enforces that relative delay. When a transaction tries to spend an output whose script contains CSV, the script reads the input's nSequence and checks it against the delay written in the script. If not enough blocks have passed since the output confirmed, execution stops and the output cannot move. nSequence carries the number; CSV reads it and enforces it. The key difference from CLTV is that CSV's clock starts when the output lands on chain, not at a fixed point in time. That property turns out to be essential for Lightning, as we will see shortly. Payment Channels A payment channel is a way of building Bitcoin transactions that are secured by the blockchain without being recorded on it. It is not a separate system or network, but leverage existing Bitcoin implementation allowing two parties transacts freely outside of the on-chain network with the guarantee that either party can enforce the final state on-chain at any time. Here the blockchain is used twice, first to lock funds in after which several transactions can be carried out between both parties. When done the blockchain is used again to close the channel. Everything between those two points happens instantly, with no fees, no block wait, no on-chain fees. The security guarantee is this: neither party can steal from the other. The worst outcome is that the last agreed state gets enforced on chain. A channel closes either cooperatively, with both parties signing a final transaction that reflects the current balance, or unilaterally, with one party broadcasting their latest valid commitment. Either way, the network enforces the final balance. That is what it means to be secured by the blockchain without being recorded on it. Simple Payment Channels A simple payment channel is the most direct answer to the on-chain bottleneck. Two parties who transact repeatedly open a channel, trade off-chain, and settle once at the end. Take Alice buying a video stream from Bob. With a card payment or a bank transfer, Alice either pays upfront and trusts Bob to deliver, or pays afterwards and Bob trusts her to pay. A payment channel removes that risk. Video streams one direction while money streams the other at near-zero cost. Alice can effectively pay for every second she watches, and the stream stops the moment the payments stop. Say the streaming video costs 100mBTC, first Alice constructs a transaction that sends 100 mBTC into a 2-of-2 multisig output held by her and Bob. Once it is confirmed, the money can move as long as both of them sign. This is the funding or commitment transaction and it opens the channel between Alice and Bob. One detail protects Alice here: before she broadcasts it, she has Bob sign a refund transaction that returns her 100 mBTC after a timelock, so her money is not stuck if Bob disappears. Bob sends the first second of video, and in return Alice signs 1 mBTC of the transaction to Bob, and the remaining 99 to herself. Once Bob has this transaction of 1 mBTC (with Alice signature), Bob can at any moment in time counter sign the multisig with his signature and this becomes a valid transaction that Bob can deposit. Depositing means settling it on chain to the Bitcoin network and once that has happened Bob would own the 1 mBTC output of that transaction while Alice would own the remaining 99. What makes the channel work is that Bob does not have to broadcast it. He knows he can, and that the network will honor it, so he keeps it off-chain and the stream continues. Each second, Alice signs a new transaction moving one more mBTC to Bob. Her share shrinks, his grows. When the stream ends, one of them broadcasts the final settlement, say 70 mBTC to Bob and 30 mBTC back to Alice. Only two transactions ever reach the blockchain: the funding transaction and the settlement. Everything in between stays off-chain. Bi-Directional Payment Channels A simple channel only moves money one way. In a bi-directional channel, both parties fund a 2-of-2 multisig they each hold a key to. Once the funding transaction confirms, they can send value back and forth by signing a series of commitment transactions. Each commitment transaction spends the multisig with an output that can be redeemed by either Alice or Bob by exchanging signatures for the multisig. These balances can remain between them as off-chain transactions and they can update them continuously until finally they have settlement transaction that corresponds to the final balance in the channel after several back and forth transactions. This raises a problem a one-way channel did not have. Every old commitment transaction is still a valid, signed transaction. What stops Alice from broadcasting an old state where she had more money? Two mechanisms work together: a timelock and a revocation key. Timelock delays the ability to redeem the commitment transaction, it prevents either party from broadcasting an older, more favorable state because a more recent commitment transaction becomes spendable first. The second mechanism is the revocable commitment, each channel state is represented by a pair of asymmetric commitment transactions, one held by Alice, one held by Bob. These are not identical. Alice's version has a time delay on her own output. Bob's version has a time delay on his own output. If Alice broadcasts her commitment transaction, Bob has a window defined by CSV during which he can broadcast a revocation key that lets him claim everything, penalizing Alice for cheating. When the channel state updates, both parties exchange revocation secrets for the old state. Holding those secrets is what makes it dangerous to broadcast an old commitment. If Alice tries to broadcast a state from three updates ago, Bob has the revocation key for that state. He can use it to claim the entire channel balance before Alice's time delay expires. Hash Time-Locked Contracts (HTLCs) Everything so far, from multisig to timelocks to revocable commitments, solves the problem of two specific parties paying each other. Alice and Bob open a channel, send money back and forth, and close. The real world does not work like that. Alice does not have a channel with everyone she wants to pay, and opening a new on-chain channel for every relationship defeats the purpose: you are back to on-chain transactions, fees and confirmations. What Lightning needs is routing: a way for Alice to pay Carol through Bob, without a direct channel between Alice and Carol, without trusting Bob to forward the money honestly, and without Bob being able to keep it. HTLCs make this possible. An HTLC adds two conditions to the usual signature check: a hash lock and a time lock. It starts with the recipient. Carol generates a random secret R, called the preimage, computes its hash H, and gives H to whoever is paying her. The contract then looks like this (simplified): if #Payment if you have the secret R HASH160 EQUALVERIFY ELSE #Refund after timeout CHECKLOCKTIMEVERIFY DROP CHECKSIG ENDIF In plain terms, the script is saying: I will pay you X bitcoin, but only if you can present the preimage of this hash within this time window. If the time expires and you have not presented it, the funds return to me. With this we see where the Hash and the time lock comes into place for the contract. The hash lock alone is not enough. If Alice locks funds behind H and nobody ever reveals R, those funds are frozen forever. Alice needs a guarantee that if the payment fails for any reason her money comes back. This is where CLTV comes in. The HTLC does not just say: pay if you reveal R. It says: pay if you reveal R before this block height. After that block height, if R has not been presented, the funds return to the sender automatically. The payment is now bounded in time. It either completes (i.e. R is revealed, funds move) or it expires and funds are return. There is no third outcome where money disappears. You can read more on HTLCs here. Routing With HTLCs and payment channels in place, we arrive at the last piece: routing. If you had to open a channel to everyone you pay, Lightning would offer little advantage, since every relationship would still cost a funding and a settlement transaction. Instead, Lightning is a network of payments routed over channels. You do not need a channel with your recipient. You need a path of channels, connected end to end, that reaches them. Introduce a third party: Carol. Alice wants to pay Carol but remember Alice only has a channel with Bob. Bob on the other hand has a channel with Carol. Alice does not have a payment channel with Carol, but instead discovers a path and this path consists of a payment channel from Alice to Bob, and a payment channel from Bob to Carol. Because these payment channels exist and because the lightning network allows Alice to discover these payment channels, Alice can construct this path and route payment to Carol without opening a new channel. This means that based on the general idea that if you have a sufficiently connected network, everyone is within a certain number of hops of everyone else from one end of the network to the other, and you have a fully routable network. Here is how routing payment works: The first thing that happens is Carol constructs an invoice for Alice to pay, and this invoice consists of the hash of the secret (R) that only Carol knows and doesn’t communicate it to anyone. Carol then gives the hash to Alice, and the hash tells Alice how she needs to construct the payment. This payment can only be redeemed by whoever knows R, at this point it is just Carol. Once Alice has the hash, Alice creates an HTLC with Bob: "Pay Bob 1.0000001 BTC if he presents the preimage of H within 48 hours." Bob, recognizing this, creates a matching HTLC with Carol: "Pay Carol 1 BTC if she presents the preimage of H within 24 hours." Note the asymmetry in timeouts, Bob gives himself a window to collect from Alice before his own obligation to Carol expires. Now, let’s assume there is no direct payment channel between Bob and Carol, and there are two or three intermediate nodes; each node creates an HTLC with a shorter timeout to the next hop until it eventually gets to Carol. Carol knows R. She presents it to Bob. Bob collects from Alice. Payment complete. If Carol never reveals R, all HTLCs expire and funds return to senders. At no point did anyone have to trust anyone. The hash locked the payment, and the timelock ensured it could not be held hostage indefinitely. The key is that the promises that are being propagated forward from Alice to Carol are meaningless if no one has the secret. They also only commit each node in the route only insofar as they receive the secret from the next hop. For example, Bob is not obligated to pay Carol until she reveals R. Without it, the script cannot execute. But the moment Carol reveals the secret, Bob now has the secret, and therefore Bob can now claim the HTLC from Alice. Also, Bob isn’t making a commitment that puts Bob at risk, because Bob knows that the only way he is going to pay Carol is if she has the secret, and once she hands it over, Bob uses that same secret to collect from Alice. Each HTLC carries a slightly different amount, 1.0000001 BTC from Alice, 1 BTC to Carol. The payment from Alice to Carol is 1 BTC, the extra 0.0000001 BTC that are being added to Alice HTLCs are routing fees. So when Bob receives 1.0000001 BTC but only pays out 1BTC, effectively Bob gains 0.0000001 BTC, and this is the fee for Bob to do this routing on behalf of Alice. Two questions follow naturally. How does Alice find a path through a network whose channel balances are private? And how is privacy protected along the way? On privacy: each node in the route knows only the hop before it and the hop after it. It cannot tell whether the previous node started the payment or whether the next one is the final recipient, and it does not know its own position in the route. Only the sender and the recipient know both ends. This comes from onion routing, an idea borrowed from Tor. The sender builds the entire route and encrypts it in layers. Each node peels off one layer and learns only where to forward the payment next. This protects privacy, but it creates a dependency: the sender must know enough about the network to build a working route in the first place. That knowledge comes from the gossip protocol, through which nodes announce their channels and fee policies. Gossip gives a rough map of the network, but not channel balances, which are private and change with every payment. Route finding is therefore probabilistic. Alice picks a path that looks plausible based on channel capacity, tries the payment, and if it fails somewhere for lack of balance, retries along a different path. This is the network's most significant weakness today. As it grows and payment sizes vary, pathfinding gets harder, failure rates rise, and large, well-connected routing nodes become disproportionately important. That is a centralizing pressure on a system built to resist centralization. Several improvements target this without giving up privacy. Trampoline routing delegates pathfinding to an intermediate node, which helps light clients such as phones. Multi-path payments (MPP) is another attempt to solving, it split one payment into smaller parts that travel different routes, so no single channel has to carry the full amount. Putting it together None of these pieces stands alone. Each one builds on the one before it: Script makes multisig possible. Multisig makes channels enforceable, because neither party can move the funds alone. Timelocks give the honest party time to respond, which makes revocation possible. Revocation makes bi-directional channels safe, because broadcasting an old state costs the cheater everything. HTLCs extend that safety across several hops, so a payment can pass through people who do not trust each other. Routing connects those hops into a network. Underneath all of it sit the UTXO model, the block structure and the ten-minute clock. Bitcoin remains the settlement layer that gives the whole construction its final anchor. That is the real achievement of Lightning. It does not loosen any of the rules that made the genesis block's message mean something. Funds are still held under the owner's own keys, every off-chain payment is backed by a transaction that the base layer will enforce. What changes is how often we need to ask the chain. Lightning goes to Bitcoin to open a channel and to close it, and in between, payments move at the speed of a message. Money without trust, and now, money without the wait.