Case Study 1: The Lightning Network — Building Payment Channels with Bitcoin Script

Background

In 2015, Joseph Poon and Thaddeus Dryja published "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments," a paper that proposed a radical solution to Bitcoin's scalability challenge. At the time, Bitcoin's main chain could handle approximately 7 transactions per second. Visa processes roughly 65,000 per second at peak. The gap seemed insurmountable without either increasing block size (controversial and limited in its scaling potential) or moving the bulk of transactions off-chain.

Poon and Dryja's insight was that Bitcoin Script already contained every primitive needed to build a network of bidirectional payment channels that could route payments across multiple hops without trusting any intermediary. The key ingredients — 2-of-2 multi-sig, time locks (CLTV and CSV), hash locks, and conditional logic (OP_IF/OP_ELSE) — had been sitting in Bitcoin's scripting system since the early days, waiting to be assembled.

By 2024, the Lightning Network had grown to over 15,000 nodes, 60,000 channels, and a total capacity exceeding 5,000 BTC. Payments settle in seconds with fees measured in fractions of a cent. It is the most sophisticated application of Bitcoin Script ever built, and understanding how it works illuminates every concept in this chapter.

The Problem: On-Chain Scaling Limits

Bitcoin's block size limit (approximately 1 MB, or 4 million weight units with SegWit) and 10-minute average block interval create a hard ceiling on transaction throughput. Increasing the block size requires a hard fork and introduces centralization pressure (larger blocks require more bandwidth, storage, and processing power to validate). Reducing block time introduces higher orphan rates and reduces security.

The fundamental question was: can we get the security of on-chain settlement with the speed and cost of off-chain transactions?

The Solution: Payment Channels

Step 1: The Funding Transaction

Alice and Bob want to transact frequently. They create a funding transaction — a standard on-chain transaction that sends, say, 1 BTC into a 2-of-2 multi-sig output controlled jointly by Alice and Bob. This transaction is broadcast to the Bitcoin network and confirmed in a block.

Funding Transaction Output:
OP_2 <Alice_pubKey> <Bob_pubKey> OP_2 OP_CHECKMULTISIG

(In practice, this would be wrapped in P2WSH or P2TR for efficiency, but the logic is the same.)

At this point, Alice and Bob each have 0.5 BTC in the channel. Neither can spend the funds unilaterally — both signatures are required.

Step 2: Commitment Transactions

Rather than broadcasting a transaction every time Alice pays Bob (or vice versa), they create and exchange commitment transactions — pre-signed transactions that distribute the channel's funds according to the current balance. These transactions are valid Bitcoin transactions but are not broadcast. They are kept by each party as insurance.

Each commitment transaction has a critical asymmetry: it gives the other party the ability to claim their funds immediately, but makes the creating party wait through a relative time lock (using CSV) before they can claim their own funds.

Alice's version of Commitment Transaction #1 (Alice: 0.4 BTC, Bob: 0.6 BTC):

Output 1 (Bob gets 0.6 BTC immediately):
<Bob_pubKey> OP_CHECKSIG

Output 2 (Alice gets 0.4 BTC after 144-block delay, OR Bob can claim with revocation key):
OP_IF
    <Bob_revocation_pubKey> OP_CHECKSIG
OP_ELSE
    144 OP_CHECKSEQUENCEVERIFY OP_DROP
    <Alice_pubKey> OP_CHECKSIG
OP_ENDIF

The time-lock-plus-revocation structure is the heart of Lightning's security model. If Alice broadcasts this commitment transaction:

• Bob can claim his 0.6 BTC immediately.
• Alice must wait 144 blocks before claiming her 0.4 BTC.
• If this is an old commitment transaction (and Alice is trying to cheat by broadcasting an outdated state that gives her more money), Bob can use the revocation key to claim Alice's 0.4 BTC during the 144-block window — punishing Alice for cheating.

Step 3: Revocation and State Updates

Every time Alice and Bob update the channel balance (a new payment), they create a new pair of commitment transactions and exchange revocation secrets for the old commitment transactions. The revocation secret for an old commitment is the private key that unlocks the revocation path in that commitment's scripts.

Once Alice gives Bob the revocation secret for Commitment #1, she can no longer safely broadcast Commitment #1. If she does, Bob will see it on-chain during the 144-block delay and use the revocation key to claim all of Alice's funds. This is the penalty mechanism that keeps both parties honest.

The state progression looks like this:

Each new commitment transaction invalidates the previous one through the exchange of revocation secrets. The channel can be updated thousands or millions of times without ever touching the blockchain.

Step 4: HTLCs for Multi-Hop Routing

Payment channels between just two parties are useful but limited. The Lightning Network's real power comes from routing payments across multiple channels using Hashed Time-Locked Contracts (HTLCs).

Suppose Alice wants to pay Carol 0.1 BTC, but Alice only has a channel with Bob, and Bob has a channel with Carol. The HTLC mechanism allows Alice to route the payment through Bob:

