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 and minimizing trust of third parties.

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, followed by closing the payment channel by broadcasting the final version of the transaction to distribute the channel's funds.

The specification for using the Lightning Network uses Segregated Witness (SegWit).

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). 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 CEO Elizabeth Stark announced the early phase release version of lnd 0.4-beta for developers with the intent on making it available for testing purposes.

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 bi-directional 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. Also, due to the burdensome nature of the Lightning Network's dispute mechanism which requires all users to watch their full nodes constantly for fraud, a new concept has been introduced called "watchtowers" where trust is outsourced to watchtower nodes to monitor their channel payments for fraud.

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