Lightning Network


Lightning Network is the additional payment protocol, a layer embedded on top of a blockchain to enable users to send or receive payments instantly and at zero cost. It involves the use of peer-to-peer payment channels that mean users can defer broadcasting their transactions to the blockchain, making it scale. It is intended to help Bitcoin cryptocurrency scale.

Lightning Network Explained

Lightning Network is a proposed implementation of Hashed Timelock 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.

  • February 2015– T. Dryja and J. Poon published the first Lightning Network’s White Paper.
  • July 2015 – Blockstream, Lightning Labs and ACINQ announced the beginning of LN’s specification developments – C-lightning, Lnd and Éclair.
  • May 2017 – deployment of Segregated Witness enabled C. Decker to send the first transaction “not normally possible” using LN.
  • December 2017 – tests for interoperability between LN channels three implementations.
  • January 2018 – Blockstream launched “Lightning Charge,” – a micropayment system for web retailers

Concept

Lightning Network is a solution for blockchain’s scalability problem as it introduces automated micropayment (up to 0.0429 Bitcoin) services via implementation of a multi-party Smart Contract.
LN channel is essentially a network of two-party multi-signature bitcoin address with bi-directional payment channels. The payment channels enable money transfers between network participants without making all transactions public on the blockchain.
Technical features
Lightning Network implementation is possible due to Segregated Witness, which splits a transaction in two parts, separating the unlocking signature data from the Merkle tree.
Scalability is provided with Hashed Timelock Contracts.  Transactions are chained across a network due to hashing and CSV time-locks.
Flexibility is allowed with atomic swaps, which enable cross-chain trading. Atomicity means that a party must deliver the money within a specified time; otherwise the payment will be cancelled.
Security is empowered by onion-style routing. It prevents intermediary nodes from knowing who who they received a routable payment from and who to send it to next.

Lightning Network Blockchain Limitations

  • Intermediate failures: In case of intermediary node failure, transaction timeout could take days.
  • Peer failures: If one of the nods is unresponsive, it would require time to close payment.
  • No Offline Payments:  Counterparty cannot receive payment if they are not online.
  • Blockchain reliability: If underlying blockchain fails, then Lightning fails as well.

How does the Lightning Network work?

To use the Lightning Network, Bitcoin user needs to open a payment channel on the main Bitcoin blockchain. The same will apply to user with whom user A needs to transact.
The payment channel uses a smart contract protocol that allows the users to open a Multisignature wallet, spendable only when the two allow it.
Alice and Bob deposit a given amount to the account and sign to indicate how much of the balance belongs to each one of them. This opening balance is broadcast to the blockchain and forms the smart contract. It will self-execute when the conditions are met.
When payment channel open, transactions between Alice and Bob are done off-chain. They can transact as many times as possible without ever having to record their operations on the Bitcoin ledger.
These payment channels stay open for as long as the two continue to transact with each other.

Transfer of Ownership

To transact on a payment channel, one of the parties assigns a transfer of ownership, asking the network to transfer BTC from them to the other party.
Alice and Bob open a payment channel between them. If they deposited 10 BTC each, then the smart contract assigns each of them that exact amount to spend.
If say Bob wanted to send 3 BTC to Alice, he creates a transaction and assigns ownership of 3 BTC to Alice which he sends.

Alice will receive the transaction and sign it. Now Alice has 13 BTC while Bob has 7 BTC. The payment protocol will indicate Alice 13 BTC and Ben 7BTC if the contract is closed after that transaction.
If Alice and Bob wish to continue transacting for a given time, the network protocol will keep a record of their transactions, up to the last agreed upon payment.

Creating the Network

A network is the connectedness of several payment channels.
If Alice wanted to send some money to Charlie, yet they have not opened any payment channel between them;
Alice asks Bob to send Charlie the money on the Bob-Charlie payment channel, then Alice sends Bob the amount on the Alice-Bob payment channel. That creates a ”network” between Alice and Bob, Bob and Charlie, and Alice, Bob and Charlie.

The same scenario is replicated with Diane and so on. The premise is that there will be an interconnectedness of thousands, millions of payment channels. The growing network of payment channels reduces the number of transactions done on the primary bitcoin network, making the Bitcoin network faster and cheaper.

How do the payment channels operate?

The Lightning Network relies on the protocol in Segregated Witness (SegWit) which promotes the idea that most of the transactions undertaken using Bitcoin don’t have to be registered with the blockchain ledger. Instead, they can be completed in a kind of “smart contract” network called payment channels.
These payment channels allow the users to carry out transactions off-chain, only returning to record it onto the main chain when they want to close the channel. Users only incur a cost when opening a payment channel or when finalizing it; otherwise, transactions on the private network are free and instant.

Road map

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.
  • Securely cross blockchains: payments can be routed across more than one blockchain (including altcoins and sidechains) as long as all the chains support the same hash function to use for the hash lock, as well as the ability the ability to create time locks.
  • Sub-satoshi payments: payments can be made conditional upon the outcome of a random event, allowing probabilistic payments.) 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: 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: (, )) 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: 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: (Hashed Timelocked 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: (R 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 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: 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: (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.

Benefits

The Lightning Network will have three main benefits to the users of Bitcoin.

  • Instant payments- since most of the transactions will be made off-chain, users can connect and make payments online faster than what is happening now on the Bitcoin blockchain.
  • Reduced transaction fee- as noted earlier, LN channel will considerably reduce fees, potentially to zero costs.
  • Privacy of transactions- since you will be transacting within a payment channel, most of the transactions won’t end up on the main chain where every node has to verify it.

See Also

Source