1. Carol generates a random secret R and sends Alice the hash H = SHA256(R).
2. Alice adds an HTLC to her channel with Bob: "Bob gets 0.1 BTC if he provides the preimage of H within 100 blocks."
3. Bob adds an HTLC to his channel with Carol: "Carol gets 0.1 BTC if she provides the preimage of H within 50 blocks."
4. Carol reveals R to Bob to claim her 0.1 BTC from the Bob-Carol channel.
5. Bob now knows R and reveals it to Alice to claim his 0.1 BTC from the Alice-Bob channel.

The HTLC script (simplified) looks like this:

OP_IF
    OP_HASH160 <H> OP_EQUALVERIFY
    <recipient_pubKey> OP_CHECKSIG
OP_ELSE
    <timeout> OP_CHECKLOCKTIMEVERIFY OP_DROP
    <sender_pubKey> OP_CHECKSIG
OP_ENDIF

Notice the time lock asymmetry: Alice gives Bob 100 blocks; Bob gives Carol only 50 blocks. This ensures that Bob has time to claim from Alice after learning R from Carol. If the time locks were equal, Bob might learn R from Carol but be unable to claim from Alice before the timeout expires.

Every concept from this chapter is at work simultaneously in this single mechanism: - Multi-sig for the funding transaction - CSV relative time locks for the revocation window in commitment transactions - CLTV absolute time locks for HTLC timeouts - Hash locks for HTLC conditional payments - OP_IF/OP_ELSE for branching between the hash-lock path and the time-lock refund path

Step 5: Channel Closure

Channels can close in three ways:

Cooperative close: Alice and Bob agree on the final balance and create a single closing transaction that distributes funds accordingly. This is the most common and cheapest closure method. With Taproot, this looks like any ordinary single-signature transaction.

Unilateral close: One party broadcasts the latest commitment transaction. The other party can claim their funds immediately; the broadcasting party must wait through the CSV time lock. This is used when one party is unresponsive.

Penalty close: A party broadcasts an old (revoked) commitment transaction. The counterparty detects the fraud during the time lock window and broadcasts a penalty transaction claiming all funds. This is the enforcement mechanism that keeps the channel honest.

The Taproot Improvement

Lightning Network channels benefit enormously from Taproot:

Privacy: With Taproot, the funding transaction (2-of-2 multi-sig) looks like a standard single-signature transaction thanks to Schnorr key aggregation. Cooperative channel closures also look like standard transactions. This makes Lightning channels indistinguishable from ordinary Bitcoin transactions on-chain, improving privacy for all Lightning users.

Efficiency: Schnorr signatures are smaller and faster to verify. MAST allows complex HTLC scripts to be hidden in the key path, revealed only in dispute cases. This reduces the on-chain footprint of Lightning transactions.

Point Time-Locked Contracts (PTLCs): Taproot enables PTLCs, an upgrade over HTLCs that uses Schnorr adaptor signatures instead of hash locks. PTLCs improve privacy by using a different "point" (elliptic curve point) for each hop in a payment route, preventing correlation between hops. With HTLCs, the same hash H is used across all hops, allowing a routing node that controls two channels in the same path to link the payment.

Analysis Questions

1. Script primitives: Identify every Bitcoin Script feature used in the Lightning Network's construction. For each, explain what would break if that feature did not exist.

2. Security model: The Lightning Network's security relies on the assumption that both parties monitor the blockchain for fraudulent commitment broadcasts. What happens if a party goes offline for longer than the CSV time lock period? How do "watchtowers" address this problem?

3. Taproot migration: As of 2025, the Lightning Network is gradually migrating from P2WSH-based channels to P2TR-based channels. What are the concrete privacy and efficiency benefits? Are there any risks or challenges in the migration?

4. Routing economics: Lightning routing nodes earn fees for forwarding payments. If routing fees are too low, nodes have no incentive to provide liquidity. If fees are too high, users will prefer on-chain transactions. How does this economic equilibrium relate to the time lock and multi-sig costs discussed in this chapter?

5. Failure modes: Describe three scenarios in which a Lightning payment can fail and the Bitcoin Script mechanisms that ensure no party loses funds in each case.

Key Takeaways

• The Lightning Network is built entirely from Bitcoin Script primitives that existed (or were added through soft forks) without any hard fork or protocol-breaking changes.
• The combination of 2-of-2 multi-sig, CSV time locks, CLTV absolute time locks, hash locks, and conditional logic enables a sophisticated state machine that is enforced by the Bitcoin consensus layer.
• The penalty mechanism — where broadcasting an old state allows the counterparty to claim all funds — is the game-theoretic foundation of Lightning's security.
• Taproot improves Lightning's privacy by making channel operations indistinguishable from ordinary transactions and enables the upgrade from HTLCs to PTLCs.
• This case study demonstrates that Bitcoin's "limited" scripting system, when combined thoughtfully, can achieve functionality that rivals far more expressive smart contract platforms.