Lightning Network: History and Reality

Aaron Van Wirdum’s History of the Lightning Network: From Brainstorming to Beta chronicles the interesting history of the Lightning Network before 2018.

Satoshi Nakamoto had the idea of a payment channel when he created BTC in 2009, and the initial code implementation of the payment channel was included in Bitcoin 1.0, and the idea of a payment channel and even the Lightning Network has been discussed by the BTC community for several years.

Bitcoinmagazine, which Vitalik founded in its early years, included many important articles from the Lightning Network, and in late 2013, Vitalik proposed a more general approach to the Mastercoin team when considering how to further expand the functionality of Bitcoin and Mastercoin. This solution allows replacing Mastercoin’s professional contract language with flexible and scriptable (but not Turing-complete) contracts. While the Mastercoin team was impressed, the offer was too radical to fit into their roadmap, and the proposal was rejected.

As a result, the rejected Vitalik began to draft an Ethereum white paper to implement its ideas about on-chain smart contracts, and BTC developers gradually formed a consensus – abandoning the route of implementing smart contracts and scaling at one layer, fixing the functions of one layer on security and basic functions, and putting various extensions off-chain implementation, two public chains behind the two public chains.


February 2015 was an important time when Thaddeus Dryja and Joseph Poon wrote a paper called “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments” with Joseph Poon after much discussion among programmers The white paper was first published in February 2015 and presented their vision for the first time at the Bitcoin Devs Seminar in San Francisco.

In the months that followed, throughout the spring and summer of 2015, Bitcoin’s scaling issues and block size caps turned into public disputes. In this climate of crisis, two consecutive conferences were held at the end of 2015: Scaling Bitcoin Montreal in September and Scaling Bitcoin Hong Kong in October. In Montreal, Poon and Dryja took the stage again, and both gave a second more in-depth presentation in Hong Kong.

Just after the conference in Hong Kong, Gregory Maxwell presented a roadmap for expansion in the Bitcoin developer mailing group. This roadmap prominently includes the Lightning Network. It gained the support of a large part of the Bitcoin technical community and became the de facto roadmap for the Bitcoin Core project.

The Lightning Network’s white paper contains many highly technical concepts that are not easy to read.

The basic component of the Lightning Network is the payment channel.

How is the payment channel implemented? This contains a series of cryptographic technical means and ingenuity based on BTC transaction logic, in short, under the premise that the safety of funds is guaranteed to be trusted, two users simultaneously “recharge” to a 2-of-2 multi-signature address, and then, by exchanging signature transaction information to achieve each balance update / complete payment, within the balance limit, such payment does not need to be on the chain, both parties to the transaction rely on the correct signature transaction information to ensure their own interests, when needed, On-chain settlement can be carried out by broadcasting the latest transaction information to the chain and closing the payment channel.

Then, through HTLC, a large number of payment networks can be connected to form a network, and payments can reach recipients who do not have a direct channel connection with the payer through such a network, such an offline payment network that relies on the BTC chain is called the Lightning Network.

(Source: A Technical Introduction to The Lightning Network)

Of course, this description is oversimplified, for details, please also read the white paper.


After the goal was set, BTC fans enthusiastically threw themselves into the construction of the Lightning Network.

To create and optimize the Lightning Network, BTC underwent several protocol updates, the largest of which was SegWit.

What Segregated Witness achieves is to separate the part of the initiator’s signature in a transaction for separate reference.

An illustration of the old and new transaction serialization posted by David A. Harding.

This makes it possible that subtransactions built on transaction A can already be broadcast when transaction A is signed but has not yet been broadcast. This can be used to build pre-signed commitment transactions to mitigate counterparty risk after injecting funds into a MultiSig address, a feature required to build payment channels.

For the history of SegWit, see “The Long Road to SegWit: How Bitcoin’s Biggest Protocol Upgrade Became Reality.”

After a long struggle, the SegWit soft fork was finally activated on the Bitcoin blockchain in the summer of 2017, paving the way for the Lightning Network.

Frankly speaking, the Lightning Network built from the bottom up of payment channels has many problems from the beginning, among which the most affecting the user experience should be the channel capacity economy problem, in addition, there are payment delay problems, state management problems, HTLC problems, and Tor dependency problems, see Shinobi’s “Where the Lightning Network is Not Satisfactory“.

The life cycle of a channel requires opening and closing two on-chain transactions, but the cost of these two transactions is enough to constitute a barrier to entry in many cases, and this recharge-card-like model is definitely not efficient in terms of the efficiency of the use of funds.

