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
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 proposed solution to the bitcoin scalability problem. The network would use an off-chain protocol and is currently under development. It would feature a P2P system for making micropayments of digital cryptocurrency through a scale-free network of bidirectional payment channels without delegating custody of funds or trust to third parties.

It is expected that 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 relies on Segregated Witness (SegWit).

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}$.

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), and ACINQ (eclair). The specification is available on Github, and its largest contributor is Rusty Russell of Blockstream.

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

In December 2017 three different entities were working on creating software implementations, ACINQ, Lightning Labs, and Blockstream and in the same month test transactions had been made on the testnet. Payment provider Bitrefill tweeted in December 2017 claiming it was the first lightning transaction operating on the Bitcoin network.

In April 2017, Syscoin has confirmed it has introduced the Lightning Network (LN) on its mainnet, becoming the first cryptocurrency to achieve the milestone.

External links

• http://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?