-
trustless between peers
-
operation takes place off chain
-
throughput bound by TCP/IP traffic
-
have capacity which is split into a balance sheet
-
instant payments between peers
-
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)
-
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
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
-
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)
-
-
trivial case / channel partner as destination with enough funds in the channel
-
topology information from the gossip protocol
-
fees and pathfinding from destination to source
-
select outputs vs select payment channels / finding a path
-
change outputs vs no change on lightning
-
mining fees vs routing fees
-
public transactions on the blockchain vs. secret payments
-
waiting for confirmations vs instant settlement (if everything works smoothly)
-
arbitrary amounts vs capacity restrictions
-
variying fees depending on the traffic vs announced fees (might become dynamic too?)
-
blockchain to save all transactions vs blockchain as a court system