The Lightning Network
A second-layer scaling and privacy solution
Bitcoin's scaling problem
- One block every 10 minutes (1 megabyte each)
- One transaction = 450 bytes (approximately)
- 4 to 7 transactions per second (depends on SegWit usage)
Compared to centralized payment networks:
- PayPal: 240 transactions per second (average) [0]
- VISA: 3,500 transactions per second (average) [1] and 65,000 (peak capacity) [2]
- AliPay: 325,000 transactions per second (peak capacity) [3]
How big do blocks need to be to support the same?
- At 7,500 transactions per second (average) → 2 gigabytes
- At 500,000 (peak capacity) → 108 gigabytes!
It has a privacy problem too...
- Bitcoin is pseudonymous (NOT anonymous)
- All transactions are public
- Wallet apps expose your IP and bitcoin addresses
- Your real identity can be tied to addresses by:
- Centralized exchanges that comply with KYC/AML
- Careless social media use
With real consequences:
- Data brokers will sell your transaction history
- Black-listing addresses is not possible at the protocol level, but has already happened at centralized exchanges [4]
- Targeted blackmail, extortion, robbery, and more...
The Lightning Network
Trustless, instant payments via bi-directional payment channels.
Building Block: Transactions
- Transactions are made of inputs and outputs
- Inputs - the source of funds
- Must satisfy rules to spend (usually a signature)
- Output - the destination
- Defines how funds can be spent
Building Block: Double-Spend
- An unspent output can be used as an input only once
- In the example here, only one transaction will be confirmed
Building Block: Multisig
- Multisig outputs require 2 or more signatures to spend
- The transaction cannot be changed without invalidating existing signatures
- In this example, Bob has signed but Alice's signature is also required
Building Block: Timelock
- A time-locked output cannot be spent before n blocks
- The block height of the output's transaction is the starting point
- In this example, Alice must wait 1000 blocks after the output's transaction was confirmed
Building Block: Secrets
- In this example, the output requires an arbitrary secret to spend
- The secret can be anything - typically a randomly generated value
- The hash of the secret is included in the output's script
Opening a Channel
- Alice and Bob provide inputs to a 2 of 2 multisig output
- Think of this as a joint escrow account
Updating Channel State
Alice and Bob exchange partially-signed commitment transactions
Updating Channel State (pt. 2)
This is Bob's version of the commitment transaction
Closing the Channel
- A new transaction is created and confirmed on the blockchain
- The multisig output from the opening channel tx is used as the input
- The outputs reflect the last state of balances in the channel
- This is how LN payments are settled on the blockchain
Notes
- Channel details never touch the blockchain
- This information must be managed by client software
- LN nodes must have a hot wallet:
- To open channels
- To update channel state
Current problems
Failed routing due to insufficient capacity
- Work-in-progress: Atomic Multi-path Payments (AMP)
- Not possible to know balances in a channel (as an observer)
- Must try many different paths before one finally works
- With AMP, all of your channel balances can be used together
Must be online to punish cheating
- Work-in-progress: Watchtowers
- Specialized nodes will watch for and punish cheating
- Only a problem if you want to receive payments
Statistics
- 2,443 nodes (with at least one active channel)
- 18,773 active channels
- 558 BTC total network capacity
- 0.229 BTC average node capacity
- 0.030 BTC average channel capacity
Try it out!
End-user applications are still badly needed. So if you have the skills and energy, please try to get involved!
Mobile Apps
Desktop Apps
Learn More
There are already multiple compatible node implementations for the Lightning Network.
Lightning Node Implementations
Resources