Lightning network

Lightning network
Visualization of the topology of the Lightning network in May 2018
Basic data
Maintainer	Joseph Poon, Thaddeus Dryja
developer	Elements Project ( Blockstream ) Lightning Labs ACINQ WITH DCI
Publishing year	2018
Current version	0.9.0 ( July 31, 2020 )
programming language	C , Go , Java
category	Cryptocurrency
License	WITH
lightning.network

The Lightning Network is a protocol for scaling from block chain technologies. It was proposed in July 2015 through a white paper by Joseph Poon and Thaddeus Dryja. In the following years, a detailed specification was developed and, based on this, several independent implementations were developed, on the basis of which a network of payment channels was created, which in May 2019 had a capacity of approx. 1000 Bitcoin.

History of origin

The basic idea of payment channels goes back to Satoshi Nakamoto . However, his implementation idea was not certain. There were some similar ideas in the following years, and in 2012 Meni Rosenfeld already described a construction that is similar to today's Lightning Network in many ways. Technical complications (such as transaction malleability, which was only resolved by Segregated Witness ) and a lack of motivation - because Bitcoin itself was still little used - prevented decisive progress for a long time.

When the price of a bitcoin exceeded $ 1000 for the first time towards the end of 2013 , it became clear that the blockchain, on which the Bitcoin network is based and which does not allow any number of transactions per second , would have a problem with scalability. The number of transactions was limited by the block size of 1 megabyte , the storage space required by a transaction and the block time of statistically about ten minutes. As a result, only about 7 financial transactions per second could be carried out on the Bitcoin blockchain worldwide . Credit card providers process significantly more transactions with around 40,000 payment transactions per second. The developers of the Bitcoin protocol agreed that the problem of scalability had to be solved so that Bitcoin actually fulfills the monetary function of a medium of exchange and there is a realistic chance that Bitcoin will be accepted as a currency by people.

Discussions arose within the Bitcoin developer community about how to solve the scalability problem of the Bitcoin network. The most prominent proposed solutions were increasing the block size and introducing layer 2 solutions such as the Lightning Network. The majority of Bitcoin developers preferred the Lightning Network, while the minority faction split off to Bitcoin Cash and increased the transaction capacity there with 32 megabyte blocks. In order to enable the development and implementation of the Lightning network, however, the Segregated Witness update of the Bitcoin protocol was required . This was difficult to achieve due to the decentralization of the Bitcoin network, as the community had to agree on the implementation of the update. In August 2017, a mechanism in the Bitcoin protocol for finding consensus made it clear that over 90% of the Bitcoin mining power in the network supported the update. This majority was enough to carry out a soft fork of the Bitcoin protocol.

Regardless of the outcome of the vote, several projects were created in 2016 that dealt with the development of the Lightning network as open source software. On the one hand the Elements project, which is close to Bitcoin Core and the Blockstream company and is developing an implementation in C with c-lightning . Christian Decker and Rusty Russell carried out the first successful tests of this project in October 2016. Second, the currently most advanced implementation Ind Company Lightning Labs , which in the language of Go is implemented. The French company ACINQ is also developing an implementation in Scala called eclair , which is available as a mobile wallet for Android devices , among other things .

The Australian developer Rusty Russell from Blockstream plays a central role in the development of the protocol . Russell, who was previously recognized as one of the strongest Linux developers by Linus Torvalds , developed an RFC standard for the Lightning network based on the white paper . All implementations should follow this standard.

functionality

The core element of the Lightning network is the so-called payment channel (Payment Channel). With the help of a channel, two nodes in the network can send each other amounts of money free of charge using a 2-2 multi- signature wallet and thereby update the balance of the channel up to a previously defined upper limit. After an initial funding transaction to open the channel, the nodes themselves can carry out any number of additional transactions with one another without saving them in the blockchain , which relieves the load and improves scalability. To do this, after each payment they record the current balance in a commitment transaction that must be signed by both nodes. The idea thus corresponds to the current account in classic commercial law, although the claims are only offset when one of the participants closes the channel by publishing a settlement transaction . Only this saves the final balance of both parties in the last commitment transaction back into the blockchain. Unlike the current account, the two parties that form the channel do not have to trust each other. Nevertheless, the transactions in the payment channel only take place with the knowledge of the two actors. The throughput of the payment channel is only limited by the latency and throughput of the TCP socket used . According to Christian Decker, around 500 transactions per second are currently possible in one payment channel. The protocol for managing a channel is constructed using hashed time locked contracts so that fraudulent behavior (e.g. publication of an older commitment transaction) within a payment channel can be reported by the other party. The Bitcoin network checks the attempted fraud and sanctions fraudulent behavior by paying out the entire amount of money from the channel to the victim .

