On 9 November 2026 a Bitcoin user could get a transaction into the next block for 1 satoshi per virtual byte, the rate mempool.space recommended that morning for every speed, from fastest to economy. The same day, the public map of the Lightning Network showed about 3,218 BTC locked in some 28,050 payment channels between about 15,030 nodes, and LNbits, a popular piece of software that runs on top of Lightning nodes, was telling every operator to switch their servers off after a wave of attacks. Both facts describe the same system. Lightning makes bitcoin payments fast and cheap, and it does so by asking someone, you or a company you trust, to keep a piece of online software running and patched.
This lesson explains what happens inside that software. It follows on from our lesson on SegWit and Taproot, and the link is direct: Lightning channels depend on transactions that are signed before the transactions they spend are confirmed, which was unsafe until SegWit fixed transaction malleability in 2017, and Taproot later gave channels a cheaper and more private on-chain footprint. If you need the short version first, our guide to layer 1 and layer 2 networks has a section on Lightning as Bitcoin’s layer 2.
What is the Lightning Network? Payment channels on top of Bitcoin
The Lightning Network is a network of two-party payment channels built on Bitcoin. Two people lock bitcoin in a shared output on the blockchain with one transaction. From then on they move the balance between them by exchanging signed transactions that they keep and do not broadcast, as often as they like and at almost no cost. When they are done, one final transaction settles the result on chain. Because channels connect to each other, a payment can cross several of them to reach someone you never opened a channel with, and the intermediaries cannot steal it on the way. Lightning has no coin of its own: the unit is bitcoin, counted in satoshis or in thousandths of a satoshi, and any “Lightning token” sold online has nothing to do with the protocol.
The idea was written down by Joseph Poon and Thaddeus Dryja. Their paper, dated 14 January 2016 in its draft version 0.5.9.2, starts from a blunt diagnosis: “Currently, Bitcoin supports less than 7 transactions per second with a 1 megabyte block limit,” set against the 47,000 transactions per second Visa handled at its 2013 holiday peak (Poon and Dryja, The Bitcoin Lightning Network). Their answer was not a bigger chain but fewer trips to it. Bitcoin’s blockchain works like a post office that stamps every letter for the whole world; Lightning is the till next to it, where two parties keep a running tab and only post the total.
It took two more years to ship. On 15 March 2018 Lightning Labs released lnd 0.4-beta, which it described as “the first release of lnd that has the option to run on Bitcoin’s mainnet”, while recommending that users “experiment with only small amounts” (Lightning Labs, lnd beta announcement). That gap matters: SegWit, activated in August 2017, removed the risk that a third party could change a transaction’s identifier before confirmation, which would have broken the chain of pre-signed transactions a channel relies on.
A Lightning channel is a 2-of-2 output and a pile of unbroadcast transactions
Everything in a channel uses tools you met in our lesson on Bitcoin transactions and scripts: multisignature outputs, relative timelocks (CSV) and absolute timelocks (CLTV). Lightning adds no new opcode. It combines those pieces in a precise order, written down in the BOLT specifications.
Opening: one funding transaction on the blockchain
Alice and Bob agree to open a channel. Alice builds a funding transaction that pays, say, 1,000,000 sats into a pay-to-witness-script-hash output locked by a 2-of-2 script: 2 <pubkey1> <pubkey2> 2 OP_CHECKMULTISIG, with the two keys sorted so both sides build exactly the same script (BOLT 3, transactions). Spending that output from then on needs both signatures.
Before Alice broadcasts the funding transaction, Bob signs her first commitment transaction, which spends the funding output and gives Alice her 1,000,000 sats back. That is the safety net: if Bob vanished right after the funding confirmed, Alice could still recover her money. Only then does the funding transaction go to the network, and the channel becomes usable once it has the number of confirmations both sides agreed.
A few rules from the peer protocol (BOLT 2) shape what a channel can hold. Unless both nodes support the large-channel option, a channel must be smaller than 224 satoshis, 16,777,216 sats or about 0.168 BTC; the spec calls that cap a temporary limit from the days when implementations were not considered stable. Each side keeps a reserve, with 1 percent of the channel suggested, so that it always has something to lose if it cheats. And each side accepts at most 483 pending payments in flight at once.
Cost on chain: in November 2026 the opening is cheap. At 1 sat/vB, a funding transaction of a couple of hundred virtual bytes costs a couple of hundred sats (an example, not a quote: fees move, and our lesson on the mempool and transaction fees explains why they rise when blocks fill up). A channel opened during a fee spike can cost far more, and so can its closing.
Updating: new commitments, old ones revoked
Each payment inside the channel replaces the pair of commitment transactions with a new pair. Alice holds one version signed by Bob, Bob holds a mirror version signed by Alice, and neither is broadcast. On Alice’s copy, Bob’s share goes straight to Bob, while Alice’s own share sits in a to_local output with two ways out: Alice can take it after a delay of to_self_delay blocks, enforced with CSV, or Bob can take it at once with a revocation key.
That revocation key is the clever part. Bob cannot use it while the commitment is current, because he lacks a secret only Alice knows. When the channel moves to a new state, Alice hands Bob the per-commitment secret of the old one, and from that moment Bob can derive the key that unlocks the old to_local output. Revoking a state therefore means giving your partner the power to punish you if you ever publish it.
If Alice later broadcasts an outdated commitment that paid her more, Bob has the whole to_self_delay window to notice it and sweep Alice’s output with the revocation key: the cheater loses her entire balance in the channel, not just the amount she tried to take. The on-chain handling spec even warns that grouping every revoked output into a single penalty transaction is unsafe, because the cheater can block it; each output should be swept on its own (BOLT 5). The penalty only works if someone is watching the chain during that window, which is where watchtowers come in later in this lesson.
Closing: cooperative or forced
A cooperative close is the normal ending. Both nodes agree on a final transaction that pays each side its balance straight from the funding output, with no delay and a fee they negotiate. On chain it looks like one ordinary transaction.
A force close happens when one side is offline, unresponsive or misbehaving. The other side broadcasts its latest commitment. The party that closed waits out its own to_self_delay before getting its money, and any payments still in flight are settled through extra on-chain transactions. Commitments are signed in advance, so their fee can be too low when the time comes. Since the anchor-output format entered the spec in August 2020, each commitment carries two small anchor outputs of 330 sats, one per side; each owner can spend its anchor in a child transaction that pays a higher fee for both (CPFP), and after 16 blocks anyone may sweep a leftover anchor. In May 2026 the specification added a zero-fee-commitment variant (feature bits 40/41), built on version 3 transactions, in which the commitment pays no fee at all and a child pays everything. Force closes are where Lightning meets the fee market, and they are the expensive way out.
How a Lightning payment crosses two strangers, step by step
Most payments do not travel over a direct channel. Alice wants to pay Carol, she has a channel with Bob, and Bob has one with Carol. Bob is a stranger to both, and the protocol must make sure he can neither keep the money nor lose his own. The tool is the hash time-locked contract (HTLC): a conditional payment that the receiver can claim by revealing a secret, and that returns to the sender if the secret does not appear before a block height.
The table follows one payment with example numbers. The fee uses the formula of the gossip spec, base fee plus a proportional rate in millionths, with a base of 200 millisatoshis and a rate of 100 parts per million, close to the medians of the public graph on 9 November 2026 (200 msat and 103 ppm per the mempool.emzy.de explorer, the rate rounded here). The heights start from block 975,158, the chain tip that morning. Everything else is illustrative.
| Step | Who acts | What happens (example figures) |
|---|---|---|
| 1 | Carol | Draws a random secret, the preimage, and puts its SHA-256 hash in an invoice for 100,000 sats. The invoice expires after 3,600 seconds by default and asks for at least 18 blocks of margin on the last hop (BOLT 11 defaults). |
| 2 | Alice | Finds a route through Bob from the public map of channels and builds an onion: one encrypted layer per hop, so Bob learns only where the payment came from and where to send it next. |
| 3 | Alice to Bob | Adds an HTLC of 100,010.2 sats to her channel with Bob (100,000 plus Bob’s fee: 0.2 sat base plus 10 sats proportional). It expires at block 975,216. Both sign new commitments. |
| 4 | Bob to Carol | Peels his layer, checks the fee and the expiry, then adds an HTLC of 100,000 sats to his channel with Carol, expiring earlier, at block 975,176. |
| 5 | Carol | Reveals the preimage to Bob to claim her 100,000 sats. The channel moves to a new state. |
| 6 | Bob | Uses the same preimage to claim 100,010.2 sats from Alice. He keeps 10.2 sats. Nothing has touched the blockchain. |
The two expiries are the heart of the design. Bob’s outgoing HTLC to Carol expires 40 blocks before his incoming HTLC from Alice; that gap is his cltv_expiry_delta, which he advertises in the channel_update messages he gossips for that channel. If Carol claims at the last moment, Bob still has about 40 blocks, roughly six and a half hours, to use her preimage against Alice. Each hop needs a margin like this, so a route of five hops locks the sender’s money for longer than a route of two if something goes wrong.
If Carol never reveals the secret, the HTLCs simply expire or are cancelled back hop by hop, and everyone returns to the previous balance. If Bob disappears while holding Alice’s HTLC, Alice can force-close and recover the funds on chain after expiry. The preimage doubles as a receipt: Alice can show that Carol was paid, because only Carol knew the secret.
The onion itself is a fixed 1,366-byte packet: one version byte, a 33-byte public key, 1,300 bytes of hop data and a 32-byte check (BOLT 4, onion routing). Every packet has the same size whatever the route length, so the packet itself does not tell a hop how far it sits from the sender or the receiver.
Routing, liquidity and privacy: the network behind the payment
Why Lightning payments sometimes fail
Nodes tell each other about channels through gossip messages: who is connected to whom, the channel capacity, the fees and the timelock delta. Gossip does not say how the capacity is split between the two sides, because that changes with every payment and publishing it would reveal who paid whom. So Alice knows a channel between Bob and Carol holds 2 million sats in total, but not whether Bob’s side has the 100,000 she needs. Her wallet guesses, tries, and on failure tries another route.
Researchers have worked on that guess for years. René Pickhardt and Stefan Richter showed in 2021 that choosing routes by lowest fee ignores the unknown balances; modelling the probability of success and splitting a payment into several parts could raise the size of payments that go through reliably “by several orders of magnitude”, they wrote (Pickhardt and Richter, arXiv 2107.05322). Splitting a payment over several paths, called multi-part payments, is now part of the spec. Published success rates come from one wallet, one node operator or one research team at a time, so a single “Lightning failure rate” quoted online describes that sample, not the network.
Liquidity: inbound, outbound and the role of service providers
A channel’s balance has a direction. Alice can send only what sits on her side, minus her reserve: that is her outbound liquidity. To receive, she needs coins on her partner’s side of some channel, her inbound liquidity. A new user who opens a channel with 1,000,000 sats can pay but cannot receive a single sat until money flows back. A shop has the opposite problem.
Lightning service providers (LSPs) exist to fix this. Many mobile wallets open a channel to the user from the provider’s side on the first payment, or sell inbound capacity for a fee. Splicing lets a channel grow or shrink without closing it: the funding output is spent into a new one with more or fewer coins while payments keep flowing. The splicing specification (feature bits 62/63) was merged into the BOLT repository on 23 March 2026 (BOLT pull request 1160), and support varies by implementation: Lightning Labs wrote in June 2026 that its new Taproot channels “lay the groundwork for splicing”, so LND 0.21 did not ship it.
Privacy: onions, blinded paths and what the channel map reveals
Onion routing hides the full route from intermediaries, and the payment never appears on the blockchain. That is a real gain over on-chain payments, where every amount and address is public. It has limits. A public channel announces its funding output, so anyone can link a node to an on-chain transaction and its capacity. A node sitting right next to a receiver can guess a lot. Blinded paths, used by BOLT 12 offers, let the receiver hide the last hops and even its node ID from the payer. Private, unannounced channels are not shown on the map at all, which helps their owners and, as the figures below show, makes the network harder to measure.
BOLT specifications, four implementations and the 2026 upgrades
Lightning is defined by the Basis of Lightning Technology documents, the BOLTs, kept in a public repository whose readme says they are still being drafted (lightning/bolts on GitHub). They run from BOLT 1 (base messaging) through BOLT 12 (offers). There is no BOLT 6 in the repository. Any node that follows them can open channels with any other, whatever software each runs.
Four implementations carry most of the network. LND, by Lightning Labs, written in Go, is the software of most public nodes and ships inside node-in-a-box platforms such as Umbrel. Core Lightning, written in C, began at Blockstream. Eclair, written in Scala by the French company ACINQ, runs ACINQ’s large routing node; the same company’s Phoenix wallet uses lightning-kmp, a separate Kotlin implementation built for phones. LDK is a library that wallet makers build into their own apps rather than a ready-made node.
| Upgrade | What it changes | Status (date) |
|---|---|---|
| Anchor outputs | Two 330-sat outputs on each commitment so fees can be bumped at closing time | In the spec (BOLT 3); feature bits 22/23 |
| Simple Taproot channels | Funding output becomes a Taproot output that looks like any single-key spend when closed cooperatively | Spec merged 4 May 2026 (PR 995); called production-ready on mainnet in LND 0.21, 11 June 2026 |
| Splicing | Add or remove funds without closing the channel | Spec merged 23 March 2026 (PR 1160); not in LND 0.21 |
| BOLT 12 offers | Reusable payment codes; fresh invoice for each payment, requested over onion messages | Spec merged 24 September 2024 (PR 798); payer proofs added July 2026 |
| Zero-fee commitments | Commitment pays no fee; a child transaction pays it through a shared anchor | In BOLT 3; feature bits 40/41 |
Taproot channels are the direct sequel to the previous lesson. The 2-of-2 multisig script disappears from the chain: the two parties combine their keys into one, so a cooperative close looks like any single-signature Taproot spend and costs less space. Lightning Labs’ LND 0.21 post says simple Taproot channels “graduate” from experimental status, using the final scripts behind feature bits 80/81 (Lightning Labs, LND 0.21 launch). Support in the other implementations differs and changes from release to release.
BOLT 12 changes how you ask for money. A BOLT 11 invoice, the long string starting with lnbc that most wallets show today, is single-use and expires after an hour by default. A BOLT 12 offer, starting with lno, can be printed on a donation page or a till and reused: the payer’s wallet sends an invoice request over onion messages and receives a fresh invoice, by default valid for 7,200 seconds (BOLT 12, offer encoding). It needs onion-message relay along the path, which LND 0.21 now limits by default to peers that have a channel with the node.
Watchtowers answer the online problem. A watchtower is a server that receives from your node what it needs to punish a cheating partner, and broadcasts the penalty transaction if that partner publishes a revoked state while you are offline. LND bundles both a tower and a tower client, which must be switched on in its configuration, and its documentation calls these towers altruistic: they get no compensation for the job (LND watchtower documentation). Mobile wallets often rely on their provider for the same job.
Lightning is also meant to carry more than bitcoin. Lightning Labs and Tether announced on 30 January 2025 that USDT would be issued on Bitcoin and move over Lightning through the Taproot Assets protocol (Lightning Labs announcement). That is a separate protocol from Taproot channels, and the announcement is not a measure of use.
Lightning Network figures in November 2026: public capacity down 45 percent from its peak
The figures below come from the Lightning explorer of mempool.emzy.de, a community instance of the mempool.space software run by the operator Emzy, whose daily statistics run to 9 November 2026. The Lightning statistics feed of mempool.space itself ends on 30 August 2026; its last reading is shown for comparison. The two instances crawl the network separately and do not see exactly the same graph: on 30 August, the one day both cover, Emzy’s instance counted 3,755.1 BTC in 32,569 channels and mempool.space 3,793.8 BTC in 32,665 channels, about 1 percent apart. Most of the gap between the August and November columns is therefore change in the network, with a small part due to the switch of source.
| Public graph | 28 Dec 2025 (1-year high) | 30 Aug 2026 (mempool.space) | 2 Nov 2026 | 9 Nov 2026 |
|---|---|---|---|---|
| Capacity (BTC) | 5,851.2 | 3,793.8 | 3,200.7 | 3,217.6 |
| Channels | 41,866 | 32,665 | 28,936 | 28,051 |
| Nodes | 17,409 | 16,235 | 15,905 | 15,030 |
| Median channel size (sats) | n/a | 2,040,000 | 2,000,000 | 2,154,895 |
| Median fee rate (ppm) | n/a | 100 | 100 | 103 |
Source: mempool.emzy.de Lightning statistics API (daily points for 28 December 2025, 2 and 9 November 2026), mempool.space Lightning statistics API (30 August 2026), both read on 9 November 2026. Our arithmetic: 3,217.6 BTC is 45 percent below the highest reading of the past year, and about 0.016 percent of the roughly 20 million bitcoin in existence. At the mempool.space price of 74,166 dollars at 09:50 UTC on 9 November 2026, it was worth about 239 million dollars.
Three warnings come with these numbers. They count public channels only: private channels opened by many mobile wallets do not appear on any explorer. Different trackers crawl different slices of the network and give different totals on the same day. And capacity is the stock of coins locked in channels, not the flow of payments: one channel can carry thousands of payments without its capacity changing. The series show how much capacity left the public graph since December 2025, not why: none of these trackers can say whether those coins went back on chain, into private channels or elsewhere.
The flow tells another story. River, a bitcoin financial-services company, estimated that Lightning carried about 1.17 billion dollars in about 5.22 million transactions in November 2025, with an average payment of 223 dollars against 118 a year earlier, as Bitcoin Magazine reported on 19 February 2026 (Bitcoin Magazine on River’s estimate). River builds that estimate from anonymised data of large node operators, which it says cover more than half of capacity, and extrapolates the rest. It is an estimate, not a count.
Is the Lightning Network decentralised? On 9 November 2026 the five largest public nodes by capacity, announced under the aliases Binance, bfx-lnd0, ACINQ, block-iad-1 and bfx-lnd1, held 1,395.7 BTC between them. That is at most about 43 percent of public capacity (our arithmetic; a channel between two of them counts at both ends, so the real share is somewhat lower). ACINQ’s node had the most channels, 1,760. Anyone can run a node, but much of the liquidity sits with exchanges and payment companies.
Who holds your keys: custodial, non-custodial and in between
Lightning wallets come in three kinds, and the difference decides who can lose your money. The general split between custodial and self-custody wallets is covered in our guide to crypto wallets; here is what it means on Lightning.
| Kind | Who holds the keys | What you manage | Main risk |
|---|---|---|---|
| Custodial wallet | The company | Nothing: an account balance | The company fails, freezes or leaves your country |
| Non-custodial wallet with an LSP | You, on your phone | A backup; the provider runs channels and liquidity for you | Losing the backup; provider downtime; fees for liquidity |
| Your own node | You | Channels, liquidity, backups, updates, uptime | Bugs, unpatched software, mistakes in force closes |
Two dated episodes show how regulation weighs on the first two kinds. On 24 November 2023 Wallet of Satoshi, a widely used custodial Lightning wallet, removed its app from US app stores and said it would no longer serve US customers; users could withdraw their funds, and the company gave no reason (The Block, 24 November 2023). On 26 April 2024 ACINQ said its non-custodial Phoenix wallet would leave US app stores on 3 May 2024, citing doubt over whether self-custodial wallet providers, Lightning service providers or even Lightning nodes could be treated as money services businesses (No BS Bitcoin, 26 April 2024).
The US rulebook behind that doubt is FinCEN’s guidance FIN-2019-G001 of 9 May 2019. It says that “hosted wallet providers are account-based money transmitters”, while a person using an unhosted wallet to buy goods or services for themselves is not one (FinCEN guidance, May 2019). The guidance does not mention Lightning. A custodial Lightning wallet fits its description of a hosted wallet; how it applies to LSPs and routing nodes is exactly the uncertainty ACINQ pointed to.
In the European Union, holding crypto-assets on behalf of clients is a service that needs authorisation under MiCA, and the transitional period ended on 1 July 2026 in France and Italy. A custodial Lightning wallet serving EU residents falls in that perimeter; a wallet whose keys stay on your device does not hold anything for you. Our MiCA guide explains how to check a provider in the ESMA register.
El Salvador ran the largest state experiment with everyday bitcoin payments, and its lesson is mostly about wallets and adoption. When the Bitcoin Law came into force in September 2021 the government handed out the equivalent of 30 dollars in bitcoin through its public e-wallet, Chivo. According to the IMF, surveys at the project’s peak found that only 20 percent of firms accepted bitcoin and 4.9 percent of sales were paid in it. Under the 40-month IMF arrangement of about 1.4 billion dollars approved on 26 February 2025, the law was amended to make acceptance by the private sector voluntary, taxes are paid only in dollars, and public participation in Chivo was to end by the end of July 2025 (IMF Country Report 25/58).
Where Lightning still hurts in 2026
Lightning works well for what it was built for: frequent, small to medium payments between parties that are online. Outside that zone the design shows its costs.
Someone must stay online. A channel partner who goes offline cannot receive, cannot forward, and cannot catch a cheating peer unless a watchtower does it. Mobile wallets hide this by delegating to their provider, which brings back a trusted party. Large payments are harder than small ones, because every hop on the route needs enough liquidity on the right side; splitting payments helps, but a few hundred dollars goes through more easily than tens of thousands.
The design also leans on the mempool. In October 2023 Bitcoin developer Antoine Riard disclosed “replacement cycling”, an attack in which a malicious peer uses fee replacement to push a node’s time-sensitive HTLC transaction out of miners’ mempools until a timelock expires, and then claims the funds (The Block, 23 October 2023). Eclair, LND and Core Lightning had already shipped mitigations, mainly rebroadcasting those transactions, and no attack using the method had been reported. Riard himself doubted that the patches would stop more advanced forms of the attack.
The sharpest pain in 2026 has been software. On 11 August Lightning Labs published ten LND advisories, three of them rated high; a preprint by Saurabh Kumar of Bitcoin Data Labs estimated that 550 public LND nodes, 14.9 percent of live LND nodes, were on an exposed release that day, and that 71 percent of that group were still exposed on 13 October. The share is of the exposed group, not of the network, and no theft linked to those flaws was reported (our report on unpatched LND nodes). In October, ACINQ shipped Eclair v0.14.4 so that web pages could no longer send commands to a node through its owner’s browser (our report on the Eclair patch).
Then November brought two warnings from the application layer. BTCPay Server asked operators on 1 November to stop their servers after reports that hot wallets had been swept; its founder Nicolas Dorier said the cases appeared to involve releases older than 2.4.2 (our report on the BTCPay Server alert). On 8 November LNbits told every operator to stop theirs; one operator reported losing 2,285,545 sats, and on the morning of 9 November no patched release had been published (our report on the LNbits shutdown). Neither project is the Lightning protocol: BTCPay is a payment processor and LNbits a wallet server that sit on top of nodes. For the person whose sats sit on those servers, the distinction changes little.
The common thread is that a Lightning node is a hot wallet that must stay online, connected and up to date. The same preprint found that LND nodes tend to upgrade when platforms such as Umbrel ship a new version rather than when an advisory appears. Running your own node, the subject of the next lesson in this path, gives you control of the keys and of the updates, along with the duty to apply them.
Paying with Lightning and the tax office
For tax purposes a Lightning payment is a bitcoin payment. Speed does not change its nature. In the United States the IRS treats digital assets as property, so paying for goods or services with bitcoin is a disposal: you owe tax on any gain between what the sats cost you and their dollar value when you spend them, as our guide to US crypto taxes explains. A coffee bought over Lightning is, legally, a small sale of bitcoin followed by a purchase, and the record keeping is yours, since self-custody wallets send no Form 1099-DA.
The United Kingdom treats spending crypto as a disposal for capital gains tax as well, as our guide to UK crypto tax sets out. In the EU, France and Italy also treat paying with crypto as a taxable disposal. France’s flat tax on 2026 gains is 31.4 percent, per the tax administration’s crypto page of 17 July 2026 (our French crypto tax guide). Italy taxes crypto gains realised from 1 January 2026 at 33 percent, up from 26 percent, according to the Agenzia delle Entrate brochure on the 2025 budget law (Agenzia delle Entrate). Lightning wallets rarely export clean histories with the value of each payment, so keep your own record from the start. None of this is tax advice.
