The Bitcoin Lightning Network: A Second-Layer Solution for Bitcoin’s Scaling Problem
The Bitcoin Lightning Network is presented as a potential game-changer for Bitcoin adoption, promising to address key limitations like scalability, transaction speed, and fees. But how can an independent system achieve this and bypass Bitcoin’s inherent rules?
This article delves into the mechanics of the Bitcoin Lightning Network, its ability to fulfill its promises, and its current status.
Note: This article assumes you understand Bitcoin. If you need a refresher, refer to “Cryptocurrency for Dummies: Bitcoin and Beyond.”
The Bitcoin Scaling Bottleneck: A Primer
Feel free to skip this section if you’re familiar with the Bitcoin scaling problem.
Bitcoin faces a scaling issue. Its design mandates storing all transactions in a data structure called a block. A block encompasses details about the preceding block, information on mining rewards, and primarily transaction data, all within a 1 MB size limit.
This size restriction translates to a maximum processing capacity of between 3.3 and 7 transactions per second, assuming non-SegWit transactions. This is insufficient for a currency aiming for mass adoption, especially compared to systems like Visa, which boasts 24,000 transactions transactions per second.
As transaction volume surges, competition for block space intensifies. Miners prioritize transactions with higher fees, making transactions costly, as exemplified by a 192-byte transaction costing $92.98, with a fee of $14.86.
Several proposed solutions aim to “scale” Bitcoin:
- Increasing block size: 2X, 8X, …, ∞X
- Smaller transactions: SegWit and similar solutions
- Sidechains: The Bitcoin Lightning Network
Expanding Bitcoin Block Size
A straightforward approach is increasing the block size limit beyond 1 MB. This idea sparked heated debates and led to the Bitcoin Cash (BCH) fork on August 1st, 2017, introducing 8 MB blocks.
However, larger blocks lead to faster blockchain growth, increasing storage costs for miners. This could centralize mining, potentially compromising the network’s security.
Moreover, increasing block size is a temporary fix. Limits will always exist and fall short of the desired 24,000 transactions per second. Even with 8 MB blocks, BCH is restricted to 61 transactions per second.
Compressing Transactions: Segregated Witness (SegWit)
Alternative solutions propose optimizing the transaction format to fit more transactions within a block. Segregated Witness (SegWit), implemented via BIP 91 on August 25th, 2017, is a prominent example.
SegWit segregates signature data from transaction blocks, reducing transaction size and improving block space utilization. This optional structure when syncing the blockchain results in smaller on-disk storage.
This also mitigates the transaction malleability problem, enhancing the security of transactions solely utilizing SegWit outputs.
Demystifying the Bitcoin Lightning Network
The Lightning Network operates as a secondary network layered on Bitcoin. It handles signed but unbroadcast transactions, settling them finally on the Bitcoin blockchain. This frees transactions from block size limitations, eliminates confirmation delays, and reduces blockchain bloat.
While Joseph Poon and Thaddeus Dryja initially described the network in a white paper, it has evolved through community contributions, with individuals and companies refining specifications and implementations.
More details will follow.
SegWit vs. Block Size Increase vs. Bitcoin Lightning Network
Which solution reigns supreme? While empirical evidence is limited, prioritizing efficient block space usage, as with SegWit, seems prudent. Increasing block size merely postpones the problem, potentially reigniting debates in the future.
However, the Lightning Network, as an alternative settlement network, presents a compelling solution. Real-world implementation and usability remain key factors to observe.
Inside the Bitcoin Lightning Network
As mentioned, the Lightning Network functions as a secondary network processing signed, off-chain transactions, relying on the Bitcoin blockchain for final settlement.
Let’s illustrate its real-world application.
Understanding Lightning Nodes and Channels
A Lightning node resembles a Bitcoin node in its networking, transaction validation, and communication aspects. However, it differs by holding funds, acting as an automated financial intermediary, and actively monitoring Lightning “channels” for malicious activities.
Nodes require funds to operate.
Note: Initially, we assume all users operate always-online Lightning nodes. This assumption will be addressed later in the Lightning Wallet vs. Lightning Node section.
Establishing a Lightning Channel
Imagine you and Bob frequently engage in financial transactions. To simplify settlements, you decide to establish a Lightning channel, each funding it with half a bitcoin.
This process mirrors creating a multi-signature Bitcoin wallet requiring both your signatures for transaction approval. However, each party receives a signed but unbroadcast “Commitment Transaction” (as per the Lightning Network white paper) that returns your initial deposits upon channel closure. This safeguard ensures fund retrieval if the channel dissolves.
Lightning Transactions with Existing Channels
Suppose you owe Bob 8,000 satoshis (0.31 USD at the time of writing). Using Bitcoin would incur a 0.10 USD fee and an hour-long wait, rendering it impractical.
Lightning facilitates an instant and free solution. You update your “Commitment Transaction” to reflect the new balance, increasing Bob’s balance by 8,000 satoshis and decreasing yours. (Cheating by broadcasting the old transaction is addressed in the Closing a Channel section.)
While closing the channel is an option, it incurs transaction fees. Holding onto the channel for future settlements is more cost-effective.
Lightning Transactions with Non-Existent Channels
Imagine joining Bob and his friend Alice. You incur a debt to Alice, payable in the defunct cryptocurrency Coinye, which Alice possesses.
Assuming Bob has an active channel with Alice, Lightning enables payment through Bob. Your node identifies the optimal route—in this case, through Bob—and facilitates the transfer with potential minimal fees for intermediaries.
Closing a Channel: Options and Risks
Three methods exist to close a Lightning Channel:
- Collaborative Closure: Both parties initiate and approve the closure. Funds are accessible immediately upon confirmation, making it the optimal method.
- Unilateral Closure: One party initiates closure without requiring approval. This triggers a time-lock during which the other party can dispute the closure using a “Breach Remedy” transaction (explained in scenario 3). Once the time-lock expires, funds are released. This is an acceptable, albeit less ideal, method.
- Breach Remedy: Since Lightning transactions form a timestamped chain with varying fund splits, malicious actors could attempt to close a channel using an older transaction favoring them. The aggrieved party can then utilize a “Breach Remedy” transaction during the time-lock, reclaiming their funds and potentially claiming the entire channel capacity.
Lightning Node vs. Lightning Wallet
The examples above assume continuous node operation. However, the Lightning Network white paper offers a solution:
…periodically monitor the blockchain for invalidated Commitment Transactions broadcast by your counterparty, or delegate this task. Delegation involves providing a third party with the Breach Remedy transaction and a fee incentive. This third party, or “watchtower,” acts only during malicious activity, preventing forced channel closures.
Watchtowers alleviate the burden of constant node uptime.
The Evolving Landscape of the Lightning Network
As of March 27, 2019, the Bitcoin Lightning Network encompasses:
- Over 7,500 nodes
- Nearly 40,000 active channels
- Over 1,000 BTC in capacity
The network exhibits rapid growth, with:
- 25 new nodes added hourly
- 304 channels established hourly
Numerous Lightning Network node implementations exist, including a Eclair Lightning-ready wallet called Phoenix on the Play Store. Despite its experimental stage, limited features, and small ecosystem, the network demonstrates promising growth.
Specifications, Implementations, and the BOLTS
The Bitcoin Lightning Network specification is currently under Request for Comments (RFC), guided by a series of evolving documents known as Basis of Lightning Technology (BOLTS), open for community contributions.
Several BOLT-compliant Lightning Network node implementations are available:
- LND: Primarily Go-based implementation (Lightning Network Daemon).
- Eclair: Primarily Scala-based implementation.
- C-lightning: Primarily C-based implementation.
The conclusion provides additional resources for further exploration.
Advantages and Challenges of the Lighting Network
The Lightning Network offers several advantages:
- Micro-transactions with fractional-cent values
- Near-zero transaction fees
- Enhanced privacy through off-chain transactions
However, challenges and criticisms remain:
- Routing and Centralization: The network’s dynamic nature necessitates constant route recalculation. Scalability poses a challenge, potentially requiring centralized supernodes for route optimization.
- Excessive Lending: Concerns exist regarding the potential for excessive lending due to the chaining nature of transactions, as highlighted in this post, a discussion joined by Ethereum co-founder Vitalik Buterin. Real-world implications require further observation.
This list of criticisms is not exhaustive, and further discussion is encouraged.
Delving Deeper into the Lightning Network
Understanding the Lightning Network’s cryptographic token exchange system is crucial. While not yet flawless or universally adopted, it represents a significant engineering feat.
A recommended starting point is the original Bitcoin Lightning Network white paper](https://lightning.network/lightning-network-paper.pdf). For additional resources, GitHub user Ben Congdon’s curated list, available at bcongdon/awesome-lightning-network, is an invaluable asset. Continuously learning about this evolving technology is essential for Bitcoin developers.
To conclude on a lighter note, here’s an amusing video featuring a supposed Satoshi Craig Wright attempting to talk about the good ole days of bitcoin.