For example, if Twitter wants to use the Lightning Network to turn on tipping for 1% of 300 million active Twitter users, then it needs to open payment channels for each of these 3 million users, assuming that each channel occupies 0.01 BTC, then all these channels will take up 30,000 BTC.

According to the statistics on the, the current (October 20, 2022) Lightning Network has a total of 82,623 payment channels and channel funds of 5,001 BTC.



“The Lightning Network’s white paper is a long and complex document that contains many highly technical concepts; In 2015, few people had the time and ability to read and understand this document. But after long-time Linux kernel developer Rusty Russell studied this white paper, everyone’s basic understanding has improved a lot. In a series blog issue in early 2015, Russell “translated” the white paper for a wider audience (but still picky).

Then, in March 2015, Russell accepted an offer from Blockstream Engineering Develop a C lightning network implementation: c-lightning. This proved to be a crucial step towards realization. A concept that was just proposed a few months ago now has one of the world’s top engineers to make it happen. Later, Christian Decker of Blockstream joined Russell. Others, including Corné Plooy, have also contributed to the open source project.

Shortly after Russell began developing c-lightning, Blocksteam wasn’t the only company to enter the Lightning Network. In the summer of 2015ACINQ, a smaller bitcoin technology company that initially planned to develop smart card-based hardware wallets, decided to try this promising technology as well. The Paris-based startup later announced that its developers had developed their own Lightning Network protocol, called Eclair, in the Scala programming language.

After a few more months, the third implementation began to take off. In January 2016, Poon and Dryja, authors of the Lightning Network white paper, joined Elizabeth Stark and Olaoluwa “Laolu” Osuntokun to form a new company to develop the Lightning Network Lightning Labs。 Lightning Labs spearheaded the floodgates on LND, a Lightning Network implemented in Google’s Go programming language (also known as “golang”), which they had been developing before the company was founded.

About a year after founding the company, at the end of 2016, Dryja left Lightning Labs instead Joined MIT Media Lab’s Digital Currency Initiative, which also employs top Bitcoin Core developer Wladimir van der Laan and several Bitcoin Core contributors. At MIT, Dryja continued to develop his implementation of the Lightning Network that he started at Lightning Labs, renamed lit. Now both lnd and lit are available. What sets Lit apart from LND and other implementations is that it encapsulates the wallet and nodes into a single whole; Now, it also supports the simultaneous use of multiple coins.

In addition, blockchain company Bitfury (known for its mining pool services and mining hardware) forked the lnd implementation and made another version. What’s special about this version is that it makes design sacrifices that eliminate the need to fix the malleability of the Bitcoin network – we’ll go into more detail later. Bitfury has also contributed to the field of transaction routing, most notably the “Flare” protocol (except that now the development of the Bitfury version of lnd seems to have stalled) (Translator’s note: The example of “meltability” is that transactions that are essentially the same signature can produce completely different hashes (transaction IDs), making transactions untraceable; Just like the same piece of metal can be melted into different shapes).

Later, in 2016, major wallet service Blockchain announced that they had developed a simplified version of the Lightning Network, called “thunder”. This implementation makes a big sacrifice over the standard Lightning Network implementation, most notably in that it requires you to trust the counterparty in the network. Because of this sacrifice, it was able to launch an alpha version in the spring of 2016, much earlier than the other development teams. (While Thunder may also be compatible with the Lightning Network, development of this implementation seems to have stalled.) )

After the Scaling Bitcoin Milan conference, the third conference was held at the end of 2016, bringing together most of the Lightning Network contributors (hence the name of the first Lightning Network Summit). Here, they discuss how to make all the different implementations interoperable, resulting in a specification for the Lightning Network protocol called “BOLT” (BOLT is short for “Basis of Lightning Technology”). ”


BOLT protocol structure, derived from the network

The Lightning Network white paper has a theoretical design, and BOLT is the protocol stack of the Lightning Network. is the foundation of what we know today, de facto the Lightning Network.


OmniBOLT, which appeared on August 1, 2019, is an enhanced version of the BOLT protocol, proposed by the omni foundation, and as the name suggests, the biggest impetus for the launch of this enhanced version of the protocol is to allow the Lightning Network to add support for omnilayer assets.

Information on github shows that OmniBOLT also supports the following features, some of which are still in the planning phase:

OmniBOLT #05: Atomic Swap Protocol among Channels

OmniBOLT #06: Automatic Market Maker, Liquidity Pool and DEX