Another core idea of the Lightning Network is the routing of payments through the network. As soon as a meshed network is created between the participants by opening payment channels to several nodes , payments can be made between any two nodes, even if they are not directly connected to one another by a payment channel. Nodes that are only supposed to forward the amount cannot steal it, as it is secured again by a hashed time locked contract and a secret - the so-called payment pre-image - which only the receiving node knows. Routing thus enables participants to carry out transactions with any other network participants after a bilateral payment channel has been created. Through onion routing , as it is e.g. B. is used in the Tor network , the privacy of the participants should also be protected. In particular, finding routes and managing routing tables still has most of the need for development.

distribution

In December 2017 it became known for the first time that the 3 implementations passed all 75 integration tests and are therefore actually compatible with each other. In January 2018 published block stream with Lightning Charge a Node.js server that is a REST - API provides to use the Lightning network. LApps (lightning apps) were created, which offer services primarily in the field of micropayments . In March 2018, an implementation for the Bitcoin network was released as a beta for the first time . Blockstream also presented several Lightning apps that can be used for payment services on the web. The “Eclair Wallet” followed in April with Lightning support for Android. The number of nodes in the Lightning network is growing and currently consists of over 8,000 nodes with over 35,000 payment channels and a total capacity of over 1000 Bitcoin (as of May 23, 2019). From the developer's point of view, however, the network itself is still in the pioneering and testing stage and, due to a fixed upper limit for the balance of payment channels, cannot yet be used for large financial transactions.

properties

The Lightning Network, by design, has several desirable properties for solving Bitcoin's scalability problem. These include low fees, which enable micropayments in particular . In addition, the privacy of the participants in the network is higher than in the Bitcoin network.

Marginal Transaction Fees

The Lightning network makes it possible to transfer money back and forth within a payment channel free of charge. Nodes can charge fees for routing . These should probably not be higher than one satoshi per hop . Therefore, with the Lightning network, money can be transferred in real time for the first time worldwide, practically free of charge.

Micropayments

Since the transaction fees in the Lightning network do not increase as the number of users grows, but instead potentially decrease, the Lightning network is particularly - but not exclusively - suitable for micropayments.

privacy

The Lightning Network Protocol works without the publication of individual transactions in a payment channel. This means that privacy is significantly higher than with the Bitcoin network, where all transactions are stored in the public database. The blockchain only saves account balances when the payment channels are opened and closed. Only the nodes themselves know which individual transactions make up the difference.

Second layer protocol

The Lightning Network Protocol can be understood as an abstraction layer above a blockchain. It would therefore be possible to make transactions between two different blockchains (so-called atomic swaps ) if both meet all the necessary requirements for the Lightning network.

technology

The Lightning network conceptually has two layers that build on each other. The basis is provided by bidirectional payment channels, which make it possible to send amounts of money back and forth between two participants as often as required up to a previously defined upper limit. It is important that the two parties do not have to trust each other or a third party. As a decentralized system, the blockchain (e.g. Bitcoin) provides trust. A network is set up from these payment channels as the second level, whereby payments between two participants can be sent through the payment channels of other participants. The special feature that applies to the construction of the network is that you do not have to trust the participants in the payment channels at any point, since the blockchain also acts as a trustworthy authority here.

Bidirectional payment channels through Revocable Sequence Maturity Contracts

In the current implementations, the bidirectional payment channels are based on so-called RSMCs (English Revocable Sequence Maturity Contracts ). Two other designs for bidirectional payment channels are known. On the one hand, Christian Decker presented in his dissertation at the ETH Zurich an approach with which one can operate a payment channel with the help of invalidation trees. In addition, Christian Decker, Rusty Russell and Olaoluwa Osuntokun presented “eltoo” in May 2018. With eltoo, payment channels can be implemented with significantly less effort, but a soft fork of the Bitcoin protocol is required, which was proposed as BIP118. The core idea of all known constructions of payment channels is based on transferring an amount (the capacity) to a 2-2 multi-signature wallet and then jointly negotiating transactions from this wallet back to the parties, which encodes the balance of the payment channel between the parties . However, in the normal case, these transactions are not published to the Bitcoin network, but are renewed in order to make a payment. The main problem now is the invalidation of old transactions, so that old balance sheets cannot be published to the Bitcoin network. The following describes the construction of the payment channels and invalidation of old balance sheets based on RSMCs.

Open payment channels

