Lightning Network

Lightning Network

Routing through an idealized mesh network of payment channels.
Original author(s)	Joseph Poon, Thaddeus Dryja
Developer(s)	Elements Project (Blockstream) Lightning Labs ACINQ MIT DCI
Preview release	1.0 RC / 6 December 2017 (2017-12-06)
Written in	C, Go, Scala
Type	Cryptocurrency
Website	lightning.network

The Lightning Network is a "second layer" payment protocol that operates on top of a blockchain (most commonly Bitcoin). It enables instant transactions between participating nodes and has been touted as a solution to the bitcoin scalability problem. It features a peer-to-peer system for making micropayments of digital cryptocurrency through a network of bidirectional payment channels without delegating custody of funds.

Normal use of the Lightning Network consists of opening a payment channel by committing a funding transaction to the relevant blockchain, followed by making any number of Lightning transactions that update the tentative distribution of the channel's funds without broadcasting to the blockchain, optionally followed by closing the payment channel by broadcasting the final version of the transaction to distribute the channel's funds.

To perform as intended, Lightning Network requires a transaction malleability fix, such as Segregated Witness (SegWit) in Bitcoin.

History

Joseph Poon and Thaddeus Dryja wrote the Lightning white paper. The specification was announced after the paper, and is being developed by multiple parties, including Elements Project (c-lightning, depending on Bitcoin Core/bitcoind), Lightning Labs (lnd, depending on btcsuite/btcd or Bitcoin Core/bitcoind), and ACINQ (eclair, depending on Bitcoin Core/bitcoind).

The specification is available on Github, and its largest contributor is Rusty Russell of Blockstream.

The public alpha release of lnd was made on 10 January 2017. The Release Candidate (RC1) of the Lightning protocol specification was released on 6 December 2017.

In December 2017, three different entities working on creating software implementations, ACINQ, Lightning Labs, Blockstream, performed a series of interoperable test transactions. There is also an implementation by the MIT DCI that uses a different specification. Payment provider Bitrefill tweeted in December 2017 claiming it was the first lightning transaction operating on the Bitcoin network.

On January 4, 2018. TorGuard became the first VPN provider to accept payments via mainnet Lightning network while covering any potential losses of funds when sending Lightning payments.

In January 2018 Blockstream launched a payment processing system for web retailers called "Lightning Charge," and noted that lightning was live on mainnet with 60 nodes operating as of January 18, 2018, and should be considered "in testing."

On March 15, 2018, Lightning Labs CEO Elizabeth Stark announced the initial release of lnd 0.4-beta for developers with the intent on making it available for testing purposes on the main bitcoin network. The released also included Litecoin support.

On March 28, 2018 ACINQ released desktop version of eclair software for mainnet.

On April 4, 2018 ACINQ released Android version of eclair software for mainnet.

In April 2018, the eclair wallet was removed from the Google Play store for a few days because the app developer lost the private signing key making it unable to be updated for critical bugs.

In April 2018, Btcduke.com becomes the first bitcoin-to-fiat exchange in the world to accept main net lightning network deposits and withdrawals.

In May 2018, Vaultoro.com becomes the first bitcoin-to-gold exchange in the world to accept main net lightning network deposits.

2018 DDoS attacks

On March 20, 2018, Lightning Network nodes faced a Distributed Denial of Service (DDoS) attack that sent around 200 nodes offline, down from around 1,050 to 870. The exploit used as many node connections as possible to prevent any new connections. A month earlier in February, Bitcoin Core developer Peter Todd said the Lightning protocol could very well "prove to be vulnerable to DoS [denial of service] attacks in its current incarnation." According to the cryptographer, this poses danger to both the peer-to-peer as well as the blockchain level of the project.

Design

The payment channels allow participants to transfer money to each other without having to make all their transactions public on the blockchain. This is done by penalizing uncooperative participants. When opening a channel, participants must commit an amount (in a funding transaction, which is on the blockchain). Time-based script extensions like CheckSequenceVerify and CheckLockTimeVerify make the penalties possible.

If we presume a large network of channels on the Bitcoin blockchain, and all Bitcoin users are participating on this graph by having at least one channel open on the Bitcoin blockchain, it is possible to create a near-infinite amount of transactions inside this network. The only transactions that are broadcast on the Bitcoin blockchain prematurely are with uncooperative channel counterparties.

