The history of the Lightning Network: from brainstorming to beta version

A few weeks ago, the first Lightning Network implementation lnd was officially launched in beta. The second implementation, eclair, was released last week, and the third implementation, c-lightning, is coming soon. Therefore, this overlay network that achieves cheap and instant payments on Bitcoin has been considered by most of its developers to be safely used on the Bitcoin mainnet: this is a major milestone in the development of this technology over the years. .

This story is a long story.

First spark

The conceptual origin of the Lightning Network can be traced back to Bitcoin itself.

The first concept used by Lightning Network is called “payment channel”. The payment channel is essentially the Bitcoin balance between two Bitcoin users; and it only requires that they know each other, and other people do not need to know or care about their relationship with each other. The important thing is that their balances can be updated without any Bitcoin transactions on the chain; and the increase in A’s balance means that B’s balance decreases by the same amount.

After they complete the transaction and are satisfied, they only need to broadcast a transaction on the network to settle their payment channel: this transaction will distribute the due amount to both parties based on their channel balance. For both of them, this also means that channel updates (“off-chain transactions”) are relatively cheaper, because there is no need to pay miner fees, and it is also faster because there is no need for blockchain confirmation.

This concept can be said to be as early as the Bitcoin software released by Satoshi Nakamoto in 2009 as a whole. Bitcoin 0.1 includes a draft code that allows users to update the transaction before the transaction is confirmed by the network:

The history of the Lightning Network: from brainstorming to beta version

Draft payment channels included in Bitcoin 0.1

Although this code is very rough, Mike Hearn told more details about how the payment channel works when Satoshi Nakamoto later talked privately with the bitcoinj developer.

A few years later (2013), Hearn disclosed Satoshi Nakamoto’s explanation of the payment channel in the Bitcoin development mail group:

The history of the Lightning Network: from brainstorming to beta version

Satoshi Nakamoto’s explanation of the principle of payment channels, exposed by Mike Hearn

The first payment channel

Although the payment channel as a concept can be said to be as old as Bitcoin, Satoshi Nakamoto’s design is not safe enough. More importantly, a user in the payment channel can work with the miner to let the blockchain confirm an old transaction, so as to obtain more bitcoins than he deserves (such as just paying the other party, and then Put old transactions on the chain).

The first solution to this problem appeared in 2011 (after Satoshi Nakamoto left the Bitcoin project). Bitcointalk forum user “hashcoin” conceived a two-layer payment channel hashcoin, which requires users to exchange partially signed multi-signature transactions and time-locked transactions that are interdependent with these multi-signature transactions. If one participant disappears, the other party can take all the funds in the channel after waiting for a period of time. However, the disadvantage of this design is that this payment channel is one-way. Alice can pay Bob any number of times, but Bob cannot use the same channel to pay Alice.

Another idea similar to hashcoin surfaced in early 2013, and this time it is no longer just thinking about it. In April of this year, Jeremy Spilman described the concept of a payment channel in the Bitcoin development mailing list. He even wrote a proof-of-concept code. This design was adjusted by Mike Hearn. Matt Corallo, who later became a Bitcoin Core software contributor, Blockstream company co-founder, and Chaincode Labs developer, changed it from a concept to a working code on bitcoinj in mid-2013.

After another year, Alex Akselrod (now an engineer at Lightning Labs) proposed a two-way payment channel for the first time. Alice can pay Bob any number of times, and Bob can also use a decreasing time lock to pay Alice in the same channel-but the number of times is limited. However, unlike a one-way payment channel, this solution has never been implemented by code.

The first payment network concept

At the same time that the concept of the first payment channel emerged, others-including Bitcoin Core developers Peter Todd and Gavin Andresen-were also thinking about off-chain payment networks. If Alice can pay Bob through an off-chain transaction, and Bob can pay Carol through an off-chain transaction, then Alice should also be able to pay Carol through Bob without having the transaction on the chain.

Corné Plooy (now a developer of the Lightning Network, at the Dutch Bitcoin exchange BL3P) has also been studying the payment layer of Bitcoin, rooted in a preliminary idea he put forward in 2011.

The history of the Lightning Network: from brainstorming to beta version

An early illustration of Plooy’s payment layers, which later became Amiko Pay, the predecessor of the Lightning Network

Under the advice of Bitcoin Core developer and future CTO of Blockstream, Gregory Maxwell, and Ripple founder Ryan Fugger (and others), this idea has evolved over the years and became the basis of Bitcoin and the original Ripple Collectively, and produced a Plooy system called “Amiko Pay”. Earlier drafts of Amiko Pay did not use payment channels, so trust must be injected into the system: if a user refuses to settle the balance with another user, the latter has nothing to do.

