5. Scaling options
● On-chain
○ Bigger blocks
○ Sidechains
○ Magic tricks (SegWit)
○ Sharding
● Off-chain
○ LN (in a way LN is a sidechain with only 2 participants)
6. State channels
● Multi-party record of a specific state
● Off-chain
● Private
● Pre-determined (between the parties) life-span
● Most often two-party
7. Payment Channels
● 2-party state channels, but for
balance (money)
● Another way: 2 party ledger
Time Alice Bob
T0 10 0
T1 9 1
T2 7 3
T3 8 2
8. Key LN enablers
● Payment channels (LN is a network of Payment channels)
● TOR
● HTLC
9. History
● Joseph Poon & Thaddeus Dryja
● Original paper in Feb-2015
● Updated since https://lightning.network/lightning-network-paper.pdf
● Transformed into BOLT RFC
https://github.com/lightningnetwork/lightning-rfc
● All implementations follow the BOLT specs
14. How it works
● Each channel balance change means a new set of transactions are
exchanged but not broadcasted (the whole point of being off-chain)
● Old transactions are invalidated (how they do that: keys are provided to the
other party)
● Unilateral close is CSV guarded (locked for 144* blocks)
● Bad behaviour (publishing an old transaction) is punished (cheater is
wiped out)
● The balance changes can go forever (there’s a theoretical limit of
281,474,976,710,655 changes, though)
15. Payment Routing
● Routing schema is based on the Sphinx
● Path is determined / calculated by the sender
○ Creates a shared secret (using ECDH) for each intermediate node, based on pubkey(ID)
● Different least cost path algorithms (e.g. lnd - Dijkstra, c-lightning
Bellman-Ford)
● Nodes forwarding the message can verify the integrity, but can’t
○ learn which other nodes, except for previous and next, are part of the route
○ learn the length of the route
○ or learn their position in the route
● Max length is 20 hops.
16. Good to know
● Channel balance cannot decrease below a certain threshold on each end
(both nodes need to have SITG)
● Upon opening a channel the balance tends* to be on one side
○ Thus opener MUST pay before being able to be paid
● Operating a LN node can bring profits (unlike operating a “classic” bitcoin
node), by routing payments for others base_fee + fee%
17. Node Implementations
● LND (in Go) by Lightning Labs
● C-Lightning (in C) by Blockstream
● Eclair (in Scala) by ACINQ
● Lit (in Go) by MIT DCI
● Ptarmigan (in C++) by Nayuta
● Plasma (in node.js) by bcoin
● Thunder (in Java) by Blockchain.com
18. Wallet implementations
● Mobile
○ Eclair (by Acinq)
○ Lightning Wallet (by A. Kumaigorodski)
○ CoinClip (by Valcour Games)
● Desktop
○ Zap (by Jack Mallers)
○ Lightning App (by Lightning Labs)
○ Presto
● Web
○ Htlc.me (by Alex Bosworth)
● And … CLI for the brave: lncli, lightning-cli, eclair
20. DevTools & ready made apps
● Lightning-Charge https://github.com/ElementsProject/lightning-charge
(REST API for c-lightning)
● LN-Service (REST API for lnd) https://github.com/alexbosworth/ln-service
● https://github.com/cdecker/kugelblitz (UI for c-lightning)
● LApps
○ Woocommerce LN plugin
https://github.com/ElementsProject/woocommerce-gateway-lightning
○ Jukebox https://github.com/ElementsProject/lightning-jukebox
● Directories of tools and apps
○ https://github.com/bcongdon/awesome-lightning-network
○ https://gist.github.com/bretton/798ec38165ffabc719d91e0f4f67552d
21. Use cases
● Instant transactions
● Exchange Arbitration
● Micropayments
● Financial Escrow and Smart Contracts
● Cross chain payments and atomic swaps (both chains need to support
HTLC)
24. AMP
● Split big payment into smaller ones
● Can only be settled all-or-none
● It’s independent of the intermediate nodes, only the sender and the
received need to be aware
● Further enhance privacy
25. AMP
● Implements a basic secret-share mechanism
● Employs Extra Onion Blobs
26. Splice-in / Splice-out
● Splicing - modify the live balance of the channel
○ Send tx from channel balance to regular BTC address
○ Top-up channel balance
● Works by adding a UTXO or splitting the funding TX into 2 UTXO
27. Watch Towers
● Let other nodes claim funds on your behalf
● Will (most likely) mean additional fees
● Implementation proposal using Encrypted Blobs
○ Use half of the current commitment txid as hint and the the other half as encryption key
○ Assemble revocation tx, encrypt with key and give to WT
● Comes with privacy implications
28. Submarine swaps
● Main idea: swap liquidity in LN for ‘classical’ BTC liquidity
● Send regular BTC tx to pay LN invoice (e.g. no LN wallet)
● Or the other way around (pay LN, receive BTC)
● Might come useful to balance channels (splicing notwithstanding)
● See in this respect
○ https://lightningconductor.net/
○ https://submarineswaps.org/
29. Other considerations
● Since some of those use constructions based on LN, they could be
considered L3
● BOLT’s are (largely) coin neutral => any (more-accurate: most) blockchain
that supports time-locked contracts can implement it
○ LTC
○ ETH (Raiden/µRaiden)
○ ZCash (see proposed BOLT https://blog.z.cash/bolt-private-payment-channels/)
● To watch: Lumino and LTCP on RSK (BTC sidechain with EVM)
30.
31. Timelocks primer
Time Lock Location Targeting Metric Type Signal
nLocktime Txn Absolute Blocks/Seconds Seconds if >=500000000
nSequence Input Relative Blocks/Seconds Seconds if type flag set
OP_CLTV Script Absolute Blocks/Seconds Seconds if >=500000000
OP_CSV Script Relative Blocks/Seconds Seconds if type flag set
32. Ride the lightning
● Second album by Metallica
● Released Jul 27, 1984
● 8 Tracks
….