— Lightning Paper

The CheckSequenceVerify (CSV) Bitcoin Improvement Proposal details how Hash Time-Locked Contracts are implemented with CSV and used in Lightning.

Commitment transactions

If Alice and Bob have a payment channel, both of them also have a "latest" commitment transaction. A commitment transaction divides the funds from the funding transaction according to the correct allocation between Alice and Bob. For example, if Alice owns 1.0 mBTC (equal to 0.001 bitcoins or 100000 satoshis) and Bob owns 1.0 mBTC in the channel, the commitment transactions divide the total channel funds in that way.

Commitment transactions allow multiple users to participate in a single transaction (and thus act as a single entity), using a multi-key system. Determination of congestion falls primarily on the miners, so this network rests on the assumption that honest miners will not organize a 51% attack.

Since commitment transactions spend the funding transaction, they must be signed by both partners.

Commitment transactions are actually a pair of asymmetrical transactions. Alice's commitment transaction contains two outputs: one which pays Bob outright, and another which is a timelocked, revocable output that eventually pays Alice. The revocable output may be revoked by Bob if Bob knows the revocation key. Bob's commitment transaction is the reverse: it pays outright to Alice, but pays Bob's share under a timelocked, revocable output; if Alice knows the revocation key to Bob's commitment transaction, she can revoke it.

Initially, Alice holds the $A_{1}$ commitment transaction, and Bob holds the $B_{1}$ commitment transaction. The revocation key for $A_{1}$, $R_{A_{1}}$, is known by Alice, but not by Bob; the revocation key for $B_{1}$, $R_{B_{1}}$, is likewise known only by Bob.

Suppose Alice decides to pay Bob 0.25 mBTC (before this, each owns 1 mBTC):

1. Alice creates a new Bob's transaction, $B_{2}$, which allocates 0.75 mBTC to Alice and 1.25 mBTC to Bob.
2. Alice signs $B_{2}$ and sends to Bob.
3. Bob receives $B_{2}$, signs it, and keeps it.
4. Bob creates a new Alice's transaction, $A_{2}$, which allocates 0.75 mBTC to Alice and 1.25 mBTC to Bob.
5. Bob signs $A_{2}$ and sends to Alice.
6. Alice receives $A_{2}$, signs it, and keeps it.
7. Alice provides $R_{A_{1}}$, invalidating $A_{1}$; she can then delete $A_{1}$.
8. Bob provides $R_{B_{1}}$, invalidating $B_{1}$; he can then delete $B_{1}$.

Limitations

The Lightning Network is made up of bidirectional payment channels between two nodes which combined create smart contracts. If at anytime either party drops the channel, the channel will close and be settled on the blockchain. Due to the nature of the Lightning Network's dispute mechanism which requires all users to watch the blockchain constantly for fraud, the concept of a "watchtower" has been developed, where trust can be outsourced to watchtower nodes to monitor for fraud.

Criticisms

Opponents of the Lightning Network have been quick to point out design flaws in the off-chain network which has been cited as a scaling solution to Bitcoin's scaling problems, citing various issues such as the path-routing problem which could make it difficult or even impossible to find payment routes. In addition other opponents of this second layer solution such as Yours CEO Ryan Charles explain in clear terms how the Lightning Network can not work smoothly, where opening and closing channels will not happen instantly and users must be online at all times to receive a payment, in addition to other problems. Also, when payment channels are used, funding them requires two on-blockchain transactions (to open and then close the channel) making single-use Lighting Network payment channels more expensive than doing a single on-blockchain Bitcoin transaction.

Others have criticized the Lightning Network saying it's impossible for the network to be decentralized, saying it will lead to a hub-and-spoke model of centralized hubs on the network. Some solutions to the path-routing problem have been suggested such as Flare, but are also subject to centralisation by using trusted master nodes, called 'beacons'. Some fear due to the centralizing nature of Lightning Network, it will lead to "Lightning Banks" where legislators may be able to target them in an attempt to regulate the system.

External links

• http://dev.lightning.community/
• https://lists.linuxfoundation.org/pipermail/lightning-dev/ on the Linux Foundation servers
• What is the Lightning Network and how can it help Bitcoin scale?
• https://1ml.com/ Lightning Network Search and Analysis Engine