Lightning Network

Background

All blockchain designs have tradeoffs. Some of the main tradeoffs in bitcoin are:

  • Decentralization vs. throughput
  • Supply verifiability vs. privacy

Statechannels were a very old idea (even Satoshi talked about it).

Problem: Bitcoin has limited space in blocks. Normal people do repeat business with a lot of the same people/businesses over time. There’s not enough space in blocks for all these transactions individually.

Solution: Use payment channels between one or more parties to batch payments over time.

LN white paper by Joseph Poon and Thaddeus Dryja in 2015

LN is one of many second layer solutions in bitcoin: Lightning network, sidechains, statechains

LN is a protocol, not a company or federation. It relies on bitcoin’s security model not trusted third parties.

The LN protocol is being developed in various implementations based on the BOLT standards:

  • C (Blockstream)
  • Go (Lightning Labs)
  • Python (Electrum)
  • Rust (Matt Corollo, others)
  • Scala (ACINQ)

LN was enabled via the Segregated Witness (segwit) soft-fork in mid-2017.

  • Fixed transaction malleability: Resolved an attack where a txid could be changed after a tx has been signed. This is a big deal for LN b/c it means you can punish cheaters effectively.
  • Enabled script versioning: Lay groundwork for Schnorr or other signature algorithms

Important Concepts

Multipath payments (MPP):

  • Instead of paying your 2m sat (~$200) invoice from a single channel, MPP routs to utilize the liquidity from all your available channels to the recipient.
  • Atomicity: Even though the different parts of the payment may take different paths, they all arrive to the destination and combine to a single receipt

Watchtowers:

  • LN required interactive tx signing so you need a hot wallet
  • If you go offline you wouldn’t be able to broadcast the justice/penalty tx against cheaters
  • Watchtowers hold your justice/penalty tx for you (encrypted to with ½ of the txid) and watch the chain for you

Wumbo:

  • Only ~1,000 BTC in public LN channels today
  • Protocol initially limited the channel size to 0.04 BTC (to avoid people being #reckless)
  • People can now open larger channels and send larger payments

Channel factories:

  • Today, all channels are a single pipe between the two users
  • With Schnorr signatures (and the multisig improvements it brings) channel factories are possible where many people combine together to form more complex networks. Ex: Everyone in a fantasy football league pools money together in a channel factory instead of setting up multiple individual channels

Lightning limitations

  • Wormhole attack: Attacker with two nodes at the beginning and end of the route routes a payment to himself but cheats to steal honest middle-of-route node fees
  • Penalty/Justice transaction make backups risky: Rebooting your LN node from an old backed-up state could cause you to broadcast an old state and allow your channel partner to claim all your funds

 

How it works – Technically

Most of the content below has been either directly quoted or slightly modified from “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments”. Quotation marks and citations have been omitted for readability. I highly recommend it to anyone interested in understanding the innerworkings of future Bitcoin Lightning Network implementations.

—–

How does the Lightning Network actually work?

The base of this example was taken from “The Bitcoin Lightning Network” white paper.

Say Alice wants to buy a coffee from Dave, but Alice and Dave have never done a transaction together and do not have any prior existing relationship.

The Lightning Network provides Alice a way to pay Dave in an instantaneous (no block confirmations necessary), trustless (as in Bitcoin), low fee (as opposed to on-chain transactions), and decentralized (as in Bitcoin) manner.

At the start of the transaction, Dave takes any random piece of data (R) and hashes it (HR) [a hash is a cryptographic function whereby any data run through the hashing function will always produce the same output, but it is impractical to work backwards to the input data from the hashed output]. Dave then gives Alice the HR value via a normal secure communication method (i.e. not via a Bitcoin transaction).

 

 

The Lightning Network determines that Alice can pay Dave via two hops through Bob and Carol.


Each payment hop will be accompanied by a Hashed Timelock Contract (HTLC) between the two participants and each hop will have a timeframe element which is set in relation to the other hops in the chain.

At each hop (A à B, B à C, C à D), the participants (ex: A and B) initiate an HTLC which basically states:

  • Alice contributes 0.1 BTC to an HTLC “smart contract” (ugh!) with Bob. Bob cannot spend this money until he knows “R” (the secret word).
  • If Bob knows “R” within 3 days and proves this to the HTLC, then Alice will settle the contract by paying Bob 0.1 BTC as stated in the contract.
  • If 3 days have elapsed, then the above clause is null and void and the contract is invalidated. Alice will be refunded her previously contributed 0.1 BTC from the contract with Bob as stated in the contract (the Segwit transaction malleability fix made this step possible and prevents Bob (or anyone else) from holding Alice’s funds hostage in the contract).

After the HTLCs have been established between each participant, Dave shares the secret word with Carol and pulls the 0.1 BTC funds from the contract for himself. This process waterfalls back down to Alice’s final payment. Additionally, Alice knows that Dave has successfully received the payment because of her receipt of the secret word (R).

 

 

If at any point any participant is suspected to be a bad actor, any participant can broadcast their transaction onto the public Bitcoin blockchain and reclaim any funds at issue.

The beauty of this setup is that through the implementations of the Lightning Network which are being developed, all this hashing, contract generation, payment execution, and knowledge sharing occurs instantaneously and nearly free over the internet – without any record of it (aside from opening and closing channels) hitting (or bloating) the public Bitcoin blockchain.

 

Use Cases

Instant Transactions: Using Lightning, Bitcoin transactions are now nearly instant with any party. It is possible to pay for a cup of coffee with direct non-revocable payment in milliseconds to seconds.

Micropayments: Bitcoin blockchain fees are far too high to accept micropayments, especially with the smallest of values. With this system, near-instant micropayments using Bitcoin without a 3rd party custodian would be possible. It would enable, for example, paying per-megabyte for internet service or per-article to read a newspaper.

Exchange Arbitrage: There is presently incentive to hold funds on exchanges to be ready for large market moves due to 3-6 block con- firmation times. It is possible for the exchange to participate in this network and for clients to move their funds on and off the exchange for orders nearly instantly. If the exchange does not have deep market depth and commits to only permitting limit orders close to the top of the order book, then the risk of coin theft becomes much lower. The exchange, in effect, would no longer have any need for a cold storage wallet. This may substantially reduce thefts and the need for trusted third party custodians.

Cross-Chain Payments: So long as there are similar hash-functions across chains, it’s possible for transactions to be routed over multiple chains with different consensus rules. Payment can be routed by participants in both chains in the hop. E.g. Alice is on Bitcoin, Bob is on both Bitcoin and X-Coin and Carol is on a hypothetical X-Coin, Alice can pay Carol without understanding the X-Coin consensus rules.