To open a payment channel between parties A and B, two nodes jointly agree to transfer an amount to a 2-2 multi-signature wallet. This happens in the so-called “Funding Transactions”. Before these transactions, however, to the Bitcoin network gebroadcastet are two commitment transactions are created (one for each party) responsible for issuing the Funding Transaction and back transfer the amount provided each party back to the party. Only when both sides have the commitment transaction signed by the other side are the funding transactions broadcast and the payment channel created. The commitment transactions are important so that each side can close the channel - even without the additional consent of the other party. The commitment transactions - although they are signed - are not initially broadcast to the network. Its purpose is to encode the channel's balance sheet and ensure that both parties have the option of closing the channel again without the consent of the other. The commitment transactions have two outputs. One for each party. In Party A's commitment transaction, however, the output to Party A is tied to an RSMC. This means that A can only issue the output after a certain number of blocks after the commitment transaction has been mined. The amount can only be spent beforehand if the so-called revocation keys of both parties are known for this commitment transaction . This script in the Bitcoin transaction is OP_CHECKSEQUENCEVERIFYmade possible by what became part of the Bitcoin protocol through the activation of BIP112. The script with which the output that is normally due to party A can be output looks (simplified) as follows:

OP_IF
   144 OP_CECKSEQUENCEVERIFY
   OP_HASH160 <A's key>  OP_EQUALVERIFY OP_CHECKSIG
OP_ELSE
   2 <Revocation Key von A><Revocation Key von B> 2 OP_CHECKMULTISIGVERIFY
OP_ENDIF

Make payments

So that payments can be made within a channel, a new commitment transaction is agreed for each side in the channel. This outputs the funding transaction - i.e. the capacity on the multi-signature wallet - differently than before and thus leads to new ownership of the multi-signature wallet. Before the new commitment transaction can be signed, the signature and revocation keys of the previous commitment transaction are exchanged using a type of Diffie-Hellman key exchange. The revocation key enables the opposite party to transfer OP_CHECKSEQUENCEVERIFYall outputs of the old commitment transaction to their own Bitcoin wallet for a time window. This punishment creates a threat to publicize your old commitment transactions. This effectively creates the possibility to invalidate old commitment transactions and to ensure that only the most recent pair of commitment transactions is always used as the authoritative source for the balance sheet of the channel. It is important to use new revocation keys in the commitment transaction for every update of the payment channel. In addition, all old revocation keys must be kept, as nothing else can be done against potentially fraudulent behavior by the other party. It is also a good idea to delete your own old commitment transactions so that they are not published accidentally, e.g. due to a software bug.

Close payment channel

Channels can be closed unilaterally by publishing the current commitment transaction on the blockchain. However, your own part of the balance sheet can only be output after the timelock. For this reason, it is also important to keep your current revocation key secret. However, if the two parties work together, they can spend the output of the funding transaction through a settlement transaction that reflects the current balance of the channel. In the settlement transaction, the outputs for each party can be OP_CHECKSEQUENCEVERIFYagreed without, so that, as soon as the transaction has been accepted by the Bitcoin network, they can be issued again without timelock. As soon as you have agreed on such a settlement transaction, you really have to inform the Bitcoin network and close the channel, as you can no longer use the payment channel without trust.

Network of payment channels through hashed time locked contracts

The essential technology that enables the routing of transactions without trust of the participating payment channels are the hashed time locked contracts , or HTLC for short . The idea is to agree on another output (the HTLC) in the commitment transactions. This can only be issued by the receiving party within a time window if they can still provide a secret. The hash of the secret is in the script, which is necessary to output this additional output. If the secret is not OP_CHECKSEQUENCEVERIFYprovided by the receiving party within a specified number of blocks after the commitment transaction has been confirmed by the Bitcoin network, only the sending party can issue the output. The routing of a payment takes place in that a chain of conditional transactions is carried out on a path from the sending party to the receiving party. All of these transactions involve the same hash. As soon as the receiving party requests their payment, they must provide the secret in their payment channel. The secret is now passed backwards along the way to the sending party. Neither party can steal or withhold funds in this way. On the contrary. If you do not conform, you run the risk of not getting your payment back. In particular, the commitment transactions do not have to be published as soon as the secret becomes known. It is sufficient to carry out a new update of the channel in which the HTLC output is removed and the amount is assigned to the receiving party.

Onion routing

The core idea of onion routing is that, in contrast to IP routing, a packet with sender and recipient addresses is not created which is then routed through the network. Rather, a sender must first find a path through the network. Transactions can now be nested within each other for each hop. This increases privacy because the individual accounts only know on the way who they are receiving money from and to whom they have to forward the money. Nodes may withhold part of the payment as a fee for the service of forwarding payments. This fee is communicated to the network by the nodes via the Gossip protocol and can be taken into account when calculating the paths.

Controversies and Risks

Backing up a payment channel is dangerous. If nodes import an old backup, they could inadvertently publish an old commitment transaction. This could be seen by the other side as an attempt of fraudulent behavior and lead accordingly to the loss of the bitcoins.