An early payment network concept using payment channels was proposed in 2012 by Meni Rosenfeld, a mathematician who later became a partner of Bitcoin emBassy TLV. On the Bitcointalk forum, Rosenfeld described an example (following the example above) where a payment processor replaced Bob to serve Alice and Carol. This payment processor, in turn, has opened payment channels with other payment processors, so the entire payment channel network is a wheel model. 

This solution has appeared many times in the past few years. For example, Bitcoin Core contributor Peter Todd proposed this concept in the Bitcoin developer mailing list in 2014. At the same time, payment processor BitPay also published a white paper on a similar in-channel payment solution (“Impulse”) in early 2015. A similar solution was also implemented by the Swedish startup Strawpay, called Stroem (or Ström), at almost the same time – but none of these developments had a significant impact.

The history of the Lightning Network: from brainstorming to beta version

Logo of the now-defunct Strawpay micropayment company

An earlier attempt to establish a trust-free payment channel network came from Alex Akselrod. He proposed a draft in 2013, which was transformed into a proof-of-concept code in 2014. Akselrod’s solution took a lot of effort to solve this problem theoretically. But in practice, the problem remains. For example, if a payment fails during the routing process, the user has no right of recourse, and only waits for the funds to be released after the time lock of the payment channel is lifted, which may take several months.

At the same time, by 2015, Plooy’s Amiko Pay has evolved to the point where it can work without trust. However, his design required relatively far-reaching changes to the Bitcoin protocol, so much so that certain types of transactions would need to be rolled back. Although it is technically possible, it is not so obvious whether such changes to Bitcoin will be accepted.

At the end of the year, researchers from ETH Zurich, Dr. Christian Decker (now at Blockstream) and Roger Wattenhofer proposed in their white paper “A Fast and Scalable Payment Network with Bitcoin Duplex Microayment Channels” Another overlay network design. Their solution relies heavily on time locks as a “countdown device” for channel validity, and a cryptographic technique called “invalid tree” to invalidate outdated channel transactions.

Akselrod’s solution, Amiko Pay’s later draft, and Duplex micropayment channel (DMC) are all similar to the Lightning Network in some respects, and they can all work under different assumptions (choices). If the Lightning Network is not invented, any of the solutions here may become the basis of Bitcoin’s expansion layer.

However, history has no ifs, and the Lightning Network turned out.

Lightning Network

After years of evolution of payment channels and network design, all the puzzles were finally collected in early 2015.

Thaddeus “Tadge” Dryja and Joseph Poon, the CTO of the smart contract trading platform Mirror, wrote a white paper called “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments”, which was first published in February 2015.

Facts have proved that it turned things around.

The Lightning Network white paper proposes a variety of solutions to achieve a completely trust-free payment channel network: anyone who wants to cheat, he has to risk losing all his balance in the channel; and the intermediary that transmits payment transactions does not Want to steal a penny. In addition, this solution requires relatively few changes to the Bitcoin protocol, and promises to be more flexible and user-friendly than other solutions already available.

The key innovation described in this white paper is the “Poon-Dryja channel”. Like other payment channel designs in the early days, the Poon-Dryja channel also relies on participants to exchange partial signatures that are not broadcast to the entire network. But unlike its predecessors, this new channel requires an extra step: the two parties need to constantly exchange secret values; this design allows the channel to be updated in any “direction”. Alixe can pay Bob any number of times, and Bob can also pay Alice any number of times in the same channel.

In addition, the Lightning Network also utilizes the Hash Time Lock Contract (HTLC). This concept is generally considered to be proposed by Tier Nolan, and the original intention of the design is to be used for cross-blockchain transactions; for example, it is used to exchange Bitcoin and Litecoin without trust. In the Lightning Network, this tool is used to connect multiple payment channels in series.

Poon and Dryja presented their ideas for the first time at the Bitcoin Devs Seminar in San Francisco in February 2015.

In the following months, throughout the spring and summer of 2015, the issue of Bitcoin expansion and the disagreement of the block size limit evolved into an open dispute. In this crisis atmosphere, people held two consecutive conferences at the end of 2015: Scaling Bitcoin Montreal was held in September, and Scaling Bitcoin Hong Kong was held in October. In Montreal, Poon and Dryja gave a speech again, and both Poon and Dryja gave a second more in-depth speech in Hong Kong.

Just after the Hong Kong conference, Gregory Maxwell proposed a roadmap for expansion in the Bitcoin Developer Mail Group. This roadmap prominently includes the Lightning Network. It has won the support of most people in the Bitcoin technology community and has become the de facto roadmap of the Bitcoin Core project.

If people’s original expectations for the Lightning Network were not high enough, this is enough.

accomplish

