All articles

Lightning Network

The Lightning network is an off-chain approach for solving Bitcoin scalability issues. It is a proposed implementation of Hashed Timelock Contracts (HTLCs) with bi-directional payment channels (a payment channel where payments can flow in both directions, from Alice to Bob and back to Alice) which allows payments to be securely routed across multiple peer-to-peer payment channels. The architecture of payment channels permits the formation of a network where any peer on the network can pay any other peer, even if they do not directly have a channel open between each other.

The main prerequisite for Lightning network was enabling SegWit which solved the malleability issue (BIP141).

Key features of the Lightning network are:
  • Rapid payments
  • No third-party trust
  • Reduced blockchain load
  • Channels can stay open indefinitely
  • Rapid cooperative closes
  • Outsourceable enforcement
  • Onion-style routing
  • Securely cross blockchains
  • Multisignature capable
  • Sub-satoshi payments
  • Single-funded channels
 
You can read more about the Lightning network on the Bitcoin wiki.
 
TABLE OF CONTENTS
  • Atomic transactions
  • Bitcoin script
  • Hashed timelock contracts
  • Atomic swap HTLC example
  • Atomic chain HTLC example
  • Payment channel
 

Atomic transactions

Atomic transactions are transactions that are all fully executed, or they are not executed at all - 'atomic' in this instance means inseparable. Parties involved cannot cheat because when they do penalties are applied.

Atomic transactions can be used:
 
  • Cross chain transactions
 
 
  • Transactions that cannot be sent directly
 
 

Bitcoin script

Bitcoins can be sent to an address as well as to the script. A script is a simple, stack-based list of instructions. This script can consist of any instructions, e.g., operations with the stack, conditions, arithmetic and logic operations, cryptography or time verification. When someone sends funds from a bitcoin address, a private key has to be used, whereas in a bitcoin script to spend the funds the input has to be provided, so the bitcoin script results in 'True'.


Hashed timelock contracts

Hashed timelock contract (HTLC) is a transaction template, and it is a type of bitcoin script. It consists of these parameters:
  • lockTime
  • keyA, keyB
  • H

Alice generates the random number R and hashes it to H. By creating an HTLC contract on the blockchain, H is published.
 

The transaction in HTLC can be spent either by:
  • the owner of keyB private key when they know the R (pre-image of H)
  • the owner of keyA private key when the lockTime already passed
 

Atomic swap HTLC example

  1. Bob wants 1 BTC from Alice.
  2. Alice wants 1 ETH from Bob.
  3. Alice generates random R, calculates its hash H.

The first transaction is created by Alice, and the ETH transaction has to be created afterwards by Bob.
 

Alice can now withdraw ETH from Bob, by this action, she publishes the R.

Bob can now withdraw BTC as he knows the R and also knows keyB, and he has enough time for this transaction (1 day).  This means atomic transaction become atomic only after some time.
 

Atomic chain HTLC example

  1. Alice wants to send 1 BTC through intermediaries (Bob and Carol).
  2. Dave generates random R, calculates its hash H.
  3. Dave publishes H and creates these transactions:
 

Dave can withdraw money from Carol, and by this action, Dave lets Carol know the R.

Same way Carol withdraws money from Bob and Bob withdraws from Alice.
 

Payment channel

Payment channel is an agreement between two individuals and it is possible to send money using the channel. The opening and closing of the channel are recorded on the blockchain, and all other transactions are recorded only off chain. Payment channel is a 2-of-2 MultiSig address which is funded by one or both involved subjects.
 

Together with funding, the commitment transaction is signed by both subjects, and this remains private. A commitment transaction divides the funds from the funding transaction according to the correct allocation between channel participants. When the off-chain payments take place, a new commitment transaction is created, and the old one is discarded. A revocable hash contract is used to prevent publishing the old (already replaced) commitment transaction. When one of the subjects wants to settle and close the payment channel, they publish the commitment transaction. The channel state consists of two numbers: A - how much money belongs to Alice, B - how much money belongs to Bob. The commitment transaction follows the channel state - it is set exactly according to it. When Alice wants to send some funds to Bob, they agree on changing the channel state.