OmniBOLT #07: Hierarchical Deterministic (HD) wallet, Invoice Encoding

The atomic swap mentioned here is carried out through HTLC, as shown below.

It should be noted here that in the third step, when Alice uses R to unlock Tx 2 to obtain BTC, she must expose R to Bob, which is the key to ensuring the atomicity of the exchange.


Of course, the two parties to the atomic exchange do not need to have a direct payment channel, as long as there is a channel route connecting the two parties, of course, if the route is long, there will be routing fees and transaction delay problems.

So can there be cross-chain atomic swaps? Of course, but the premise is that the two parties to the transaction have two payment channel routes corresponding to the two chains, and the relevant technical structures of these two chains are consistent, such as BTC and LTC.

In fact, in November 2017, before OmniBOLT appeared, Ligntning Labs conducted a cross-chain atomic swap experiment, which can be found here:

The emergence of such a trading method makes sense for users who hold BTC or ominilayer assets and do not want to trade outside of their wallets.

OmniBOLT’s AMM trading model is similar to uniswap v3.

This transaction model is based on the atomic swaps described earlier, where there is no on-chain smart contract or a liquidity pool on a single address, and all nodes can provide liquidity with their own funds in the channel, which is divided into “payment balance” and “liquidity balance”. Nodes can send messages to the tracker to inform themselves of the liquidity provided and the price range they are willing to participate in market making.

Tracker is a transaction matching engine that constantly collects liquidity information and transaction request information, and when it can be matched, it helps nodes to match and reach transactions.


Nodes do not need to trust the tracker, nodes can verify the authenticity of the information provided by the tracker and meet their own transaction conditions, and then decide whether to confirm the transaction.

Is there any impermanent loss when nodes participate in market making here? Like uniswap v3, there is, but LPs can control impermanent losses to a low level by setting a market making price range.

In short, the trading logic here is equivalent to Uniswap v3 + order book, only implemented on a distributed liquidity pool, based on the logic of atomic swaps.

All of the above technical means can also be used to achieve mortgage lending, but so far, the information on github shows that OmniBOLT’s idea of mortgage lending is still in the stage of community discussion of feasibility and is not included in the development roadmap.


In mid-November 2021, BTC completed the Taproot upgrade, which is arguably the most important upgrade of BTC after SegWit.

The Taproot upgrade is a compilation of three BIPs, Schnorr Signature (BIP 340), Taproot (BIP 341), and TapScript (BIP 342), collectively known as BIP Taproot, which brings a more efficient, flexible, and private way to Bitcoin to transmit, with Schnorr signatures and Merkel Abstract Syntax Trees (MAST) at its core.


The principle of taproot, in simple terms, is to define one output and two spending paths. As shown in the image above, with Alice and Bob participating, Taproot works as follows:

Aggregate Alice and Bob’s public keys to: C=P_A+P_B

With MerkleRoot, the public key is aggregated as: P=C+H(C|| MerkleRoot) G, where H(C|| MerkleRoot) represents a combined C and MerkleRoot hash

The lock script is filled with the aggregated public key P, in the format like Segwit:[ver] [P]. ver represents the version number, and ver=1 in Taproot.

There are two spending paths, choose one of the two:

Signature mode: Alice and Bob all sign to generate an aggregate signature, which is filled in the witness script. With the aggregated public key P, the signature can be spent after it is verified.

Script Mode: Alice and Bob, who have a refusal to sign, can go to script mode. At this point, if Alice wants to complete the cost, the witness script needs to be filled in: execution data D, Script 1, C, Hash 2 in accordance with Script 1. To verify the signature, first use Script 1, Hash2, calculate MerkleRoot, and then verify P==C+H(C|| MerkleRoot)G is true, and finally build the complete script D|| Script 1 and execute the script to verify that the result is true. When the above verification is passed, the cost can be completed.

When Taproot is spent according to the signature pattern, multiple parties and a single party all look the same on the blockchain, so many blockchain analytics will not be available, preserving privacy for all Taproot users. At the same time, Taproot’s script spending model allows users to implement complex spending conditions. Taproot can effectively compress the number of bytes of transaction scripts. In the signature mode, the EDSA transaction script size increases linearly as the number of participants increases, while the Taproot transaction script size remains unchanged. In script mode, as the number of scripts increases, the EDSA transaction script size increases linearly, and the logarithmic size of the Taproot transaction script increases.

Does Taproot make smart contracts possible?

