How Does the Lightning Network Actually Work?


Most of the content below has been either directly quoted or slightly modified from “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments”. Quotation marks and citations have been omitted for readability. I highly recommend it to anyone interested in understanding the inner workings of future Bitcoin Lightning Network implementations.


How does the Lightning Network actually work?

The base of this example was taken from “The Bitcoin Lightning Network” white paper.

Say Alice wants to buy a coffee from Dave, but Alice and Dave have never done a transaction together and do not have any prior existing relationship.

The Lightning Network provides Alice a way to pay Dave in an instantaneous (no block confirmations necessary), trustless (as in Bitcoin), low fee (as opposed to on-chain transactions), and decentralized (as in Bitcoin) manner.

At the start of the transaction, Dave takes any random piece of data (R) and hashes it (HR) [a hash is a cryptographic function whereby any data run through the hashing function will always produce the same output, but it is impractical to work backwards to the input data from the hashed output]. Dave then gives Alice the HR value via a normal secure communication method (i.e. not via a Bitcoin transaction).

The Lightning Network determines that Alice can pay Dave via two hops through Bob and Carol.

Each payment hop will be accompanied by a Hashed Timelock Contract (HTLC) between the two participants and each hop will have a timeframe element which is set in relation to the other hops in the chain.

At each hop (A to B, B to C, C to D), the participants (ex: A and B) initiate an HTLC which basically states:

  • Alice contributes 0.1 BTC to an HTLC “smart contract” (ugh!) with Bob. Bob cannot spend this money until he knows “R” (the secret word).
  • If Bob knows “R” within 3 days and proves this to the HTLC, then Alice will settle the contract by paying Bob 0.1 BTC as stated in the contract.
  • If 3 days have elapsed, then the above clause is null and void and the contract is invalidated. Alice will be refunded her previously contributed 0.1 BTC from the contract with Bob as stated in the contract (the Segwit transaction malleability fix made this step possible and prevents Bob (or anyone else) from holding Alice’s funds hostage in the contract).

After the HTLCs have been established between each participant, Dave shares the secret word with Carol and pulls the 0.1 BTC funds from the contract for himself. This process waterfalls back down to Alice’s final payment. Additionally, Alice knows that Dave has successfully received the payment because of her receipt of the secret word (R).

If at any point any participant is suspected to be a bad actor, any participant can broadcast their transaction onto the public Bitcoin blockchain and reclaim any funds at issue.

The beauty of this setup is that through the implementations of the Lightning Network which are being developed, all this hashing, contract generation, payment execution, and knowledge sharing occurs instantaneously and nearly free over the internet – without any record of it (aside from opening and closing channels) hitting (or bloating) the public Bitcoin blockchain.

I (Daniel) am of the opinion that the Lightning Network will be THE killer Bitcoin app and will make Bitcoin a viable medium of exchange (in addition to its existing strong store of value properties) for many hundreds of millions of people around the world.

—– END —–

Below are more specifics of the Lightning Network and excerpts from the white paper.

“If a tree falls in the forest and no one is around to hear it, does it make a sound?”

The above quote questions the relevance of unobserved events —if nobody hears the tree fall, whether it made a sound or not is of no consequence. Similarly, in the blockchain, if only two participants care about an everyday recurring transaction, it’s not necessary for all other nodes in the bitcoin network to know about that transaction.

Using a network of micropayment channels, Bitcoin can scale to billions of transactions per day with the computational power available on a modern desktop computer today.

These channels are not a separate trusted network on top of bitcoin. They are real bitcoin transactions.

Micropayment Channels Do Not Require Trust

Without cryptography in determining the relative timing of events in a payment channel, an interesting problem is created: If one’s counterparty disagrees about the current balance of funds (or time the tree fell), then it is one’s word against another. Without cryptographic signatures, the blockchain will not know who owns what.

By encumbering the Bitcoin transaction outputs with a hashlock (spending requires knowledge of a secret hash) and timelock (prohibits unauthorized spending prior to a mutually agreed future date), the channel counterparty will be unable to outright steal funds and Bitcoins can be exchanged without outright counterparty theft. Further, by using staggered timeouts, it’s possible to send funds via multiple intermediaries in a network without the risk of intermediary theft of funds.

