lnbook/ch01.asciidoc

[role="pagenumrestart"]
[[ch01_intro_what_is_the_lightning_network]]
== Introduction

=== What is the Lightning Network?

The Lightning Network (LN) is a payment system for Bitcoin.
It is a second layer protocol on top of Bitcoin that defines rules and contracts which enable fast, secure, private, trustless and permissionless transfer of Bitcoin.
Users of the LN are able to transfer Bitcoin among each other at virtually no cost and in real time.
They are not required to wait for block confirmations for payments.
Once a payment arrives, it is final and cannot be reversed.
Like a standard Bitcoin transaction, a payment on the LN can only be refunded by the recipient.
While all Bitcoin transactions are stored in the blockchain where they can be tracked, the payments on the LN are off-chain and offer more privacy than on-chain Bitcoin transactions.
Due to the use of onion routing, which is also implemented in Tor, even the nodes involved in forwarding the payment from sender to recipient do not know for whom they deliver the payment.

=== History of the Lightning Network

// The following is a working draft and suggested mile stones in the history of the LN.

The history of the LN is nearly as old as the history of Bitcoin.
The first response to Satoshi Nakamoto's initial publication of the Bitcoin whitepaper on the metzdowd cryptography mailing list discussed the issue of scaling.
[quote, James A. Donald, First Response to the Bitcoin whitepaper https://www.metzdowd.com/pipermail/cryptography/2008-November/014814.html ]
____
We very, very much need such a system, but the way I understand your proposal, it does not seem to scale to the required size.
____
While James A. Donald was probably referring to maintenance of the unspent transaction outputs (UTXOs) database, it quickly became clear that verifying and storing so many transactions would also become infeasible for any blockchain.

A key requirement for a second layer protocol such as Lightning (which will be described in greater depth later in this book) is the ability to sequence transactions external to the blockchain. In the first versions of Bitcoin, Satoshi Nakamoto recognised this and introduced a data field called `nSequence` into the input transaction data.
The `nSequence` field was intended to allow users to transmit updated versions of a transaction to the network, changing the outputs of a transaction, effectively creating a payment channel.
Such a payment channel would then be valid as long as the transaction was not mined.
According to a Mailinglist post in 2013 by early Bitcoin developer Mike Hearn, Satoshi Nakamoto envisioned this construction for the use case of high frequency trading.footnote:HearnBitcoinDev[Mike Hearn on Bitcoin-dev - April 16th 2013 - Anti DoS for tx replacement http://web.archive.org/web/20190501234757/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html.]

However, there were some weaknesses in this initial formulation that limited its potential. Firstly, the payment channel would only be open until the transaction was mined in a block, either limiting the duration the payment channel or handing control of the payment channel to the miners. Secondly, there was no economic incentive for miners to respect the `nSequence` number, rendering this mechanism effectively useless.

The Revocable Sequence Maturity Contracts (RSMC), which formed payment channels in the first version of the Lightning Network, reference in their name the fact that they fixed this weakness of the `nSequence` field.
This is achieved by creating an economic incentive via a penalty mechanism; otherwise, the most recent transaction or update in the payment channel is published to the Bitcoin network, and becomes enforceable in this way.
// find / add sources for some of the claims

In July of 2011, on the bitcointalk.org forum, a pseudonymous user by the name of _hashcoin_ suggested using Timelocks via the `nLockTime` function of the Bitcoin network to solve the custody problem of exchanges.footnote:[Hashcoin on Bitcoin talk on July 4th 2011 - Instant TX for established business relationships (need replacements/nLockTime) http://web.archive.org/web/20190419103503/https://bitcointalk.org/index.php?topic=25786.0]
The goal was to build a conduit for quick trades, without the necessity to send bitcoins to an exchange in the first place.
What Hashcoin proposed would eventually be termed a unidirectional payment channel.
With this mechanism, user "Alice" could fund a multi-signature address between herself and another user, "Bob", together with a timelocked transaction that 'refunded' the bitcoin back to Alice.
In their scenario, Hashcoin imagined Bob to represent an exchange.
The transaction used to fund the multi-signature address, which is controlled by Bob's and Alice's keys, is naturally called the funding transaction.

Alice would send the partially signed transaction to Bob, who would sign it and keep it private.
Note that keeping it private is crucial. If Bob does not share the fully signed transaction with Alice, she does not have both signatures needed to spend funds from the multi-signature address. Except for the timelocked refund transaction, she can't send an outdated spend of the funding transaction to the Bitcoin network.
Bob, on the other hand, could do so, but he would have no interest in publishing an old channel state. The newer state would provide him with more bitcoin than the older state.
Alice cannot effectively broadcast the refund transaction to be mined in a block before the timelock expires.
Therefore, Bob can securely receive more updates to the channel balance as long as it remains `open`.

This mechanism would allow two users to engage into several smaller transactions which all happened outside of the Bitcoin network.
While this construction of the unidirectional payment channel would have solved the custody problem of exchanges it has never been widely implemented.
We can only speculate for reasons and guess that the overhead communication would have had to be standardized - as it is nowadays in the LN specification - which might have been too much overhead in the early days of Bitcoin.
Also as a payment channel this system was not too useful as the channel could only at total send the total amount of provided Bitcoin in the funding transaction.
Once the timelock was over or all Bitcoin were sent to B the channel would have to be closed.
The obvious idea of opening two channels one from A to B and one from B to A would not have helped as each of those channels would have to be closed and reestablished once it ran dry.
The core breakthrough for the LN to become a reality was the ability to create payment channels which technically can live forever and can send money back and forth as often as the peers wish to in combination with routing payments among several channels.

[TIP]
====
You can watch a video explaining the construction and operation of unidirectional payment channels online at: https://youtu.be/AcP3czefanM
====

Surprisingly both properties took quite some while until the community figured them out.
Technically speaking the unidirectional payment channel has all the important ingreedients (funding transaction to a 2-2 multisignature wallet, a transaction spending from the wallet encoding the balance, a timelock to allow refunding if the other side becomes unresponsive, off chain communication and the fact that no additional trust other than the one in the bitcoin network) of modern payment channels which are used in the LN.
Despite being rather useless in today's world we will study the unidirectional payment channel in more depth in this book as it is an easy to understand educational example to approach the construction of today's payment channels.
This setup has one safety issue as transactions have been malleable without the segwit upgrade.
A problem that needed to be solved for any payment channel construction that we know up till today and which has been fixed in August 2017.

During the first couple of years, the Bitcoin network was growing and the focus of many enthusiasts was on adoption, rather than the blocksize and scaling. However, in 2012 Gavin Andresen proposed the Ultra Transaction server on his blog.footnote:[Gavin Andresen's blog - July 4th 2012 - Off-the-chain transactions - http://web.archive.org/web/20190730234737/http://gavintech.blogspot.com/2012/07/off-chain-transactions.html]

The Ultra Transaction server was proposed to be a trusted partner of a 2-2 multisig wallet that could not steal funds but allowed signing transactions from a 2-2 multisig wallet.
Andresen observed that with such a mechanism, payments would effectively take place offchain, allowing the number of transacations which could be handled by the system to be increased.
Andresen noted that there might be a better construction which would require less trust in the Ultra Server, and while his proposal was a step in the right direction, a few issues remained to be solved before the design of fully trustless payment channels was complete.

Andresen's work led to many discussions on Bitcointalk forum, and later on the bitcoin-development mailing list. These discussions resulted in the first construction of the first unidirectional payment channels.

To sum this up: Andresen used a similar construction as the unidirectional channel.
They key difference was that a trusted party would have co-signed the spend of the funding transaction.
The Ultra Server was not able to steal Bitcoin.

The next day, probably in response to Gavin's blogpost, Meni Rosenfeld started a discussion related to how these ideas could be combined.footnote:[Meni Rosenfeld on Bitcointalk - July 5th 2012 - Trustless, instant, off-the-chain Bitcoin payments http://web.archive.org/web/20190419103457/https://bitcointalk.org/index.php?topic=91732.0]
As Hashed Timelocked Contracts have neither been invented nor seen to solve the issue of trustless routing Rosenfeld imagined trusted routing nodes.
Without mentioning the term network or routing of payments the idea of connecting payment channels and being able to send funds from anyone to anyone else even if there was no direct channel was born.
In Rosenfelds solution payment providers would be the ultraservers and they would among themselves settle the transactions based on trust.
It took us another 3 years until the LN whitepaper emerged which had solved all the bits and bolts necessary to get rid of the trust in Rosenfelds solution.

It was 2013 that Bitcoin developer Mike Hearn referred to Meni Rosenfelds proposal and suggesting to reactivate the `nSequence` field which Satoshi preiviously had deactivated.footnote:HearnBitcoinDev[]
Also Hearn referred to a section on the contracts article talking about the case of micropayment channels with the help of `nSequence`

Links:
* https://en.bitcoin.it/w/index.php?title=Contract&oldid=36712#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party

* Multiple white papers
** Joseph Poon, Thaddeus Dryja - The Bitcoin Lightning Network:
Scalable Off-Chain Instant Payments https://lightning.network/lightning-network-paper.pdf
** Christian Decker, Roger Wattenhoffer - A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels https://tik-old.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf
* Milan meeting and creation of BOLTs
* segwit activation
* passing of integration tests / mainnet launch
* Australia Meeting and BOLT 1.1
* Initial nodes/wallets - eclair, c-lightning etc
* Reckless - Testing on mainchain.
* satoshis.place / The lightning torch
* today

[[user-stories]]
=== Lightning Network Uses, Users, and Their Stories

As an electronic cash system it preserves the 3 most important properties of money (medium of exchange, store of value, and unit of account).
The invention of money (and in particular Bitcoin) was primarily made to facilitate trade and enable the exchange of value between people.
However, without the LN, Bitcoin is hard to be used concurrently by millions of people.
Therefore, in order to fully understand the uses of the LN, we'll examine it from the perspective of people using it.
In particular the use cases will come from previous users of Bitcoin as well as people who have not used Bitcoin before.
Each of the people and their stories, as listed here, illustrates one or more specific use cases.
We'll be seeing them throughout this book:

consumer::
A regular consumer on the Internet or in the offline world who wants to make purchases.

content creator / curator::
A person or platform offering content on the web.
They want to install a pay wall or get tipped by their fans and consumers.
This could even include music or video streaming on demand paying in real time.

John is a 9 year old boy from Australia, who wanted a games console just like his friends. However he was told by his dad that in order to buy it, he had to earn the money by himself. Now John is an aspiring artist so he knows that while he is still learning, he can't charge much for his artwork. After learning about Bitcoin, he managed to setup a website to sell his drawings across the internet. By using the LN, John was able to charge as little as $1 for one of his drawings. By being able to set a fair price, which would normally be considered a micropayment and as such not possible with other payment methods, and by using a global currency such as Bitcoin, John was able to sell his art work to customers all over the world and in the end buy the games console he so very much wanted.

gamer::
Similar to the content creator, a gamer and live streamer would like to be tipped.
However, in gaming (and gambling) the transfer of bitcoin could be part of the game for example to trade items or to wage for bets.

migrant::
Remittance is an important way for refugees to help their loved one in their home country.
Characteristic for remittance is that the payments usually are cross border and relatively small.
However, they might happen on a monthly base as they are just a fraction of the monthly wage.

professional bitcoiner::
A person who wants to earn interest on their bitcoin without the risk of lending them to other people could decide to set up routing nodes on the LN.
By providing liquidity to the LN the routing capacities will be increased offering the chance to earn routing fees on the owned bitcoin.

merchants::
Merchants live on the margin of the sold goods.
They usually pay fees for using point of sales services and several payment methods which take a fraction of the transferred money.
This directly decreases the margin on which merchants operate.
A merchant will be happy to get an additional payment method which is virtually for free to the merchant.

An example of a merchant is Silke.
Silke runs a small coffee shop in an upmarket street in Berlin.
She knows about Bitcoin and wants to accept it in her shop, but has been reluctant to do so because she knows that Bitcoin payments take approx. 10 minutes to be confirmed into her account.
However with the LN, she knows that her regular clients, such as Joerg can pay for their coffee at her shop, quickly and with negligible fees.
Additionally, by using the LN, Silke has all funds deposited instantly to her wallet and with usually smaller fees on her side as well.
Ultimately this allows her to provide a better service or to offer better pricing for her products.

=== Getting Started

==== Choosing a Lightning Network Wallet

* full nodes (c-lightning, eclair, lnd) + remote controls
* phone / desktop wallets (SPV clients)
* custodial services / wallets?
// Mastering bitcoin also had a section about custodial web wallets. So it might be fair to include them.

==== Quick Start

* We start with a mobile wallet like eclair
* Verify the authenticity of the software (e.g. App store / Acinq website / github)
** discuss that a general phising scheme might consist of tricking you to download a similar looking software

[[getting_first_bitcoin]]
==== Getting Your First Bitcoin on the Lightning Network

* Trade fiat for Bitcoin (as in Mastering Bitcoin)

[[using_own_bitcoin]]
==== Process for people who already own Bitcoin ====

* send bitcoin to lightning wallet (1 onchain transaction - soon nodes / wallets may support funding a channel directly without sending bitcoins to the lightning network wallet first)
* find a node to open a channel with (Node explorer / Autopilots / ...)
* open a connection
* open a channel
* wait confirmations for the channel to become operational

[[sending_receiving]]
==== Sending and Receiving Bitcoin on the Lightning Network
* have the person who helps onbording open a payment channel (As complex as a bitcoin transaction)
* showcase how the funds now can be send back and forth
** create invoice
** decode invoice (do always before paying!)
** pay an invoice
* showcase how an arbitrary invoice can be paid e.g. https://voting.ln.rene-pickhardt.de