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.

Glossary

This section attempts to document the most frequently used terms found in Lightning Network literature that may not be familiar to a general technical audience, including both the new terms created by Lightning Network designers as well as pre-existing terms that may not be well known from Bitcoin, cryptography, network routing, and other fields.

The list below should be in alphabetical order. Any commonly-used synonyms or analogs for a term are placed in parenthesis after the term.

• Bi-directional payment channel: a payment channel where payments can flow both directions, from Alice to Bob and back to Alice. This is contrasted with Spillman-style and CLTV-style payment channels where payments can only go one direction and once Alice has paid Bob all of the bitcoins she deposited in the channel funding transaction, the channel is no longer useful and so will be closed.
• Breach Remedy Transaction: the transaction Alice creates when Mallory attempts to steal her money by having an old version of the channel state committed to the blockchain. Alice's breach remedy transaction spends all the money that Mallory received but which Mallory can't spend yet because his unilateral spend is still locked by a relative locktime using OP_CSV. This is the third of the maximum of three on-chain transactions needed to maintain a Lightning channel; it only needs to be used in the case of attempted fraud (contract breach).
• Channel (Lightning channel, payment channel) a communication channel that allows two parties to make many secure payments between each other in exchange for making only a few transactions on the blockchain.
• Commitment Transaction: a transaction created collaboratively by Alice and Bob each time they update the state of the channel; it records their current balances within the channel. The Initial Commitment Transaction is the first of these transactions; it records the inital balances within the channel. This is the second of the maximum of three on-chain transactions needed to maintain a Lightning channel; it can be combined with a funding transaction for a new channel under the cooperative conditions necessary to create an exercise settlement transaction.
• Contract: an agreement between two or more entities to use Bitcoin transactions in a certain way, usually a way that allows Bitcoin's automated consensus to enforce some or all terms in the contract. Often called a smart contract.
• CSV: (OP_CheckSequenceVerify, OP_CSV) a opcode that allows an output to conditionally specify how long it must be part of the blockchain before an input spending it may be added to the blockchain. See relative locktime.
• Delivery Transaction: not really a transaction but rather the name for the outputs in the commitment transaction which Alice and Bob receive if one of them closes the channel unilaterally in the correct (current) state. If the channel is closed in an old state (indicating possible fraud), a breach remedy transaction will be generated from the output that would have paid the party closing the channel. If the channel is closed cooperatively, they'll create an exercise settlement transaction instead.
• Dispute period: (dispute resolution period) the period of time that Alice has to get her breach remedy transaction added to the blockchain after Mallory has an old commitment transaction added to the blockchain. If the dispute period ends without a breach remedy transaction being added to the blockchain, Mallory can spend the funds he received from the old commitment transaction.
• Dual-funded channel: a channel opened by a funding transaction containing inputs from both Alice and Bob. Compare to a single-funded channel where only Alice's inputs contribute to the balance of the channel.
• Encumbrance: a generic name for any conditions that must be satisfied before a bitcoin output may be spent. Early Bitcoin transactions placed all their conditions in the scriptPubKey; later the introduction of P2SH allowed conditions to be added in a redeemScript which the scriptPubKey committed to; the introduction of soft fork segwit will add a similar mechanism for detached conditions that the scriptPubKey commits to; in addition, there are even more novel ways to add conditions to outputs that are discussed but rarely used. The term "encumbrance" allows specifying what the conditions do without fussing over exactly where the conditions appear in a serialized transaction.
• Exercise Settlement Transaction: a form of the commitment transaction created cooperatively by Alice and Bob when they want to close their channel together. Unlike a regular commitment transaction, none of the outputs on an exercise settlement transaction are time locked, allowing them to be immediately respent.
• Exhausted: (exhausted channel) a payment channel where no additional payments can be made in one direction (such as from Alice to Bob). The person controlling the exhausted side of a Lightning channel loses nothing from fraudulently trying to commit an old channel state, so allowing a channel to become exhausted (or too near to being exhausted) is unpreferable. (Exception: channels can be securely started in an exhausted state, such as a single-funded channel.
• Full push: when Alice pays the full amount of the channel to Bob in the initial commitment transaction, which exhausts the channel without incentivizing fraud because Alice doesn't have a previous commitment transaction that she can broadcast. This term is used in the context of a single-funded transaction and stands in contrast to an overpayment where Alice deposits more than she pays Bob in that initial payment so that she can continue to use the channel without needing to rebalance.
• Funding Transaction: (deposit transaction) a transaction created collaboratively by Alice and Bob to open a Lightning channel. In a single-funded channel, Alice provides all the funding; in a dual-funded channel, Alice and Bob both provide some funding. This is the first of the maximum of three on-chain transactions needed to maintain a Lightning channel; it can be combined with a commitment transaction from a previous channel being closed under cooperative conditions.
• Half-signed: a transaction input which requires two signatures to be added to the blockchain but which only has one signature attached. (More generally, this could be any input that has fewer signatures attached than it needs to be added to the blockchain.)
• Hash lock: an encumbrance to a transaction output that requires the pre-image used to generate a particular hash be provided in order to spend the output. In Lightning, this is used to allow payments to be routable without needing to trust the intermediaries.
• HTLC: (Hash Time Locked Contract) a contract such as that used in a Lightning Channel where both a hash lock and a time lock are used, the hash lock being used to allow Alice to route payments to Bob even through a Mallory that neither of them trust, and the time lock being used to prevent Mallory from stealing back any payments he made to Alice within the channel (provided Alice enforces the contract).
• Intermediary: When Bob has one channel open with Alice and another channel open with Charlie, Bob can serve as an intermediary for transferring payments between Alice and Charlie. With Lightning payments being secured with a hash lock, Bob can't steal the payment from Alice to Charlie when it travels through Bob's node. Lightning payments can securely travel through a theoretically unlimited number of intermediaries.
• Limbo channel: an optional special state for a Lightning channel where it cannot be immediately closed by one or both of the parties unilaterally (it can still be immediately closed cooperatively). This is used in particular for PLIPPs.
• Multisig: (multisignature, m-of-n multisig) a transaction output that requires signatures from at least one of a set of two or more different private keys. Used in Lightning to give both Alice and Bob control over their individual funds within a channel by requiring both of them sign commitment transactions.
• Node: (Lightning node) a wallet with one of more open Lightning channels. This should not be confused with a Bitcoin full node that validates Bitcoin blocks, although a full node's wallet may also be simultaneously used as a Lightning node to the advantage of the Lightning network user.
• Overfunding: in a single-funded channel, Alice deposits more bitcoins into the channel than she pays Bob in the initial payment, allowing her to make additional payments through the Lightning network. This stands in contrast to a full push where Alice only deposits enough to pay Bob in the initial payment.
• PILPP: (Pre-Image Length Probabilistic Payments) a specific type of probabilistic payment within a payment channel where Alice creates string with a random length and Bob guesses the length; if he guesses correctly, Alice has to pay him; if he guesses incorrectly, Alice gets to keep her money.
• Pre-image: (R) data input into a hash function, which produces a hash of the pre-image. Inputting the same pre-image into the same hash function will always produce the same hash; Lightning uses this feature to create hash locks.
• Probabilistic Payment: a payment where Alice only pays Bob if some event outside of Alice's and Bob's control occurs in Bob's favor. Probabilistic payments are usually proposed for scenarios where payments can't conveniently be made small enough for technical reasons (such as not being able to pay less than 1 satoshi) or economic reasons (such as having to pay a transaction fee for every on-chain payment, making small payments uneconomical). See PLIPP for a specific type of probabilistic payment possible within a Lightning channel.
• R: the variable commonly used in formulas to represent a pre-image.
• Rebalance: a cooperative process between Alice and Bob when they adjust their balances within the channel. This happens with every payment in a Lightning channel and is only noteworthy because single-directional channels (such as Spillman-style and CLTV-style channels) are unable to rebalance and so must close as soon as Alices has paid Bob all the bitcoins she deposited into the channel. See bi-directional payment channels.
• Relative locktime: the ability to specify when a transaction output may be spent relative to the block that included that transaction output. Enabled by BIP68 and made scriptable by BIP112. Lightning uses relative locktime to ensure breach remedy transactions may be broadcast within a time period starting from when an old commitment transaction is added to the blockchain; by making this a relative locktime (instead of an absolute date or block height), Lightning channels don't have a hard deadline for when they need to close and so can stay open indefinitely as long as the participants continue to cooperate.
• Revocable Sequence Maturity Contract (RSMC): a contract used in Lightning to revoke the previous commitment transaction. This is allowed through mutual consent in Lightning by both parties signing a new commitment transaction and releasing the data necessary to create breach remedy transactions for the previous commitment transaction. This property allows Lightning to support bi-directional payment channels, recover from failed HTLC routing attempts without needing to commit to the blockchain, as well as provide advanced features such as PILPPs.
• Single-funded channel: a channel opened by a funding transaction containing only inputs from Alice. Compare to a dual-funded channel where Alice and Bob both contribute inputs to the initial balance of the channel.
• Timelock: either an encumbrance to a transaction that prevents that transaction from being added to the blockchain before a particular time or block height (as is the case with nLockTime, or an encumbrance that prevents a spend from a transaction output from being added to the blockchain before a particular time or block height (as is the case of OP_CLTV, consensus enforced sequence number relative locktime, and OP_CSV). In Lightning, this is used to prevent malicious intermediaries from holding other users' funds hostages as well as to allow victims of attempted theft to submit breach remedy transactions before the thief can respend the funds he stole.
• TTL: (Time To Live) when Alice pays Bob with a hash locked in-channel payment that's ultimately intended for Charlie, she specifies how long Bob has to deliver the payment (its time to live) before the payment becomes invalid. When Bob pays Charlie with his own in-channel payment that has the same hash lock, Bob specifies a slightly shorter amount of time that Charlie has to reveal the pre-image that unlocks the hash lock before Bob's payment becomes invalid. This ensures that either Bob receives the data necessary to remove the hash lock from the payment he received from Alice or the payment he made to Charlie is invalidated; Alice gets the same guarantee that either the payment she made to Bob ultimate goes through to Charlie or her payment to Bob is invalidated.
• Unilateral: any action performed by only one of the participants in a channel without requesting or needing permission from the other participant. Lightning allows channels to be closed unilaterally (so Alice can close the channel by herself if Bob becomes unresponsive) and attempted fraud can be penalized unilaterally (so Alice can take any bitcoins Mallory tried to steal when he broadcast an old commitment transaction).
• UTXO: (Unspent Transaction Output) spendable bitcoins. A transaction output lists a bitcoin amount and the conditions (called an encumbrance) that need to be fulfilled in order to spend those bitcoins. Once those bitcoins have been spent on the blockchain, no other transaction in the same blockchain can spend the same bitcoins, so an Uspent Transaction Output (UTXO) is bitcoins that can be spent.