Blockchain Transaction Fees for Bidirectional Channels

The Lightning Network fees should be significantly lower than on-chain transactions, as many transactions on a Lightning Network channel can be settled into one single blockchain transaction. With a sufficiently robust and interconnected network, the fees should asymptotically approach negligibility for many types of transactions (with a one satoshi fee being sufficient in most cases). With cheap fees and fast transactions, it will be possible to build scalable micropayments, even amongst high-frequency systems such as Internet of Things applications or per-unit micro-billing.

Hashed Timelock Contract (HTLC)

To be able to construct secure transfers using a network of channels across multiple hops to the final destination requires a Hashed Timelock Contract (HTLC).

The purpose of an HTLC is to allow for global state across multiple nodes via hashes. This global state is ensured by time commitments and time-based unencumbering of resources via disclosure of preimages. Transactional “locking” occurs globally via commitments, at any point in time a single participant is responsible for disclosing to the next participant whether they have knowledge of the preimage R (a random piece of data). This construction does not require custodial trust in one’s channel counterparty, nor any other participant in the network.

An HTLC is also a channel contract with one’s counterparty which is enforcible via the blockchain.

These contract terms are programmatically enforced on the Bitcoin blockchain and do not require trust in the counterparty to adhere to the contract terms, as all violations are penalized via unilaterally enforced fidelity bonds, which are constructed using penalty transactions spending from commitment states. If Bob knows R within three days, then he can redeem the funds by broadcasting a transaction; Alice is unable to withhold the funds in any way, because the script returns as valid when the transaction is spent on the Bitcoin blockchain.

The first path (defined in the OP IF) sends funds to Bob if Bob can produce R. The second path is redeemed using a 3-day timelocked refund to Alice. The 3-day timelock is enforced using nLockTime from the spending transaction.

The Bitcoin Lightning Network

By having a micropayment channel with contracts encumbered by hashlocks and timelocks, it is possible to clear transactions over a multi-hop payment network using a series of decrementing timelocks without additional central clearinghouses.

As Bitcoin enables programmatic money, it is possible to create transactions without contacting a central clearinghouse. Transactions can execute off-chain with no third party which collects all funds before disbursing it – only transactions with uncooperative channel counterparties become automatically adjudicated on the blockchain.


Lightning Network fees, which differ from blockchain fees, are paid directly between participants within the channel. The fees pay for the time-value of money for consuming the channel for a determined maximum period of time, and for counterparty risk of non-communication.


While it may appear as though this system will mitigate the block size increases in the short term, if it achieves global scale, it will necessitate a block size increase in the long term.

Use Cases

Instant Transactions: Using Lightning, Bitcoin transactions are now nearly instant with any party. It is possible to pay for a cup of coffee with direct non-revocable payment in milliseconds to seconds.

Micropayments: Bitcoin blockchain fees are far too high to accept micropayments, especially with the smallest of values. With this system, near-instant micropayments using Bitcoin without a 3rd party custodian would be possible. It would enable, for example, paying per-megabyte for internet service or per-article to read a newspaper.

Exchange Arbitrage: There is presently incentive to hold funds on exchanges to be ready for large market moves due to 3-6 block confirmation times. It is possible for the exchange to participate in this network and for clients to move their funds on and off the exchange for orders nearly instantly. If the exchange does not have deep market depth and commits to only permitting limit orders close to the top of the order book, then the risk of coin theft becomes much lower. The exchange, in effect, would no longer have any need for a cold storage wallet. This may substantially reduce thefts and the need for trusted third party custodians.

Cross-Chain Payments: So long as there are similar hash-functions across chains, it’s possible for transactions to be routed over multiple chains with different consensus rules. Payment can be routed by participants in both chains in the hop. E.g. Alice is on Bitcoin, Bob is on both Bitcoin and X-Coin and Carol is on a hypothetical X-Coin, Alice can pay Carol without understanding the X-Coin consensus rules.


If all transactions using Bitcoin were conducted inside a network of micropayment channels, to enable 7 billion people to make two channels per year with unlimited transactions inside the channel, it would require 133 MB blocks. Current generation desktop computers will be able to run a full node with old blocks pruned out on 2TB of storage.


Your email address will not be published. Required fields are marked *