Lightning Network

Lightning Network is a proposed implementation of Hash Time Locked Contracts (HTLCs) with bi-directional payment channels which allows payments to be securely routed across multiple peer-to-peer payment channels. This allows the formation of a network where any peer on the network can pay any other peer even if they don't directly have a channel open between each other.

Key features

Key features of the Lightning Network proposal include,

• Rapid payments: payments within an established channel can be made almost as fast as data can travel over the Internet between the two peers.
• No third-party trust: the two peers in a channel pay each other directly using regular Bitcoin transactions (of which only one is broadcast) so at no point does any third party control their funds.
• Reduced blockchain load: only channel open transactions, channel close transactions, and (hopefully infrequent) anti-fraud respends need to be committed to the blockchain, allowing all other payments within Lightning Network channels to remain uncommitted. This allows Lightning Network users to make frequent payments secured by Bitcoin without placing excessive load on full nodes which must process every transaction on the blockchain.
• Channels can stay open indefinitely: as long as the two parties in the channel continue to cooperate with each other, the channel can stay open indefinitely -- there is no mandatory timeout period. This can further reduce the load on the blockchain as well as allow the fees for opening and closing the channel to be amortized over a longer period of time.
• Rapid cooperative closes: if both parties cooperate, a channel can be closed immediately (with the parties likely wanting to wait for one or more confirmations to ensure the channel closed in the correct state). Non-cooperative closes (such as when one party disappears) are also possible but they take longer.
• Outsourcable enforcement: if one party closes a channel in an old state in an attempt to steal money, the other party has to act within a defined period of time to block the attempted theft. This function can be outsourced to a third-party without giving them control over any funds, allowing wallets to safely go offline for periods longer than the defined period.
• Onion-style routing: payment routing information can be encrypted in a nested fashion so that intermediary nodes only know who they received a routable payment from and who to send it to next, preventing those intermediary nodes from knowing who the originator or destination is (provided the intermediaries didn't compare records).
• Multisignature capable: each party can require that their payments into the channel be signed by multiple keys, giving them access to additional security techniques.

Technologies & Techniques

The Lightning Network design makes use of a number of different technologies and techniques, many of which were either developed separately from Lightning or which can be useful in constructing other types of advanced payment channels (such as Duplex Payment Channels) as well as other smart contracts.

Hash locks

Bitcoin's Script language currently provides five opcodes that hash data contained within a transaction. The Script page describes a transaction that uses one of these hash functions to create a "transaction puzzle", a transaction output which can only be spent by someone who can satisfy this encumbrance:

OP_HASH256 6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000 OP_EQUAL

The encumbrance above will take the data on the top of the stack (not shown), hash it with the sha256d function (creating a computed hash), and compare it to the string 6fe2...0000 above (the provided hash). If the computed hash equals the provided hash, then the encumbrance is satisfied and the output can be spent.

The Script page tells us that provided hash is the hash of the Genesis Block header, so the data necessary to satisfy this encumbrance is the header of the Genesis Block. Someone has already done that, so if we look up the transaction on the blockchain that spent this output, we would see that Genesis Block header in one of that transaction's scriptSigs.

Had the provided hash above been the hash of some high-entropy (random) data, the encumbrance wouldn't be a puzzle---it'd be a lock that could only be opened by revealing the randomly-generated data used to create the hash. By revealing that data (called a pre-image), the hash lock is rendered unusable for further security since everyone now has the key (the pre-image) and can do whatever they want to the funds encumbered by the hash lock. For this reason, outputs protected by hash locks should also be protected by signatures so that both a correct pre-image and an appropriate signature are required to spend the funds.

However, hash locks have the very useful property that multiple outputs can all be encumbered by the same hash lock, so that if the person who has the pre-image reveals it in order to spend their encumbered funds, everyone else who has an output encumbered by the same hash lock can get the pre-image they need from the first person's transaction on the blockchain.

This property allows payments to be routed through third parties without any risk that the third-parties will take the payment for themselves. For example,

• Dan creates a pre-image with 256 bits of entropy (randomness) and hashes it with the sha256d function, creating a hash.
• Dan gives the hash to Alice.
• Alice pays an output encumbered to Bob's public key plus the hash generated by Dan.
• Bob spends one of his previously-received outputs to Charlie, setting the amount to the same amount Alice paid him (minus fees) and setting the encumbrance to Charlie's public key plus the hash generated by Dan
• Charlie does the same as Bob, setting the encumbrance to Dan's public key plus the hash Dan generated

Now whenever Dan spends the output Charlie gave him, he's required to reveal the pre-image. Charlie can now use this to spend the output Bob gave him and Bob can use it to spend the output he received from Alice. In essence, Alice has paid Dan through the two intermediaries without giving Bob or Charlie the ability to steal the money for themselves.

This simple example is meant only to illustrate how hash locks enable the routability required by the Lightning Network. The example uses direct Bitcoin transactions even though it makes no sense to pay through intermediaries with direct transactions, and the construction above is insecure because it relies on unconfirmed transactions and because it allows Bob and Charlie to hold Alice's funds hostage. The other techniques used in Lightning mitigate these problems.

Other uses

Other described uses of hash locks include,

• Cross-chain atomic swaps: trading bitcoins for coins on a compatible altcoin chain or sidechain without either party needing to trust each other or any third-party.
• On-chain betting: someone (called an oracle) generates multiple pre-images and their corresponding hashes; the players create outputs protected by a combination of signatures and hash locks, and then provide all the necessary signatures to each other. Then the oracle reveals a single pre-image and deletes the rest; the players who won insert that preimage into the transaction along with the signatures they already have and collect their winnings. Note, this scheme does still require the oracle to be honest. Peter Todd believes that this scheme is inferior to one in which the oracle uses simple signatures.

Compatibility

The hash functions in Script that are necessary to create hash locks were part of the original Bitcoin 0.1 release. In December 2010, after several problems were found with Bitcoin's opcodes, Gavin Andresen introduced the IsStandard() function which prevented relay and mining by default of transactions using those hash functions and other rarely-used opcodes. After the opcodes received more auditing and had been enabled for years on testnet without issue, Bitcoin Core 0.10.0 (February 2015) removed most IsStandard() restrictions on P2SH transactions, re-allowing the use of hash locks in transactions that are relayed and mined by default.

Time locks

Bitcoin currently provides two different mechanisms for creating time locks (nLockTime and CheckLockTimeVerify) and after the BIP9/68/112/113 soft fork, it will provide two more mechanisms (nSequence relative time and CheckSequenceVerify).

Lightning will use CheckSequenceVerify (CSV). CSV allows an output to specify how many blocks or seconds must elapse after it is added to the blockchain before an input spending that output can be added to the blockchain.

For example, Alice pays Bob 1 BTC using an output encumbrance that requires both Bob's signature (using the CheckSig opcode) and 10 blocks to elapse (using CSV). If Alice's transaction is added to block 500,000, then a transaction created by Bbo that spends that output can't be added until block 500,010. But if Alice's transaction was added to block 500,001, then Bob's spend of that output couldn't be added until block 500.011.

The CSV opcode can be used with conditional logic to allow an output to be spent earlier than the time lock if some conditions are met. For example, if we extend the earlier scenario, Alice may allow Bob to spend the previously-described output sooner than 10 blocks provided that Alice also adds her signature to the spend.

Lightning uses a condition similar to this to allow either party to close a channel on the blockchain immediately but prevents them from further spending the money they withdrew from the channel for the period of time specified by parameter given to CSV (1,000 blocks in the original paper).

The other party to the channel can use this time to inspect the withdrawal and see if it contains an old version of the channel state. If it does, they can use the other conditions of the withdrawal output to spend that output before the CSV time lock expires, allowing them to claim all funds the withdrawing party paid into the channel as a penalty for the withdrawing party closing the channel in an old state.