The Lightning Network’s white paper is a long and complex document containing many highly technical concepts; in 2015, few people had the time and ability to read and understand this document. But after studying this white paper, Rusty Russell, a long-time Linux kernel developer, has improved everyone’s basic understanding. In a series of blogs at the beginning of 2015, Russell “translated” this white paper for a wider audience (but it’s still rather picky).

Then, in March 2015, Russell was hired by the Blockstream project to develop a Lightning Network implementation in C language: c-lightning. Facts have proved that this is a crucial step towards realization. A concept that was just put forward a few months ago, and now there is a world-leading engineer to implement it. Later, Christian Decker of Blockstream also joined Russell; others (including Corné Plooy) also contributed to this open source project.

Soon after Russell started developing c-lightning, Blocksteam was not the only company to join the Lightning Network. In the summer of 2015, ACINQ, a smaller Bitcoin technology company (which initially planned to develop a smart card-based hardware wallet) decided to also try this promising technology. The Paris-based startup company later announced that their developers had developed their own Lightning Network protocol using the Scala programming language, called eclair.

The history of the Lightning Network: from brainstorming to beta version

Eclair release announcement from ACINQ

After another few months, the third realization started. In January 2016, Poon and Dryja, the authors of the Lightning Network white paper, together with Elizabeth Stark and Olaoluwa “Laolu” Osuntokun, established a brand new company to develop the Lightning Network: Lightning Labs. Lightning Labs took the lead in opening the gate on lnd, which is a Lightning Network implemented in the Go programming language (also called “golang”) launched by Google Inc.-they started development before the company was founded.

About a year after founding the company, at the end of 2016, Dryja left Lightning Labs and joined MIT Media Lab’s Digital Currency Initiative. This organization also hired Bitcoin Core’s top developer Wladimir van der Laan and several Bitcoin Core developers. Contributors. At MIT, Dryja continued to develop the Lightning Network implementation he started at Lightning Labs and renamed it lit. Both lnd and lit are available now. The difference between Lit and lnd and other implementations is that it encapsulates the wallet and node as a whole; now, it also supports the use of multiple currencies at the same time.

In addition, the blockchain company Bitfury (known for its mining pool services and mining hardware) also forks the lnd implementation and makes another version. The special thing about this version is that it has made sacrifices in design so that there is no need to fix the malleability of the Bitcoin network-we will explain in detail later. Bitfury has also contributed to the field of transaction routing. The most famous result is the “Flare” protocol (but now the Bitfury version of lnd development seems to have stalled) (Translator’s Note: An example of “meltability” is essentially A transaction with the same signature may produce a completely different hash value (transaction ID), making the transaction untraceable; just like the same piece of metal can be melted into different shapes).

