Lightning: Bitcoin’s High Speed Transmission Protocol
Bitcoin’s usage growth over the past decade has been strong and steady. On this journey, from its humble beginnings, Bitcoin has progressed through several phases of differing usage. Starting as a worthless geeky collectible, it soon moved to a niche instrument of speculation, before graduating to its more recent and increasing use as a store of value, or digital gold. Such progressions inches Bitcoin ever closer to the final and most valuable use case: A global and widely used new form of money.
However, widespread usage of bitcoin as money requires it to be useful as such. For bitcoin to reach its final monetary form, it is not sufficient to be a store of value alone (as is currently the case with gold), it also needs to be a viable medium of exchange. As we will see, this is a peculiar challenge for a decentralised payment system.
Bitcoin was designed to reliably settle peer-to-peer transactions without reliance on any third party. To achieve this, it purposefully prioritises security and settlement finality at the expense of transaction scalability. All decentralised systems face this dilemma as there exists an inescapable tradeoff between decentralisation and scalability at the blockchain level. Take note of that last distinction as it is an important concept to grasp when investigating how scalability can still be achieved in decentralised systems using layering. We’ll return to that in a bit.
To maximise security and robustness, Bitcoin’s protocol encourages decentralisation in its network structure, meaning that no specific individual or group is distinctly relied upon to ensure network uptime. A widespread infrastructural base is incentivised by keeping the barriers to joining the network as low as possible. By minimising participation requirements (computation, storage and bandwidth) Bitcoin can be effectively operated by cheap and widely available computers, and as a result, the network is kept accessible for as many participants as possible.
Simultaneously, to optimise for reliable settlement finality, Bitcoin enforces strict and complex rules that ensure time and energy have been expended to confirm transactions.
While Bitcoin’s recipe to integrate security and finality have proven fruitful in its aspirations as a peer-to-peer monetary system, it comes with tradeoffs:
1. Non-instant settlement transactions
Bitcoin requires its transaction record (“the blockchain”) to add new batches of transactions (“blocks”) in a process that proves the passage of time to its otherwise uncoordinated network members, and as a result, bitcoin payments are settled incrementally, not instantaneously. Per the rules, each new batch of transactions must be replicated across the entire network and each member must verify the validity of each transaction. These duties take time and energy for each participant to perform, and transactions and blocks also require time to reliably propagate across the network.
In order to minimise the incidence of stale blocks, Bitcoin is programmed to generate blocks every 10 minutes on average. This ensures that the chance of two miners finding simultaneous blocks is lowered, meaning a valid block is likely to fully propagate across the network before an alternative valid block is discovered elsewhere.
The trade-off is that it can take time for a transaction to make it into the blockchain, and once it’s in, the level of settlement finality it enjoys is determined by how many blocks deep the transaction sits in the blockchain (and the total cost of mining those blocks).
2. Capacity limitations
Apart from batches of transactions (blocks) being settled on a delayed schedule, they are also limited in total size (often referred to as the “block size”). Because these batches of transactions are replicated across the network, each participating member must sacrifice storage to maintain their own record of transactions and bandwidth to send and receive them. This is a cost node operators must bear to participate in the network, and one for which they are (unlike miners) not compensated by the protocol. Bitcoin limits these data requirements as a means to encourage participation and minimise barriers to entry.
Depending on the type of transactions the market requests for inclusion in any given block, Bitcoin’s rules require each batch (or block) of transactions to not exceed a certain data size. The actual average block size is not static, but tends to not exceed ~1.3Mb. The maximum theoretical limit is somewhat higher, but not much so. This size limit effectively increases the network’s decentralisation and security as it ensures it will remain inexpensive for users to support basic network activities.
Bitcoin’s capacity limitations together with its delayed batch processing yield a settlement speed of roughly three to seven transactions per second. This equates to around 600,000 transactions per day, which is roughly equivalent to the daily number of transactions on the FedWire settlement network. While it is probably enough for a settlement system, it is nowhere near the capacity needed for a retail payment system capable of handling small, casual transactions such as Visa or MasterCard.
3. High individual transaction costs
To keep track of new payments throughout the settlement process, Bitcoin offers a queue that serves as a waiting room for outstanding payments (“the mempool”). These outstanding payments are ordered by the size of their offered fee and sit waiting until they’re added to a block by a miner. However, due to its limited speed and capacity, Bitcoin lends itself to congestion and waiting periods that unfavorably impact senders of low-value transactions (whose transactions are less able to justify competitive fees). If transaction demand gets high enough, low-paying fees may never make it into the blockchain.
Figure shows that transaction fees are dependant on available block space and demand to process transactions
Original Source: Buck Perley, Unchained Capital
Interestingly, Bitcoin transaction fees are offered on the basis of its data size, not its transaction size (value). A Bitcoin transaction sending 1,000 btc costs the same for a network participant to process as a 0.01 btc transaction. This favours transactions carrying large amounts of value. Being the same data size as a small value transaction, high value transactions can offer much higher fees per data size, while still paying a much lower percentage of the total transaction value.
In a way then, the higher the value of a transaction, the cheaper it is to send.
Block producing participants (“miners”) earn fees and subsidies (together, the “block reward”) for enduring the costs inherent in Bitcoin’s settlement process. The subsidies are released by the protocol as newly issued bitcoin supply, while the fees are ‘recycled coins’ offered by users in each transaction. Importantly, each time bitcoin’s inflation rate is reduced (each “halving”), transaction fees become more significant as a means to incentivise Bitcoin’s settlement process.
Figure shows the long term trend of fees increasing as a proportion of miner revenue.
In the early days of Bitcoin, fees were trivial as the project saw little adoption and its asset was more of an experiment than a monetary instrument. Back then, transaction demand on the Bitcoin settlement chain was low enough that blocks were rarely full and transaction fees were effectively zero.
However, earlier this year, bitcoin’s market cap surpassed a trillion dollars, and its network and market infrastructure are supported by a vast industry of professionals. It has undergone three halvings and its inflation rate is approaching that of gold, meaning that the subsidy part of the block reward is getting smaller and smaller.
Increasing adoption has also induced more network activity, meaning more and more transactions are being requested by the market. This has highlighted the scarcity of transaction space available on Bitcoin, and as a result, several software upgrades and creative strategies have been adopted to combat high fees. Despite these advancements, transactions are still becoming increasingly expensive, making small casual payments on-chain, uneconomical.
Figure showing increase in mempool size since Jan 1, 2020. Colour bands represent the volume of transactions offered at each fee level. Every time the graph hits zero, the mempool is cleared.
The consequence of these dynamics is that Bitcoin requires layered solutions built on top of its settlement chain in order to accommodate the billions of daily transactions required for bitcoin, the asset, to take on a role as a widespread medium of exchange. Centralised payments aggregators like Visa, MasterCard, PayPal, Square etc. will likely fill a significant chunk of that role, but this is a ‘risk’ in that these giants are competitors with clout and network effect, potentially eroding the benefits of Bitcoin’s decentralisation.
However, there are also independent alternatives out there that retain a user’s full autonomy over spending, without relying on a centralised service.
One such system is the Lighting Protocol.
Lightning’s core innovation is its use of payment channels. These allow two trading parties to freely transact in a peer-to-peer manner, using bitcoin, but without needing to use Bitcoin’s hefty finality process for anything other than initiating and ending a series of trades. This works similar to a pre-funded tab of sorts, whereby each entity continuously tracks a history of payments as they’re streamed back and forth. Then, should they wish to conclude their trading partnership, they submit the final balance to the Bitcoin blockchain and undergo its robust settlement process.
In other words, payment channels enable one opening, and one final settlement transaction, to encompass many historical trades. This increases the economic density of the bitcoin transactions and splits its fees across a potentially unlimited amount of individual payments.
The Lightning Network operates as a second layer atop Bitcoin where each participant recognises the same native unit and uses it to make exchanges. Importantly, as an extension to Bitcoin, Lightning doesn’t have or need its own blockchain. Rather, it relies on Bitcoin for its security in finalising transactions. In this way, Lightning is subscribing to a judiciary service offering, where Bitcoin’s layer one acts as the final arbiter to any disputes on Lightning’s layer two. In other words, if there’s a disagreement within a payment channel, Bitcoin issues a verdict in accordance with its rules.
The channels we’ve explained above are bidirectional, meaning they only involve two parties sending money back and forward between each other. However, bidirectional payments channels are not sufficient to create a globally viable payments network. So to improve bitcoin’s use case as a transactional currency, Lightning expands beyond its core concept of bidirectional payment channels to networked multidirectional channels, where payments can be routed in hops across multiple channels, similar to how packets of information are routed across the internet.
Figure shows a simplified structure of a multi-channel network. The numbers reflect the liquidity capacity of each channel, denominated in satoshis (1/100,000,000 btc).
Lightning creates a mesh network of interconnected users, and payments can travel from one to any other Lightning user as long as there exists a route of open payment channels connecting the two. For example, if Alice has an open channel with Bob, Bob has one with Carol, and Carol has one with Dave, Alice can pay Dave by using Bob and Carol as payment routing intermediaries.
For this to work efficiently, payment channels require liquidity. As briefly mentioned above, each payment channel is constructed with a pre-loaded, fixed amount of bitcoin. The two entities entering their trading partnership set a capacity limit to their channel as they fund it with a bitcoin transaction. Thus, as payments are streamed back and forth, there is an inherent limit to the size of each payment. One’s limit is reflective of the capacity in the total channel, as well as their current balance within the channel. To visualise this concept, consider an ancient mathematical tool: the abacus.
In this example, a payment channel is represented by a single wire on an abacus. The channel’s capacity is then explained by the total amount of beads strung on that wire, and each channel partner’s available balance corresponds to the amount of beads that reside on his/her side.
Channel liquidity along the route of an intended payment therefore becomes an influential measure of the Lightning Network’s ability to facilitate said payment. All channels along the intended path must have the necessary capacity to handle it in the desired direction. So long as there are available channels with necessary liquidity, and a more or less circular economy in the system, Lightning can handle an effectively unlimited transaction flow, and these transactions can be arbitrarily small and frequent.
So What Might Lightning do for Bitcoin?
When Lightning works as visualised, it mitigates Bitcoin’s deficiencies as a high-cost, slow settlement system by adding a layered transport network for cheap, speedy payments. This is quite similar to what Visa and MasterCard do for the Federal Reserve. Most transactions in the dollar economy never touch the systems of the Fed, they are processed by payment aggregators who in turn use intermittent commercial banks, who then use the Fed for final settlement. Lightning does the same thing for bitcoin transactions, only using the Bitcoin blockchain for final settlement.
With that in mind, let’s review how Lightning could fit as a puzzle piece to assuage Bitcoin’s fundamental tradeoffs:
In Bitcoin, users wait for their transactions to be finalised in a process that’s designed to prove the passage of time. The target time between blocks is optimised for robustness and reliability, not rapid transaction speeds. Hence, this scheduling dynamic requires users to sometimes accept wait periods on the order of hours.
As an alternative, using payment channels, Lightning forwards payments at the same speed as an email is sent across the internet — instantly.
- Low cost
In Bitcoin, transaction fees have been increasing due to network congestion and the demand to send bitcoin.
While sending a routed payment across multiple channels will incur fees, these fees are negligible and subject to competitive pressure. At the time of writing, the base fee per transaction is 1 satoshi (0.00000001 btc), equivalent to ¢0.04.
- High Capacity*
In Bitcoin, transactions are settled as part of a block that’s limited in size (~ 1.3Mb). This confines Bitcoin to linear scaling efforts where either transaction sizes or block capacity limits would need modification. While technological advancements have assisted in the reduction of transaction sizes, increasing block size would be counterintuitive to Bitcoin’s prioritisation of security and robustness.
Alternatively, Lightning removes the concept of a block such that payments are simply limited by the liquidity in each payment channel. This opens Lightning to scale horizontally as it becomes increasingly more efficient to transact when more payment channels are open and capital is efficiently dedicated to the network. Throughout 2020, Lightning’s capacity rose roughly 22% and active nodes rose roughly 41%. At the time of writing (July 2021), Lightning is on pace for a record year with capacity rising another roughly 90% and active nodes another 52%.
In summary, Lightning as a second-layer inherits many of Bitcoin’s characteristics as its global, cross-border, and accessible by anyone. However, through its use of payment channels, Lightning enables users to amortise the cost of a bitcoin transaction across many payments over time. We see Lightning as a critical technology that could evolve bitcoin’s usefulness in payments beyond its stigma as an investment vehicle.
 Bitcoin has network fault-tolerance meaning it can continue operating despite one or many of its constituent network participants (nodes) failing or going offline. This has led to more than 8 years of 100% network uptime since its last serious consensus bug which was fixed in 2013. Over its entire lifetime, Bitcoin’s uptime stands at 99.986% (March 2020).
 Joining Bitcoin’s network requires storing blockchain data as well as sending and receiving messages with other nodes.
 In computer science, this process is referred to as Nakamoto Consensus. It is a mechanism whereby nodes, in order to propose valid blocks, solve a math problem of dynamically-adjusting difficulty that requires the expenditure of energy. The expended energy acts as an objective proof, independent of the system itself, that a sufficient amount of time has passed since the previous block. The cost of this energy also adds counterfeit protection by making the creation of dishonest transaction histories as costly as honest ones. Honest behaviour is incentivised through competition for bitcoin rewards from newly minted coins and transaction fees.
 A stale block is a valid block that does not make it into the blockchain. This normally happens because two blocks are found more or less simultaneously by two different miners, leading to short-lived forks in the transaction history. Such forks are almost always resolved when a new block is found to extend one of the two competing chains causing the network to immediately discard the now shorter chain. A stale block is often referred to as ‘orphaned’.
 Each subsequent block that’s found and added to the height of the chain is called a confirmation. With each confirmation on top of a given block, the cost necessary to modify that block increases as a new proof-of-work must also be discovered for each confirmation block. By common convention, six confirmations is widely considered as fully settled, although this should arguably vary based on transaction size.
 At the time of writing (July 2021), basic hardware with basic connectivity can run Bitcoin with just 404 GB of disk space and the estimated equivalent of 5 GB/day download speed.
 The first monetary bitcoin exchange occurred in 2009 October where 1309.03 BTC = $1, but a market rate wasn’t established until July 2010.
 CoinShares Research, Coinmetrics.
 The 2017 Segwit softfork enabled more transactions to fit in a block by stripping certain data away from transactions. This introduced a new variable called block weight where a block may be 4 MB but only 1 MB is necessary for legacy nodes to validate transactions. Exchanges also adopted batching techniques that enabled them to reduce daily on-chain transactions. Coinbase claims to have reduced daily transaction count by 95% in 2020 due to batching.
Sign up for our monthly newsletterSubscribe
Our latest insights & research. Never spam.