Lightning network

From Trezor Wiki
Jump to: navigation, search


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 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

Atomic transactions[edit]

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

Atomic transactions can be used:

  • Cross chain transactions
Atomictransaction1.png
  • Transactions that cannot be sent directly
Atomictransactions2.png

Bitcoin script[edit]

Bitcoins can be sent to 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 bitcoin address, private key has to be used, whereas in bitcoin script to spend the funds the input has to be provided, so the bitcoin script results in True.

Hashed timelock contracts[edit]

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

  • lockTime
  • keyA, keyB
  • H

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


HTLC1.png

The transaction in HTLC can be spent either by:

  • owner of keyB private key when they know the R (preimage of H)
  • owner of keyA private key when the lockTime already passed

Atomic swap HTLC example[edit]

Bob wants 1 BTC from Alice.

Alice wants 1 ETH from Bob.

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.

HTLC2.png

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[edit]

Alice wants to send 1 BTC through intermediaries (Bob and Carol).

Dave generates random R, calculates its hash H.

Dave publishes H and creates these transactions:

Atomicchain.png

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

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

Payment channel[edit]

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 2 of 2 MultiSig address which is funded by one or both involved subjects.

Paymentchannel.png

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 payments off chain take place, 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.

Like Trezor? Get one here!