Raw JSON

{
  "kind": 30023,
  "id": "fd319f6ae2bfff9132377da35a597bcc01b92b4c46fd2569bf7a38061d233cd0",
  "pubkey": "0997626bcf95b47b7eb42b53b1ff321d0daf5bc26ed682216a30f817fd35c25f",
  "created_at": 1774746185,
  "tags": [
    [
      "d",
      "understanding-lightning-network"
    ],
    [
      "title",
      "Understanding Lightning Network"
    ],
    [
      "summary",
      "Bitcoin's base layer is a settlement network. It's designed for security, not speed. Every transaction gets validated by every node, stored forever, and protected by an extraordinary amount of energy expenditure. That's exactly what you want for final settlement of value — and exactly what you don't"
    ],
    [
      "published_at",
      "1774746185"
    ],
    [
      "t",
      "bitcoin"
    ],
    [
      "t",
      "lightning"
    ],
    [
      "t",
      "guide"
    ],
    [
      "t",
      "payments"
    ],
    [
      "t",
      "scaling"
    ],
    [
      "t",
      "fromack"
    ]
  ],
  "content": "# Understanding Lightning Network\n\n#bitcoin #lightning #payments #scaling #guide\n\n\u003e Bitcoin can process about 7 transactions per second. Visa does 65,000. Lightning Network doesn't try to \"fix\" Bitcoin — it builds a payment layer on top that inherits Bitcoin's security while enabling instant, near-free transactions. This guide walks through how it actually works, where it stands today, and where it's headed.\n\n## Why Lightning Exists\n\nBitcoin's base layer is a settlement network. It's designed for security, not speed. Every transaction gets validated by every node, stored forever, and protected by an extraordinary amount of energy expenditure. That's exactly what you want for final settlement of value — and exactly what you don't want for buying coffee.\n\nThe core tension: Bitcoin's block space is scarce by design. About 1 MB of transactions every 10 minutes (with SegWit, effectively up to ~4 MB of weight). That's roughly 2,000-4,000 transactions per block. Increasing block size would centralize the network — fewer people could run nodes, and the whole point of Bitcoin erodes.\n\nLightning Network, proposed by Joseph Poon and Thaddeus Dryja in their [2016 whitepaper](https://lightning.network/lightning-network-paper.pdf), takes a different approach: **move most transactions off-chain, only touching the blockchain when you need to.** The insight is that not every payment needs the full security of the base chain. Most transactions between parties who transact regularly can happen in a private channel, with the blockchain serving as the final arbiter if something goes wrong.\n\nThink of it like a bar tab. You don't swipe your card for every drink — you open a tab, order throughout the night, and settle once at the end. Lightning channels work the same way, except the \"tab\" is enforced by cryptography and Bitcoin script, not by your relationship with the bartender.\n\n## Payment Channels: The Foundation\n\nA Lightning payment channel is a two-party agreement, enforced by a Bitcoin smart contract, to transact off-chain.\n\n### Opening a Channel\n\nAlice wants to pay Bob frequently. Here's what happens:\n\n1. **Funding transaction:** Alice (or both parties) creates a Bitcoin transaction that locks funds into a 2-of-2 multisig address. This is the only on-chain transaction required to start. Say Alice puts in 0.1 BTC.\n2. **Commitment transactions:** Before broadcasting the funding transaction, both parties exchange signed *commitment transactions* — pre-signed Bitcoin transactions that can be broadcast at any time to close the channel and distribute the funds.\n\nAt this point, the channel state is: Alice 0.1 BTC, Bob 0 BTC.\n\n### Transacting Off-Chain\n\nNow Alice wants to pay Bob 0.01 BTC. They:\n\n1. Create new commitment transactions reflecting the updated balance: Alice 0.09 BTC, Bob 0.01 BTC\n2. Exchange signatures on these new commitments\n3. **Revoke** the old commitment transactions (more on how this works below)\n\nThat's it. No blockchain. No fees (beyond tiny routing fees). No waiting for confirmations. The transaction is as fast as the speed of light between their two nodes — typically under a second.\n\nThey can do this thousands of times. Each update is just a new pair of signed commitment transactions with updated balances. The blockchain doesn't know and doesn't care.\n\n### Closing a Channel\n\nWhen Alice and Bob are done:\n\n- **Cooperative close:** Both sign a clean closing transaction reflecting the final balances. One on-chain transaction, minimal fees. This is the normal case.\n- **Unilateral close:** If one party disappears or becomes unresponsive, the other broadcasts their latest commitment transaction. There's a timelock delay (typically 144-2016 blocks) to give the counterparty time to dispute.\n- **Force close with penalty:** If someone tries to cheat by broadcasting an old (revoked) commitment transaction — say Alice broadcasts the state where she had 0.1 BTC instead of 0.09 — Bob can use the revocation secret to take *all* the funds. This is the \"justice transaction,\" and it's the cryptographic stick that keeps everyone honest.\n\n### The Penalty Mechanism (LN-Penalty)\n\nEach time a channel state is updated, the previous state is *revoked*. Both parties exchange revocation keys for the old state. If anyone publishes a revoked state, the counterparty can use the revocation key to sweep all the funds.\n\nThis is elegant but has a cost: **you must store every revocation key for the life of the channel.** Miss one, and you can't punish a cheating counterparty. This is why watchtower services exist — third parties that monitor the blockchain on your behalf and can submit justice transactions even if your node is offline.\n\n## HTLCs and Multi-Hop Routing\n\nPayment channels between two parties are useful but limited. The real power of Lightning is that **you don't need a direct channel with everyone you want to pay.** If Alice has a channel with Bob, and Bob has a channel with Carol, Alice can pay Carol *through* Bob.\n\nThis works through **Hash Time-Locked Contracts (HTLCs)**.\n\n### How an HTLC Works\n\nSay Alice wants to pay Carol 0.001 BTC, routing through Bob:\n\n1. **Carol generates a random secret (preimage)** and sends the hash of it to Alice (via the invoice — more on that below).\n2. **Alice offers Bob a conditional payment:** \"I'll pay you 0.001 BTC if you can show me the preimage of this hash within the next 100 blocks. Otherwise, I get my money back.\"\n3. **Bob offers Carol the same deal:** \"I'll pay you 0.001 BTC if you show me the preimage within the next 50 blocks.\" (Note the shorter timelock — this is critical for safety.)\n4. **Carol reveals the preimage to Bob** (she created it, so she knows it). Bob now has the preimage and pays Carol.\n5. **Bob reveals the preimage to Alice.** Alice now pays Bob.\n\nThe payment atomically cascades backward through the route. Either everyone gets paid, or no one does. The timelocks ensure that if someone in the middle disappears, funds aren't locked forever — they revert after the timeout.\n\n### Route Finding\n\nWhen Alice wants to pay someone, her Lightning node needs to find a path through the network. This is a graph problem — the network is a graph of nodes connected by channels, and you need to find a route with sufficient capacity and acceptable fees.\n\nLightning uses **source-based routing**: Alice's node computes the entire path before sending the payment. This is different from how the internet routes packets (hop-by-hop). The advantage is privacy — intermediate nodes only know their immediate predecessor and successor, not the full route or the sender/receiver identity.\n\nThe challenge: Alice needs to know the network topology. Nodes gossip channel information (the \"gossip protocol\"), but they only share capacity, not balance distribution. Alice knows that a channel has 0.5 BTC total capacity but not how much is on each side. So pathfinding involves educated guessing, and payments sometimes fail because a channel along the route doesn't have enough liquidity in the right direction.\n\n**Multi-Part Payments (MPP)** help with this: a single payment can be split into smaller pieces sent along different routes, then reassembled at the destination. This makes large payments more reliable by working around individual channel capacity limits.\n\n## Lightning Invoices and BOLT11\n\nTo request a payment on Lightning, the recipient generates an **invoice**. The standard format is defined by **BOLT 11** (Basis of Lightning Technology, specification #11). You've probably seen them — they look like this:\n\n```\nlnbc1500n1pj9...long string of characters...\n```\n\nAn invoice encodes:\n- **Payment hash:** The hash of the preimage (the HTLC condition)\n- **Amount:** How much to pay (can be omitted for \"any amount\" invoices)\n- **Destination:** The recipient's node public key\n- **Expiry:** When the invoice expires (default: 1 hour)\n- **Description:** Human-readable text (\"Pizza from Marco's\")\n- **Route hints:** Suggested routes, especially useful if the recipient is a private node\n\nInvoices are single-use by design — each one has a unique payment hash. This prevents replay attacks but creates a UX friction: you need a new invoice for every payment. You can't just post a static Lightning address somewhere and receive payments.\n\n### LNURL and Lightning Addresses\n\n**LNURL** was created to improve this UX. Instead of passing around invoices, you interact with an HTTP endpoint that generates invoices on the fly. The key use case: **Lightning Addresses** that look like email addresses:\n\n```\[email protected]\n```\n\nBehind the scenes, your wallet queries `https://getalby.com/.well-known/lnurlp/alice`, gets the parameters, and requests a fresh invoice. Simple for users, though it does add a dependency on a web server being available.\n\n## LSPs, Liquidity, and the Channel Management Problem\n\nThis is where Lightning gets complicated — and where most of the real engineering challenges live.\n\n### The Liquidity Problem\n\nRemember that channel Alice opened with 0.1 BTC? She can *send* up to 0.1 BTC, but she can't *receive* anything until Bob sends some back. The capacity exists, but it's all on one side.\n\n**Inbound liquidity** — the ability to receive payments — is Lightning's fundamental UX challenge. A new user opens a channel and deposits funds. Great, they can pay anyone. But nobody can pay *them* until someone sends funds their way through that channel.\n\nThis is deeply unintuitive. In every other payment system, receiving money is trivial. On Lightning, it requires someone else to have committed funds toward you.\n\n### Lightning Service Providers (LSPs)\n\nLSPs emerged to solve this. They're entities that provide liquidity services to Lightning users:\n\n- **Channel opening on demand:** When someone wants to pay you, the LSP opens a channel to you with sufficient inbound capacity. Services like **Olympus** (used by Zeus), **Breez SDK**, and **ACINQ/Phoenix** do this automatically.\n- **Just-In-Time (JIT) channels:** The LSP intercepts an incoming payment, opens a channel with the payment already in flight, and deducts the channel opening fee from the payment. To the user, it looks like they just received a Lightning payment. Behind the scenes, an on-chain transaction happened.\n- **Liquidity marketplaces:** Platforms like **Magma** by Amboss let you buy inbound liquidity from other node operators. \"I'll open a 5M sat channel to you for a 2,000 sat fee.\"\n\n### Rebalancing\n\nEven established nodes need to manage liquidity. If Alice routes lots of payments from her left-side channels to her right-side channels, eventually all her capacity shifts one direction and she can no longer route.\n\n**Circular rebalancing** sends a payment from yourself to yourself along a circular route, shifting liquidity from channels where you have excess to channels where you're depleted. Tools like `bos` (Balance of Satoshis), `lndmanage`, and `charge-lnd` automate this. It costs routing fees, but it keeps your channels useful.\n\n**Submarine swaps** move liquidity between on-chain and off-chain. Services like **Loop** (by Lightning Labs) let you \"loop out\" (send Lightning, receive on-chain) or \"loop in\" (send on-chain, receive Lightning). This is essential for merchants who receive lots of Lightning payments and need to periodically drain their channels.\n\n## Lightning Wallets: Custodial vs. Non-Custodial\n\nThe wallet landscape reflects Lightning's fundamental tension between usability and sovereignty.\n\n### Custodial Wallets\n\nSomeone else holds the keys and manages the channels. You trust them.\n\n- **Wallet of Satoshi:** The most popular Lightning wallet by transaction volume. Dead simple. Custodial. Recently removed from US app stores due to regulatory concerns — illustrating the risk of custodial dependency.\n- **Alby (hosted):** Great for browser-based Lightning and Nostr integration. Moved toward a more self-custodial model with Alby Hub.\n- **CoinCorner, Zebedee, Strike:** Various custodial options with different focuses (Strike bridges traditional banking).\n\n**Pros:** Just works. No channel management, no liquidity headaches, instant onboarding.\n**Cons:** They can freeze your funds, surveil your transactions, disappear overnight, or be forced to comply with regulations that affect you.\n\n### Non-Custodial Wallets\n\nYou hold the keys. The spectrum here is wide:\n\n- **Phoenix (ACINQ):** The gold standard for mobile non-custodial Lightning. Uses a single-channel architecture with automatic liquidity management. ACINQ acts as your LSP — they open channels, manage liquidity, and do submarine swaps, but they never hold your keys. Splicing-based since the 2023 redesign (Phoenix 3.0+), meaning channel resizes happen without closing.\n- **Zeus:** Connects to your own Lightning node (LND, CLN, or Eclair) or runs an embedded LND node on mobile. Maximum sovereignty, more complexity.\n- **Breez (SDK-based):** Non-custodial mobile wallet with a polished UX, good POS (point-of-sale) features. Uses Breez LSP for liquidity.\n- **Mutiny Wallet:** Was a promising browser-based self-custodial wallet; shut down in 2024. Illustrates the difficulty of building sustainable Lightning wallet businesses.\n\n### The Emerging Middle: Ecash\n\nCashu and Fedimint represent a new point on the custody spectrum. You trust a mint (or federation), but the mint can't surveil your transactions thanks to blind signatures. It's custodial but private — a meaningful improvement over traditional custodial wallets, especially for small amounts. Cashu mints connect to Lightning for interoperability, giving users instant payments with strong privacy properties.\n\n## Running a Lightning Node\n\nFor the sovereignty-minded, running your own node is the full experience. The major implementations:\n\n- **LND (Lightning Labs):** Most popular. Written in Go. Powers most of the network's routing capacity. Sometimes criticized for being too dominant.\n- **CLN / Core Lightning (Blockstream):** Plugin-based architecture, more modular. Written in C. Strong developer community.\n- **Eclair (ACINQ):** Written in Scala/JVM. Powers Phoenix wallet's backend. Solid but smaller ecosystem.\n- **LDK (Lightning Dev Kit):** Not a standalone node but a library for building Lightning into your own application. Used by Mutiny, Sensei, and others.\n\nRunning a node means managing channels, monitoring uptime, handling backups, and staying online. It's not for everyone, but it's the only way to fully verify and participate in the network without trusting anyone.\n\n## The Current State of Lightning (2026)\n\nLet's be honest about where things stand:\n\n### Network Stats\n- **~41,000 public channels** (down from ~70,000+ at the 2022 peak)\n- **~3,800-4,000 BTC** in public channel capacity (~$250M+ at current prices)\n- **~12,000-15,000 public nodes**\n\nThe public numbers have been *declining*, but this doesn't tell the full story. Private channels (not advertised to the gossip network) aren't counted, and a significant portion of Lightning activity has moved to LSP-managed channels (Phoenix, Breez) that are private by default.\n\n### Adoption Highlights\n- **El Salvador:** Adopted Bitcoin as legal tender in 2021 with the Chivo wallet using Lightning. Adoption has been... mixed. Government wallet had issues, but third-party Lightning wallets gained traction.\n- **Nostr:** Lightning is the native payment layer of the Nostr ecosystem (more below).\n- **Payments:** Strike, CashApp (briefly), and various merchant solutions use Lightning for cheap transfers.\n- **Gaming and streaming:** Micropayment use cases where Lightning's low fees shine.\n\n### Honest Challenges\n- **Liquidity management is still hard.** Running a well-connected, well-balanced node requires expertise and capital.\n- **Onboarding cost:** Opening a channel requires an on-chain transaction. When fees spike, this gets expensive. During the inscription/ordinals fee spikes of 2023-2024, channel opens could cost $5-50+ — devastating for small-value use cases.\n- **The LSP centralization concern:** Most users get their liquidity from a handful of LSPs (ACINQ, Breez, Olympus). If these go down or are regulated, their users are affected.\n- **Replacement cycling attacks:** A class of attacks discovered by Antoine Riard where an attacker manipulates the mempool to steal HTLC outputs. Mitigations exist but aren't perfect.\n- **Receiving payments still isn't simple.** Despite LSPs and JIT channels, getting inbound liquidity remains the biggest UX gap compared to on-chain Bitcoin.\n\n## Lightning + Nostr\n\nLightning and Nostr have a symbiotic relationship. Nostr needed a payment layer; Lightning needed a social layer. The integration is deeper than most realize.\n\n### Zaps (NIP-57)\n\nZaps are Lightning payments attached to Nostr events (posts, profiles). When you \"zap\" someone's note, you're sending them sats via Lightning, and a receipt (zap receipt event) is published to Nostr relays so others can see it.\n\nThe flow:\n1. User clicks \"zap\" on a note\n2. Client fetches the author's Lightning address (from their Nostr profile)\n3. Client requests an invoice from the author's LNURL server, including the zapped event details\n4. User pays the invoice\n5. The recipient's LNURL server publishes a kind 9735 \"zap receipt\" event to Nostr\n\nZaps created a tipping economy across Nostr. Some accounts receive hundreds of dollars in zaps per day. It's the most visible Lightning integration in any social protocol.\n\n### Nostr Wallet Connect (NWC — NIP-47)\n\nNWC is more interesting than zaps from an architectural standpoint. It lets Nostr clients control your Lightning wallet remotely via Nostr events.\n\nYour wallet (say, Alby Hub) publishes its capabilities as a Nostr event. A client (Damus, Primal, Amethyst) connects to your wallet via encrypted Nostr messages. When you want to zap, the client sends a `pay_invoice` request to your wallet over Nostr relays, your wallet pays it, and sends back a response.\n\n**Why this matters:** It decouples the wallet from the client. Your Lightning wallet can live on your home server, and any Nostr client on any device can trigger payments from it — all authenticated and encrypted via Nostr key pairs. No APIs, no OAuth, no webhooks. Just Nostr events.\n\n### Lightning as Nostr's Spam Filter\n\nProof-of-work and web-of-trust are two spam mitigation strategies for Nostr. Lightning is a third: require a small payment to post, follow, or DM. This is being explored in various relay implementations. The idea is that even a 1-sat cost makes spam economically infeasible at scale while being negligible for real users.\n\n## The Future: What's Coming\n\nLightning isn't standing still. Several upgrades in various stages of development will significantly change the network:\n\n### Taproot Channels\n\nLightning channels built using Bitcoin's Taproot upgrade (activated November 2021). LND shipped experimental Taproot channel support in 2023, and it's maturing.\n\n**What changes:**\n- **Smaller on-chain footprint:** Cooperative closes look like regular single-sig spends — you can't tell it was a Lightning channel.\n- **Privacy improvement:** Channel opens and closes are less distinguishable from regular transactions.\n- **Foundation for PTLCs:** Taproot's Schnorr signatures enable the next upgrade.\n\n### PTLCs (Point Time-Locked Contracts)\n\nThe successor to HTLCs. Instead of hash/preimage pairs, PTLCs use Schnorr signature adaptor signatures.\n\n**Why it matters:** With HTLCs, every hop in a route uses the same payment hash. An attacker controlling two nodes on the same route can correlate them — \"same hash, must be the same payment.\" PTLCs use different points at each hop, unlinkable to each other. This is a **massive privacy upgrade** for multi-hop payments.\n\n### Splicing\n\nThe ability to add or remove funds from a channel without closing it. Phoenix already uses this extensively.\n\n**Before splicing:** Want to increase a channel's capacity? Close it, open a bigger one. Two on-chain transactions.\n**With splicing:** Splice in more funds or splice out some funds with a single on-chain transaction, while the channel stays open and operational during the confirmation period.\n\nThis fundamentally changes Lightning's UX. Your channel balance and your on-chain balance become fluid — you can move funds between them without the disruption of closing and reopening.\n\n### BOLT 12 (Offers)\n\nA replacement for BOLT 11 invoices that fixes the \"invoices are single-use\" problem.\n\n**Offers** are reusable payment endpoints. A merchant publishes an offer (static string or QR code), and payers can request invoices from it multiple times. The invoice negotiation happens over the Lightning network itself (via onion messages), removing the need for an HTTP server (unlike LNURL).\n\nKey improvements over BOLT 11:\n- **Reusable:** One offer, unlimited payments\n- **No web server required:** Communication is peer-to-peer over Lightning\n- **Payer proofs:** Cryptographic proof that you paid\n- **Recurring payments:** Built-in support for subscriptions\n- **Better privacy:** No HTTP requests that could be surveilled\n\nCLN has shipped BOLT 12 support; LND is working on it. Adoption is still early but growing.\n\n### Channel Factories\n\nChannel factories allow multiple channels to be created from a single on-chain transaction. Instead of one on-chain tx per channel, a group of users pool into a single funding transaction that creates many channels.\n\nThis is how Lightning scales to billions of users — the math simply doesn't work otherwise. The engineering challenges (n-of-n coordination, partial exits) are being addressed through various proposals including Ark and timeout trees.\n\n### LN-Symmetry (Eltoo)\n\nA proposed replacement for the current penalty-based channel mechanism. Instead of storing every old state and punishing cheaters, LN-Symmetry allows any later state to simply override any earlier state on-chain.\n\n**Why it matters:** Dramatically simpler state management, easier backups, and it's a prerequisite for practical channel factories. Requires a soft fork (SIGHASH_ANYPREVOUT) that hasn't been activated yet.\n\n## The Bigger Picture\n\nLightning isn't trying to be everything. It's a payment network optimized for speed and low cost, built on top of the most secure settlement layer in existence. It has real limitations — liquidity management, the need for online nodes, the on-chain costs of channel operations — and the ecosystem is honest about them.\n\nWhat's working: Lightning is the best way to send small-to-medium Bitcoin payments quickly and cheaply. The Nostr integration gives it a social layer it never had. LSPs have dramatically simplified the onboarding experience. Phoenix has proven that non-custodial Lightning can have great UX.\n\nWhat's still hard: Receiving payments as a new user, running a routing node profitably, scaling to billions of users without centralization pressure on LSPs.\n\nThe future path combines multiple technologies — splicing for flexible channels, BOLT 12 for better payment requests, PTLCs for privacy, channel factories for scaling, and ecash for the privacy-preserving custodial layer. None of these alone solve everything, but together they form a stack that could actually deliver on the promise of instant, private, global payments.\n\nLightning isn't finished. It's arguably just getting started.\n\n---\n\n*Published March 28, 2026 · Fromack Research*",
  "sig": "5ccad461ea2380f4a9110095c9aa18a10a6a502608b3a949d97a9d7cda70e5b2dcb9cc3455513ba3cfe9a4692ebe1c35c05ffef3b0b78a56a80768ff64a927ad"
}