Taproot does make transactions based on complex conditions possible, and Schnorr signatures do make mass signing feasible, but Taproot doesn’t enhance BTC programmability much, and its “smart” blessings to BTC are still limited.

The brightest child Taproot spawned was Lighting Labs’ Taro.


Like Omnilayer and RGB, Taro issues assets on the BTC chain by putting asset transaction metadata into the UTXO output, but Taro uses the new Taproot transaction type to achieve all this, so it should be more efficient and better privacy.


Research and development in the field of Bitcoin off-chain protocols has opened a window for Bitcoin, and developers are pursuing much more than decentralizing the transfer of value. They started trying to go further, for example, by implementing smart contracts in an off-chain protocol, and RGB is a leader in such projects.

RGB is based on Peter Todd’s research on one-time seals and client verification, and was envisioned by Giacomo Zucco and the community in 2016 as a better asset issuance protocol on Bitcoin and the Lightning Network. The further development of these ideas led Maxim Orlovsky to develop RGB into a more comprehensive smart contract system, which he has led since 2019 with the participation of the community.

According to the official description, RGB is defined as a set of open source protocols that allow us to execute complex smart contracts in a scalable and confidential way. It is not a specific network (such as Bitcoin or the Lightning Network); Each smart contract is simply a set of contract participants that can interact using different communication channels (the Lightning Network by default). RGB leverages the Bitcoin blockchain as its state commitment layer and maintains the code and data of smart contracts off-chain for scalability. It utilizes Bitcoin transactions (and scripts) as the ownership control system for smart contracts; Although the evolution of smart contracts is defined by an off-chain solution. Finally, it’s important to note that everything is validated on the client side.

In short, RGB is a system that allows users to audit, execute, and verify smart contracts at any time without any additional overhead, and it does not use blockchain in a “traditional” way.

Some RGB fans don’t like Ethereum, and the following table by them shows this attitude.


Here we need to briefly discuss the programmability of Bitcoin and compare the smart contracts of Bitcoin to Ethereum.

Bitcoin operates on two basic concepts: transactions and UTXOs. When a transaction creates a new UTXO, it will come with an unlock condition expressed by the lock script, and when the next transaction wants to charge this UTXO, the corresponding data must be provided through the verification procedure specified by the lock script, otherwise it cannot be spent. To program Bitcoin, you have to do nothing more than at the transaction level or at the script level.

Bitcoin’s programming toolbox currently has tools such as signatures, multisignatures, hash locks, time locks, and process control.

Comparing Ethereum and Bitcoin, it can be found that Bitcoin’s programmability has obvious limitations in the following aspects:

  1. The verification procedures it allows are not arbitrary, there are only a limited number of them.
  2. It does not allow storing the internal state of funds in scripts. Even if it stipulates multiple unlock paths, it cannot limit the amount of funds that can be used by each unlock path, as long as you can unlock funds, you can use all funds using any one path. It can also be said that the script does not calculate.
  3. It does not allow to limit how funds are spent. After a UTXO is unlocked, you can spend it however you want, and the script has no way to limit how the funds are spent.
  4. The unlock script expresses a complete, independent unlock condition that does not allow us to express a dependency on another UTXO. A UTXO does not (and cannot) decide whether it can unlock it based on the existence of another UTXO, nor does it (cannot) decide whether it can unlock it based on the locking conditions of another UTXO. In a word, when spending a UTXO, the UTXO’s lock script and the unlock script provided by the exchange are an independent universe, undisturbed by anything external.

If we ask a technical expert who loves BTC, does BTC support smart contracts? He will most likely say that BTC has supported smart contracts from the beginning.

We can’t say he’s wrong, because simple scripts can also be said to be smart contracts, and the Lightning Network can be said to be a contract-based protocol that runs on the BTC blockchain, and when we take a closer look at the Lightning Network, we will find some features that may be common to BTC native smart contracts:

  • You can use transactions to express the state of the contract, and the change of transactions indicates a change in the state of the contract.
  • If you enter a state and face the risk of getting out of control, you can constrain the direction after entering this state by signing the commitment transaction in advance, thereby eliminating the corresponding counterparty risk. For example, if entering a 2-of-2 multi-signature output may cause funds to be locked, arrange a transaction to spend this output first.
  • In addition to exiting the contract, status updates always require all parties to be online.
  • Historical transactions that express state need to be stored separately by the parties (at least for now).
  • The main function of the lock script is to arrange the priority of the actions of the contract participants, rather than directly produce the result; In other words, Bitcoin-based protocol programming is using game science.

