Partnered With:

A brief history of network research | lightning

Read this article in 49 Minutes

Is the Lightning network concept an overnight success or a Slam Dunk?

CYC Labs

原文作者： CryptoYC Tech

TL; DR

· Lightning network is a mastermind, a product of the right time, geographical location and people.

· The predecessors of Lightning Network more or less needed to make changes to the underlying BTC, so they never worked well.

· It is now known as the Basis of Lightning Technology (BOLT).

· After 19 years, lightning network infrastructure became increasingly mature, and the subsequent development focused on optimization and ecological construction.

When it comes to lightning networks, most people only know the name, or those who know a little more about it know some of its basic principles. But we need to consider the question: Is the lightning network concept an overnight success or a success? If only by intuition, we think it's the latter. But what does it integrate? Why didn't the ideas that preceded it develop? This requires us to review the history of lightning network development. From the composition of lightning network, it is not difficult to find that its core is the payment channel and the payment network formed by it. So, let's take a look at some of the heroes who deserve to be remembered.

Payment Channel -- seed in BTC code

One of the big things about the Lightning network set is the payment channel. And there's nothing intuitively wrong with that. After all, if you want to form a peer-to-peer payment network, the first thing you need to solve is the problem of peer-to-peer payment.

The idea behind the payment channel is to create a channel between two Bitcoin accounts, where the balance between the two addresses is known only to the two of them, without the need for a link, until a transaction is broadcast to the chain when both parties are willing to settle.

It is now the Lightning network's "seed" because the idea is as old as BTC: Bicoin version 0.1 includes draft code for payment channels, allowing users to update transactions before they are confirmed by the network.

Of course, the scheme built from this code is still rudimentary, but Satoshi Nakamoto later spoke privately with bitcoinj developer Mike Hearn about the payment channel in more detail, and in 2013, Hearn published Nakamoto's explanation of the payment channel (see below).

In summary, if a transaction is still unpackaged in the pool, it should be possible for the user to send a new transaction with a higher serial number than the old transaction, and the miner should package the transaction with a higher serial number first. This allows one person to constantly send transactions to another, updating the serial numbers, while miners pack only the transactions with the largest serial numbers.

Also, some of the concepts involved, such as:

· nLocktime, a field in the BTC transaction. Any transaction that contains this field can only be packaged after 1000 blocks if the value of the field is a meaningful value.

· signaturehash

·......

Inspired a bunch of bigwigs to start a series of subsequent attempts.

Hashcoin -- the idea of the first usable payment channel.