Later, in 2016, the major wallet service provider Blockchain announced that they had developed a simplified version of the Lightning Network called “thunder”. This implementation makes a relatively large sacrifice to the standard Lightning Network implementation. The most obvious is that it requires you to trust the counterparty in the network. Because of this sacrifice, it was able to launch the alpha version in the spring of 2016, much earlier than other development teams. (Although 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, and most of the contributors of the Lightning Network gathered together (this conference is therefore called the first Lightning Network Summit). Here, they discussed how to make all the different implementations interoperable, resulting in a Lightning Network Protocol specification called “BOLT” (BOLT is the abbreviation of “Basis of Lightning Technology”). The Lightning Network white paper is the first in theory, and BOLT is the basis of the actual Lightning Network as we know it today.

Agreement change

When the Lightning Network white paper first appeared, its ideas were incompatible with the Bitcoin protocol at the time—at least, it was insecure. To use the Lightning Network as written in the white paper, Bitcoin requires multiple protocol changes.

The first change is a new type of time lock, which allows payment networks to resist Bitcoin’s fusion vulnerability. However, this problem was solved before the publication of the Lightning Network white paper, and was finally solved in 2015: A new type of time lock (CheckLockTimeVerify, CLTV) proposed and designed by Peter Todd was implemented in the Bitcoin protocol NS.

Then, Bitcoin Core developers realized that the Lightning Network could perform better if there is a relative time lock. Because the relative time lock allows users to specify certain bitcoins to be locked for a period of time after a certain transaction is on the chain. Conceptually, in the Lightning Network, users can leave the payment channel open forever; but CLTV time locks make them have to close the channel regularly. A soft fork upgrade implements relative time lock, called “CheckSequenceVerify” (CSV). This script was designed by Bitcoin Core contributors BtcDrak, Eric Lombrozo, and Mark Friedenbach, and was activated on the Bitcoin network in the summer of 2016.

But the biggest protocol change required by the Lightning Network (at least, if you want a smooth user experience) is to fix the fusion vulnerability for all Bitcoin transactions.

At the time of the publication of the Lightning Network white paper, meltability was considered a big problem. Although there was already a soft fork draft under discussion at that time, the developers were not sure that it would be useful and thought that a hard fork might be needed. Then, at the end of 2015, Bitcoin Core contributors discovered that Blockstream’s Elements Project’s solution to fusion, “Segregated Witness” (SegWit), could be deployed on Bitcoin as a backward compatible soft fork.

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

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

Alpha version

Even when Segregated Witness has not been deployed on the Bitcoin protocol (and it is not clear whether it will be deployed), the development of the Lightning Network has made great progress.

This started from the testnet. The testnet is a copy of the Bitcoin network, dedicated to testing. The Lightning Network first started on a special version of the testnet: the testnet code-named “SegNet 4” (it is the fourth SegWit testnet), which was launched in May 2016.

The SegNet 4 testnet was deployed in less than half a year. In October 2016, the Blockstream development team had already improved their c-lightning prototype to a usable level. This was later called the “First Strike of the Lightning Network”: Decker “bought” a cat from Russell through an early version of the Lightning Network, using Bitcoin (without value) on the testnet.

The history of the Lightning Network: from brainstorming to beta version

A picture of a cat “bought” by Christian Decker from Rusty Russell

By January 2017, the first Lightning Network implementation-lnd-launched the Alpha version. With this realization, the Lightning Network “officially” entered the “Alpha Phase”: developers all over the world received invitations for the first time to experiment with this new technology. And Lightning Labs continues to test and improve the code.

This Alpha version, in turn, attracts more and more developers to develop applications on lng and other Lightning Network implementations. These “Lapps” range from desktop wallets to mobile wallets, to micropayment blog platforms, gambling sites, and browsers, although most of them are still designed for Bitcoin’s testnet.

By the summer of 2017, Segregated Witness was finally activated, and the foundation of the Lightning Network on Bitcoin has been consolidated. After another three months, Blockstream announced that it had issued the first Lightning Network transaction on the Bitcoin mainnet. In November, Lightning Labs made the first Lightning Network transaction across blockchains (from Bitcoin to Litecoin). In December, the development teams from Blockstream, Lightning Labs, and ACINQ announced that they had passed interoperability tests.

Moreover, by the end of the year, some people began to use alpha’s Lightning Network implementation on the Bitcoin mainnet-sometimes even against the developer’s suggestion. More and more lightning channels are opened. In December, developer Alex Bosworth used the Lightning Network channel to pay his mobile phone bill to the payment processor Bitrefill: This was one of the first transactions on the Lightning Network that used Bitcoin as money.

Another month later, Blockstream opened an online store where people can use Bitcoin to buy physical goods-although the implementation of c-lightning is only a beta version, there are clear risk warnings on the website. In February 2018, when the Lightning Network was still in the alpha stage, Lazlo Hanyecz, a legend in the Bitcoin world and world-famous for “Bitcoin Buying Pizza”, announced that he had bought it using the Lightning Network – of course, again – Pizza!

The history of the Lightning Network: from brainstorming to beta version

Lazlo Hanyecz enjoy pizza.

Beta version

After years of development and (or even longer) thinking, the Lightning Network reached perhaps the biggest milestone a few weeks ago.

In mid-March 2018, the lnd of Lightning Labs was the first to release the beta version of the Lightning Network implementation. They also announced that they had received a $2.5 million seed round of financing, with investors including the famous Twitter CEO ack Dorsey. Lightning Labs believes that they are ready to use the Lightning Network on Bitcoin’s mainnet-although it is mainly for people who understand technology.

Following this announcement, ACINQ released a tweet on March 28, announcing that eclair has launched the vet version, so it is ready to be used on the mainnet. The startup also announced that their Android Lightning Wallet will meet with you in a few weeks. (It happens to be the week when this article was published.)

Blockstream’s c-lightning implementation has not yet released a beta version, although their development team told Bitcoin Megazine that they will follow suit. The blockchain development company also released 7 new Lapps in one go in the last week of March (they have been launching new products before then), demonstrating the company’s accumulation in the front end of the Lightning Network.

Although in the alpha era, people were already using Lightning Network software, the beta version further stimulated the growth trend. At the time of publication of this article, there are already more than 1,000 Lightning Network nodes and 5,000 Lightning Network channels, with more than 10 btc remaining (the total value at the time of writing this article is about 70,000 US dollars). (Editor’s note: As of August 8, 2021, there are already 12044 Lightning Network nodes and 58,717 channels in the world, with more than 1,500 btc retained, valued at 60 million U.S. dollars.) Hundreds of new nodes are added every day, even Litecoin The dedicated Lightning Network has also been developed, and it can also interact with Bitcoin’s Lightning Network in the future.

 

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/the-history-of-the-lightning-network-from-brainstorming-to-beta-version/
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.

Leave a Reply