Bitcoin’s programming places higher demands on both application developers and application participants, and these limitations make application development more unintuitive and difficult to analyze, to use an inappropriate analogy, a bit like a dojo in a screw shell or writing an operating system in assembly language. Users also can’t rely on blockchain to provide them with sufficient convenience, but must take on more responsibility themselves (for example, in the Lightning Network, you need to keep historical state transactions and corresponding hash protologies yourself, or at least someone is responsible for keeping them).

We can’t say that BTC makes no sense to limit programmability so much, Bitcoin has been in fact pursuing a “resource use minimization” principle, refusing low-cost transactions to occupy block space and expand. Go down the chain. This current state is a natural result of sticking to the original intention.

In the context of Ethereum, “smart contract” means an immutable computer program that runs determintically in a virtual machine environment, the contract is deployed in the contract account on the chain, and the EVM runs as a local instance on each Ethereum node, but because all instances of the EVM run in the same initial state and produce the same final state, the entire system behaves as a single Turing-complete world computer.

The atomicity of transactions is guaranteed by the rules by which the EVM runs, regardless of what the contract executes when it is called. Any changes in the global state (contracts, accounts, etc.) are recorded only when the transaction is successfully terminated. A successful termination means that the program executes without error and the end of execution is reached. If a transaction fails due to an error, all its effects (state changes) are “rolled back” as if the transaction had never been run. Failed transactions are still stored in the blockchain and gas costs are deducted from the original account, but have no other impact on the contract or account state.

Here, smart contracts are on-chain, all states are on-chain, and the result is a good developer and user experience, and, of course, the bloat of the blockchain.

We cannot simply judge which path is right or wrong, it is a matter of choice.

Of course, the RGB team are deep believers in the BTC path, and they explain their choice this way:

The current blockchain industry advocates storing smart contract code and data on the blockchain and executing them by all nodes across the network, ignoring the excessive growth of blockchain volume and the abuse of computing resources. The scheme proposed by RGB is smarter and more efficient because it moves away from the blockchain paradigm by separating smart contracts and data from the blockchain, thus avoiding the network saturation that is common on other platforms, and in turn, it does not require every node to execute each contract, but turns the executor into a party to the contract, which brings unprecedented confidentiality.

Smart contract developers on RGB define a scheme for how contracts evolve over time. This solution is a standard for building smart contracts in RGB, and issuers must first verify contracts when defining issued contracts and wallets or exchanges when facing specific contracts. Only when the validation is correct can each party accept the request and process the corresponding asset.

A smart contract in RGB is a directed acyclic graph (DAG) consisting of state changes that is always known only in part and the rest is inaccessible. The RGB scheme is a core set of rules that govern how smart contracts evolve and is the starting point for all smart contracts. Each contract participant can supplement this set of rules (as the architecture allows), and the resulting graph is built from the iterative application of these rules.

                                      - Francisco Calderon[《A brief Introduction to RGB Protocols》](

It sounds great, but since the Bitcoin blockchain is used as a state commitment layer, it is necessarily subject to the limitations of BTC programmability, which are critical in many scenarios.

The development of RGB is basically only to the step of issuing assets, and the implementation of off-chain smart contracts will never be smooth, and whether there is a real opportunity to match or even surpass on-chain smart contracts is a big question mark.


In the past few months, there have been frequent large-scale financings in the Lightning Network field, especially the following:

Crypto payment app provider Strike raised $80 million. ❕

Lightning Labs raised $70 million.

LightsPark received investment from A16Z and Paradigm, the amount of which was not disclosed.

The channel capacity of the Lightning Network has increased significantly in the past two years:

The main thing behind it is the strength of these institutions:


Although it is growing rapidly, the overall capacity of the Lightning Network is still very different from the expectations of fans. Below is 1ml of data for October 20.


After all, there are more than 170,000 BTC across chains to ETH.

Kollider, a derivatives trading platform based on the Lightning Network, traded about 1.1 BTC on October 22.

After all, the Lightning Network is better suited for micropayments and not so well for large transactions.

The Lightning Network has a milestone significance for the off-chain expansion route represented by BTC, although the road is difficult, but under the efforts of developers, large financing and community enthusiasm, the Lightning Network should be able to set off a wave of application boom.

After all, the atmosphere has been baked here.

But given its limitations, there should be no unrealistic expectations of it.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-10-21 10:41
Next 2022-10-21 10:44

Related articles