But we can see that in this preliminary explanation, it is difficult to avoid the double flower problem, that is, it is difficult to do without trust. Suppose a user in the payment channel conspired with a miner to get the block to acknowledge an old transaction in their favor (the previous transactions in the pool were all legitimate, so it wasn't only the transaction with the highest serial number that was legitimate), then someone else would suffer, and you and the miner would benefit.

So, based on this problem, on July 4, 2011 (after Satoshi disappeared), Bitcointalk user "hashcoin" designed a two-tier payment channel, The core idea is to require multiple sign-on transactions to be submitted as well as valid time-lock transactions with interdependence (taking advantage of BTC's original nLocktime field). If one participant disappears, the other participant can withdraw all funds in the payment channel after the time lock is unlocked. We can look at the process to see how great this idea is and how it affects the next set of solutions.

As we can see, Hashcoin uses a very clever idea to get the receiver in the payment channel to sign a transaction B that costs both the output of the payment channel (again, UTXO model, there is no balance, only Output and input, An input must be traced back to an output), and then both parties sign the output transaction A of the payment channel. When the time payer wants to pay money to the receiver, he only needs to update transaction B (the initial sequence of transaction B is 0, and the updates are added one by one). Finally, before the hash lock expires, the receiver broadcasts transaction B with a larger sequence number to complete the settlement.

The best part of this idea is to solve the problem that the money in the payment channel cannot be withdrawn when the two parties no longer cooperate. In order to open a channel, it is necessary to sign the transaction that allows the funds to be transferred out of the channel (in case the receiver does not want to play with the payer, he can still get his money back after the time lock is unlocked, instead of being locked in the payment channel) before signing the transaction for the funds to be transferred.

But here's the downside to this idea:

· The whole channel is one-way. Only A to B or B to A, in turn, have to open a new channel, very inconvenient.

· How to use the payment channel without knowing who the recipient is.

· nlocktime can only prove that an output is likely to be spent in the future, but it does not prove that it is impossible to spend the output before its expiration.

· At that time, the hash method of BTC required signature (before segwit), so to complete transaction B, the capital input of transaction A was required first, which formed a paradox. This is also a relatively out-going BTC malleability (plasticity) problem.

And more importantly, hashcoin is just an idea, not an attempt to implement it.

Jeremy Spilman's payment channel

It wasn't until April 2013 that Jeremy Spilman worked on a concept similar to hashcoin and wrote a proof of concept code. Since Jeremy's idea was described via the Bitcoin development email group at the time, it didn't have a specific name. It was later optimized by Mike Hearn (who published Satoshi Nakamoto's description of the payment channel above), and Bitcoin core contributor, blockstream co-founder, Matt Corallo (Chaincode Labs, On June 27, 2013, announced the addition of the concept to bitcoinj, the BTC development library on which many Bitcoin applications and services are built, Examples include bisq.network, bitcoin wallet, rsk.co, also created by Mike Hearn).

However, we can see that several drawbacks of hashcoin remain unresolved.

Fortunately, the nLocktime issue was addressed in the BIP-0065 proposal on November 10, 2014, by adding a new OPCODE field in the form of a soft fork -- CHECKLOCKTIMEVERIFY. Allow transactions to be unavailable until a certain point in time.

Not to mention the specific changes, but the inclusion of this field makes one-way payment channels theoretically available (under certain conditions).

The proposal of two - way payment channel

We'll leave the BTC hash method alone for now. But the problem of one-way payment can be optimized without moving the bottom layer. On October 7, 2014, Alex Akselrod (now an engineer at lightning labs) first proposed a two-way payment channel. The core idea is to introduce a decreasing time lock, which allows the receiver to send funds to the sender a limited number of times. Although this scheme has never been implemented, we can still see what Alex thought at that time.

As you can see, the discussion based on this proposal revolves around relying on nLocktime to shift the payment role. For example, suppose Alice and Bob construct a two-way payment channel. Alice pays Bob. If Alice transfers 1 BTC to Bob and marks nLocktime as 1000 on this transaction, then Bob can reverse pay BTC to Alice, but the nlocktime of the transaction initiated by Bob will decrease from 1000. For example, 999, and each transaction initiated by Bob reduces the nLocktime, so Bob can only initiate a maximum of 1000 transactions.

So far, apart from the malleability of BTC itself, the foundation of Payment channel has been preliminatively completed.

Payment Network -- the only way to expand payment channel

With the above history of payment channel basically finished, we should look at the payment network next. Looking back at the Payment channel above, you can see that the entire idea of a payment channel is an interaction between two people. However, if A and B have A payment channel, and B and C have a payment channel, is it possible for A to pay C directly? (Another way to put this problem is the disadvantage of Hashcoin mentioned above. Without knowing who the counterparty is, How to transact using the payment channel)? So, after the first Payment channel was proposed (hashcoin), some bigwigs were already considering an offchain Payment network. Among them are core BTC developers like Petter Todd (the creator of BIP-0065 mentioned above) and Gavin Andresen (who was then the chosen successor of Satoshi Nakamoto's BTC development, but was later kicked out of the community for trusting the fake Satoshi Nakamoto). So, how do they do it?

Early idea

Similar to the payment channel, many ideas have been born before the Payment network is put into practice. One of the most famous ideas is Fidelity-bonded banks proposed by Petter Todd, a member of the BTC core developer group, on February 23, 2013: decentralized, auditable, private, off-chain payments, Off-the-chain transactions proposed by Gavin Andresen on 4 July 2012, And A proposal for fast POS transactions with Bitcoin by Corn Plooy (now a Lightning web developer who also works at the Dutch exchange BL3P) on 13 July 2011.

A detailed discussion of the first two proposals can be found in the links below. But in terms of design philosophy, the two ideas are very similar: Basically, a semi-trusted middleman is introduced (" semi-trusted "means that although the middleman cannot steal users' funds, the money in the Payment network cannot be withdrawn if the middleman chooses not to cooperate) to realize the function of an under-chain payment network. Petter Todd added the concept of privacy to this, while Gavin's idea was purely to solve the problem of payment.

However, we need to talk about the earliest Plooy solutions separately. The idea is more in line with our definition of a network in a payment network.

The black arrow is the standard BTC transfer process, but Plooy has added the red arrow to it, which is the essence of the off-chain settlement network. The whole process is roughly as follows:

1. buyer initiates a transaction to seller (in a standardized information format);

2. At the same time, the buyer will publish the transaction to the BTC network and carry out the regular confirmation steps of 6789;

3. On top of that, the buyer sends the transaction to a "fast verification network";

4. Nodes in the "Fast Verification network" will quickly verify the transaction according to the original data;

5. The rapid verification network will inform the seller of the preliminary test results within a few seconds;

6. The final settlement (verification) is verified through the classic BTC network. In the event of a double flower problem, the seller will be compensated by the node in the Fast Verification network.

As you can see from the figure above, Plooy's idea is to build a layer of fast settlement network on top of the traditional BTC network. So the core of this is on this layer of fast settlement network. The loss caused by problems such as double flower is paid by nodes in the rapid settlement network, which requires a clear accountability mechanism. In Pooly's design, this accountability system is based on the verification node signature received by the seller in Step 5. This indicates that the nodes in the fast verification network are not randomly linked like BTC nodes, but only when the two nodes trust each other, the link will be established, and then the responsibility can be traced layer by layer, and finally the end buyer can be traced. It is also because the accountability system requires end-buyers to pay up front before joining the fast verification network.

As you can see, Plooy's thinking still comes down to trust. It's not totally trust-free. But to come up with this design in 2011, that's pretty impressive. At the same time, it also provides a good reference for the subsequent several real landing projects.

Amiko Pay - the precursor to Lightning Network

Like hashcoin, Plooy didn't get off the ground, but people have been trying to refine the idea, Among them are BTC core developers and Gregory Maxwell (blockstream CTO) and Ryan Fugger(Ripple founder), among others. Finally, on July 22, 2012, an article. Combining Bitcoin and the Ripple to create a fast, scalable, decentralized, anonymous, low-trust payment network (draft 1) "Announced the birth of Amiko Pay.

Amiko Pay can be seen as Plooy's attempt to land on the ground. But in this draft, there is nothing to do with the Payment Channel, leaving the entire network still to be trusted: if one user refuses to settle a balance with another, there is nothing the other can do. Although a draft of the second edition was released on January 15, 2013, the content was not significantly changed.

Amiko Pay has been making changes in the following years, and finally (2015) designed a set of solutions without trust. However, due to the limitations of the programming model of BTC at that time, similar solutions were difficult to be implemented, and "certain" changes were needed to be made to BTC, which was finally failed. Amiko Pay last updated its roadmap in June 2016:

If you are more interested in Amiko Pay, in addition to the hyperlink attached to this article, you can also click on their homepage for more details:https://cornwarecjp.github.io/amiko-pay/.

However, just like what is written above, Amiko Pay itself does not combine the advantages of Payment channel well, so it gives others some opportunities and eventually becomes the former wave.

Sword! Lightning network is on the scene

Many of the heroes ahead have come to an end, but the remaining problems still need to be resolved. So before the main character, let's take a look at the current payment network and payment channel legacy problems.

· How to be trust-free?

· How to minimize changes to the BTC network?

The first problem is essentially the second problem that leads to no good solution. The question then becomes how to implement an efficient BTC payment network without trust within the limitations of the BTC programming model.

There was a lot of technology building up ahead, and with the BTC community talking about capacity expansion in 2015, we found that many important breakthroughs were made that year (blockstream was founded to work on related things even before the Flash Web white paper in its narrow sense). Among them, A Zurich paper, "A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels," was published in late 2015. The paper's solution relies heavily on time locks as a "countdown device" for channel validity, and a cryptographic technique called "null tree" to nullify stale channel transactions. This became the prototype of the technology that later became the lightning network's livelihood. The two authors of the paper, Christian Decker and Roger Wattenhofer, have since joined blockstream.

The right time, the right place, and the right people, the three are not good, although there is a plague of victory -- "Sun Bin's Art of War, The Month War"

2015 has been a hot year for BTC expansion (two notable Scaling Bitcoin Montreal in September and Scaling Bitcoin Hong Kong in December were organized in 2015), and the timing is right. The previous accumulation of numerous technologies and the two key designs presented in that paper pave the way for lightning networks, which are in the right place.

Well, it was the right place at the right time, except for one person and. Maybe that's the main character, and as 2015 comes to a close, Gregory Maxwells, one of BTC's core developers, summarized the discussion over Capacity increases for the Bitcoin system over the last few years. Capacity increases for the Bitcoin System is basically what the BTC community meant at the time. It's got a bite of Lightning Network in it. He was part of the founding team at blockstream. For more information about Maxwells' achievements, read a science project:https://academy.bit2me.com/en/who-is-gregory-maxwell/.

Anyway, for Lightning Network, it's time to perform! On February 23, 2015, The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments first draft was released at the BTC Dev conference in San Francisco.

Then, let's take a look at how lightning network is better than its predecessors. We'll look at it from two perspectives of optimization.

Payment channel (called Poon-Dryja channel in lightning network)

· Lightning Network extends the time span of both parties to infinity. The channel can remain as long as both parties want it to. The previous payment channel scheme needed to be closed before the nlocktime expired (otherwise it would be settled automatically).

· Payment is two-way and unlimited.

Payment network

· Use HTLC (hash time lock) to connect channels together and form a network. What does this thing mean? Other it contains the condition of two "or" relationships.

· Create A conditional payment. For example, A gives B money and B has to solve a problem to spend the money (it has to be B, not anyone else). That is, the recipient discloses a piece of information and provides proof of that information in order to spend the money. A more strict definition is: hash key lock, based on the unidirectional hash, can put a ciphertext hash value into the output of the transaction as a hash ciphertext lock, that is, you must input the ciphertext corresponding to the hash value to unlock the bitcoin in the script. For example, for example, Alice receives a 2BTC transfer, but the other party sets a hash value lock, so Alice must get the ciphertext of the transaction party and sign the transaction together with her own key, and then transfer the BTC to Bob.

· Wait until the specified time is up before you can spend the money. Until then, the transaction is not effective and cannot be executed. A more strict definition is to set the clock in the transaction script and wait for the set time before you can use the address's private key signature to unlock the bitcoin in the address. For example, Alice receives a 2 BTC transfer, but the other party has set 1000 blocks before unlocking it, so Alice must wait 1000 blocks before signing the transaction with her private key and spending the BTC to send to Bob.

So what exactly does Lightning Network do? We also know in the previous design, how to ensure the honesty of the two sides of the accounting is the lightning network needs to solve the problem. There are two things involved here :

· How do we know who did the evil

· How is evil punished

At this point, we need to look at how the Lightning network transfers several times on the payment channel. You can see the white paper for the detailed process and principle.

Today is mainly about history, so I will summarize the principle: Suppose A and B build a lightning network channel, for each transaction, there are actually 4 transaction proofs:

· Transfer records recorded in Ledger A

· Transfer records recorded in Book B

· Records recorded in Book A to void previous transactions

· Records recorded in Book B to void previous transactions

As we can see, these four proofs actually fall into two categories. But it should be noted that A and B's books record the same type of transaction certificate is different.

· Suppose A transfers A BTC to B, and now the total book is A: 4 B :6. At this time, the book of A and the book of B recorded the same content of the distribution of BTC, but the inconsistency was that in order to distinguish the malicious transactions sent by the perpetrators in the evil situation, the article was made on other information constituting the transactions. Suppose there is another transaction, and A transfers 1BTC to B. At this time, the transaction record should be A:3 B:7, but A wants to be evil and sends the last transaction to the chain first. At this time, Lightning network has an interesting design, in the transaction (A:4 B: 6) sent by A, The 6 BTCS of B can be immediately removed by B, but the 4 BTCS of A can not be removed until the hash time lock expires. In this way, the victim has time to react.

· This is where the records used to void the previous transaction come in handy. Assuming B discovers A's malicious behavior, he can immediately send the latest transaction record and the record of the previous canceled transaction to the chain. Since A has sent the transaction of 4 and 6 to the chain before, B can immediately retrieve its 6 BTCS, and then the function of the invalidation of the previous record is that B can immediately or get the 4 BTCS of A that need to wait for the expiration of the time lock. In other words, all 10 BTCS in the whole channel belong to B, and A is punished.

For linking different channels into a network, the HTLC above is used. Let's say A wants to transfer money from B to C. This process can be summarized simply as:

· C hashes A ciphertext to A, and A constructs a transaction to B, but this transaction can only be unlocked if B gets C's ciphertext. If it is not unlocked within the time limit, the money will be returned to A.

· Then B constructs a transaction to C, which also requires C's ciphertext C to unlock the transaction. In this way, once C gets the money, B also knows C's ciphertext, and can get A's money.

This is the general process of lightning network, just to mention, if needed later more details. Let's continue with the evolutionary history of lightning networks.

Several implementation of specific programs

Now that the white paper is available, it's a matter of implementation. We have discussed the plasticity problem of BTC before (transaction ID of B requires transaction HASH of A, while transaction HASH of A requires corresponding signature, but we have said before that the opening channel of lightning network requires the construction of transaction of B before construction of A, which is the problem of paradox cited above). To solve this problem, the Lightning network white paper mentioned the form of signaturehash-withoutinput to solve it (in short, no matter the input, only sign output), but it failed in the end. Instead, it used the later sigwit to achieve the same purpose.

And, not only that, because the first white paper contained so many technical concepts, few understood them thoroughly. But Rusty Russell, a longtime Linux kernel developer, read the white paper and the basics improved. In a series of blog posts in early 2015, Russell "translated" the white paper for a wider (but still selective) audience. In March of that year, Russell was invited to join Blockstream to develop the first lightning network implementation: C-lightning. Russell was later joined by Christian Decker of Blockstream; Others (including Corn Plooy) have also contributed to the open source project.

Shortly thereafter, a small company called ACINQ joined the Lightning Network research and announced on March 22, 2017 that it had written its own Lightning network protocol, eclair, in Scala.

But what about the Lightning lab we know? Well, they were set up in January 2016 by Poon and Dryja, two authors of the Lightning Network White Paper. And then you know, they did LND. And at the end of 2016 Dryja left Lightning Lab for MIT's Digital currency project, where he made LIT similar to LND (the difference is that it encapsulates wallets and nodes and supports multiple coins).

At the same time, due to the malleability problem, the well-known mining company Bitfury bifurcated lnd and balanced the malleability problem, creating a lightning network that could be used without solving the malleability problem of BTC. But now the project has stalled.

Later, Blockchain developed a simplified lightning network called Thunder, releasing alpha version of Thunder, the first actual lightning network, at the expense of "no trust." Even though it's dead now.

It can be found that the lightning network at that time is all kinds of, so every time at this time, there will always be a meeting to regulate everyone, so that everyone can exchange things. The conference was the Scaling Bitcoin Milan Triplex in October 2016. At this meeting, the parties agreed to interoperate, resulting in a Basis of Lightning Technology protocol called "BOLT". So the Lightning Network Whitepaper was theoretical first, and BOLT was the foundation of the actual Lightning network as we know it today.

Towards usability

As for another story line, it revolves around the extension of btc. From the previous CLTV (CheckLockTimeVerify) proposed by Petter Todd in 2015, to the implementation of relative time locking (CSV, CheckSequenceVerify), to the upgrade of segwit, Finally let the lightning network officially enter the application stage. In October 2016, less than half a year after segNet was deployed, Decker of blockstream bought a "cat" from Russell using c-lighting.

This is also known as "First Blitz of the Lightning Network".

Then, in January 2017, LND released its alpha version. It wasn't until the summer of '17 that quarantine Witness was activated. blockstream announced the first BTC mainnet Lightning network transaction three months later, and in November, Lightning Labs made the first Lightning network transaction across the blockchain (from Bitcoin to Litecoin). In December, the development teams from Blockstream, Lightning Labs, and ACINQ announced that they had passed interoperability tests.

By the end of the year, more and more lightning tunnels were opening. In December, developer Alex Bosworth paid his cell phone bill to Bitrefill, a payment processor: one of the first transactions using Bitcoin as cash on Refill.

A month later, Blockstream opened an online store that lets people buy physical goods with Bitcoin -- though the c-lightning implementation is still in beta. In February 2018, while Lightning was still in its alpha phase, Lazlo Hanyecz, a legend in the bitcoin world known for his "bitcoin for pizza" fun, announced that he had used Lightning to buy pizza.

The rest of the story goes smoothly. Various lightning network schemes have been implemented, and the related ecology has been gradually improved. These are the historical events that I have found important about the Lightning Network so far.

summarize

The first conclusion: the wisdom of genius is always so "worthless".

A second conclusion, if you look at the story of the two authors of the Lightning White Paper, is that geniuses do things.

Their major achievements are as follows:

Thaddeus DryjaI made a project called mirro, point-to-point trading system, and joined the concept of prediction market. Dagger Hashimoto was a predecessor of the PoW algorithm (Hashimoto) before ethash came online:http://diyhpl.us/~bryan/papers2/bitcoin/meh/hashimoto.pdf.

Another author,Joseph Poon"And one of the authors of plasma. Channel-based Lightning network is proposed in BTC and chain-based plasma is proposed in Ethereum. There was also handshake(https://handshake.org/) and a project that followed the namecoin idea. Of course, cutting or not cutting is not part of our discussion.

Finally, attached is our timeline of major events related to the Lightning network:

Image credit: CYC Collation

Literature reference:

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

https://bitcoinmagazine.com/technical/history-lightning-brainstorm-beta

https://voltage.cloud/blog/bitcoin-lightning-network/life-of-lightning/

https://en.wikipedia.org/wiki/Lightning_Network

https://bitcointalk.org/index.php?topic=146307.0

http://gavintech.blogspot.com/2012/07/off-chain-transactions.html

https://bitcointalk.org/index.php?topic=28565.msg359408#msg359408

http://www.ultimatestunts.nl/bitcoin/ripple_bitcoin_draft_1.pdf

https://bitcointalk.org/index.php?topic=91732.msg1010405#msg1010405

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/006988.html

https://en.bitcoin.it/wiki/User:Aakselrod/Draft

https://www.strawpay.com/docs/stroem-payment-system.pdf

https://tik-old.ee.ethz.ch/file//716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf

https://montreal2015.scalingbitcoin.org/

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

https://lightning.network/lightning-network-paper.pdf

https://github.com/mpegavi/bitcoincn/blob/master/%E6%AF%94%E7%89%B9%E5%B8%81%E9%97%AA%E7%94%B5%E7%BD%91%E7%BB%9C%E7%99%B D%E7%9A%AE%E4%B9%A6%EF%BC%9A%E5%8F%AF%E6%89%A9%E5%B1%95%E7%9A%84%20off-chain%20%E5%8D%B3%E6%97%B6%E6%94%AF%E4%BB%98%EF%B C%88%E4%B8%AD%E6%96%87%EF%BC%89.pdf