* have capacity which is split into a balance sheet
* instant payments between peers
==== Multisig address
* short review of bitcoin transactions
* review of segwit multisig addresses
==== Funding Transaction
* opens the payment channel
* encodes the capacity of the channel
* not clear who owns what fraction of the capacity
* visible onchain transaction (even for private channels)
==== Commitment Transaction
* encodes the balance of the payment channel
* kept secretly between channel partners
* everyone has their own set of transactions
* encumbered with a time lock to give time to penalize protocol breach
* smart contract inside which gives possability to penalize protocol breach
==== Announcing the channel
* gossip protocol
* option to have private channels
==== closing the channel
* the good way - mutal close
* the bad way - force close
* the ugly way - protocol breach
=== Invoices
an alternative structure for the subsections of the invoice section (while covering the same topics) could be: (creating, decoding, paying as 3 sub chapters)
* creating invoices
* decoding invoices
* bech32 encoding and human readable part of invoices
==== Payment Hash
* `pre_image` as proof of payment
* random numbers and selecting the pre_image
==== Meta Data
* Description
* routing hints
* fallback address
* expire time
* signature
=== Delivering the payment
* gossip protocol
* network of payment channels
* different scope of the network
** global path finding (entire knowledge of the network necessary)
** multihop routing (onion necessary only a subset of nodes involved)
** locally setting up and setteling htlcs (only peers involved)
==== Finding a path
* trivial case / channel partner as destination with enough funds in the channel