In February 2018, it was announced on the developer mailing list that the Lightning network enables a new form of 51% attacks on the Bitcoin network. In this it is not only possible to spend your own bitcoins twice, but you can steal the sum of all bitcoins in your own payment channels. However, since a 51% attack becomes increasingly unlikely as the network grows and also poses a threat to the Bitcoin network, this risk can be neglected from the developer’s point of view. Bitcoin developer Peter Todd warned that the Lightning network was susceptible to DoS attacks .

At the moment, payments cannot always be routed successfully in the Lightning Network. An analysis by Diar.co has shown that there is currently a 100% probability of a successful payment only for amounts below 3 cents. From around 5 euros, the probability of finding a route falls below 50%; at 50 euros this is only about 10%. This is due to the lack of liquidity in the network. The white paper recommends arranging the network to match the banking network or tier 1 network . With this structure as hub and spoke, a participant in the network does not have to have the entire routing table .

Cross-country tests of the Bitcoin-based payment network Lightning showed that not only sender and recipient need sufficient liquidity for transfers, but also all nodes between them. Sometimes transferring parties could only make transfers by dividing the transfer amount into partial amounts.

Others temporarily borrowed bitcoin to accept a transfer.

Web links

Introductory lecture on Wikimedia Commons

Individual evidence

↑ Release 0.9.0 . July 31, 2020 (accessed August 1, 2020).

^ Joseph Poon, Thaddeus Dryja: The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. (PDF; 3 MB) January 14, 2016, accessed June 30, 2018 (English).

^ Lightning Network Search and Analysis Engine. Retrieved May 23, 2019 .

^ Aaron van Werdenum: The History of Lightning: From Brainstorm to Beta. Accessed August 6, 2018 .

↑ heise online: Segregated Witness: Protocol change should make Bitcoin more efficient. Retrieved April 16, 2018 .

↑ SegWit was successfully activated on the Bitcoin blockchain | BTC-ECHO . In: BTC-ECHO . August 24, 2017 ( btc-echo.de [accessed April 16, 2018]).

↑ The first impact: Christian Decker and Rusty Russel from Blockstream test the Lightning prototype . In: BitcoinBlog.de - the blog for Bitcoin and other virtual currencies . October 6, 2016 ( bitcoinblog.de [accessed April 16, 2018]).

↑ lightningnetwork / lightning-rfc. Retrieved April 16, 2018 .

^ Scaling, Layer 2 And Cryptographic Innovations Discussed At Consensus 2018 - Coinjournal. Retrieved May 18, 2018 (American English).

^ Lightning Protocol 1.0: Compatibility Achieved. In: Lightning Developers. December 6, 2017, accessed April 16, 2018 .

↑ Lightning Charge Powers Developers & Blockstream Store. Retrieved April 16, 2018 .

↑ Bitcoin Lightning App: Paypercall shows the full Lightning power. Retrieved April 16, 2018 .

^ Lightning Network Search and Analysis Engine. Retrieved May 23, 2019 .

^ Decker, Christian: On the Scalability and Security of Bitcoin . 2016, doi : 10.3929 / ethz-a-010619000 ( hdl.handle.net [accessed April 16, 2018]).

↑ Christian Decker, Rusty Russell, Olaoluwa Osuntokun: eltoo: A Simple Layer2 Protocol for Bitcoin. (PDF) Retrieved July 21, 2018 .

↑ Christian Decker: BIP118. Retrieved July 22, 2018 .

↑ BtcDrak, Mark Friedenbach, Eric Lombrozo: BIP112. Retrieved July 22, 2018 .

↑ Bitcoin Lightning Network: Failure resulted in loss of bitcoins. Retrieved April 16, 2018 .

^ [Lightning-dev] New form of 51% attack via lightning's revocation system possible? Retrieved April 16, 2018 .

↑ root: Bitcoin developer warns Lightning Network is vulnerable to DoS attacks. (No longer available online.) In: Münze News Telegraph. Formerly in the original ; accessed on April 16, 2018 . ( Page no longer available , search in web archives ) Info: The link was automatically marked as defective. Please check the link according to the instructions and then remove this notice.@1@ 2
↑ Lightning network: Successful routing decreases rapidly as the amount increases. BitcoinBlog.de - the blog for Bitcoin and other virtual currencies, June 27, 2018, accessed on July 12, 2018 .
^ Joseph Poon, Thaddeus Dryja: The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments. (PDF) Retrieved July 12, 2018 (English).
↑ Lightning torch relay shows drastic liquidity problems Christoph Bergmann, Bitcoinblog.de , March 15, 2019.