The document outlines the Lightning Network proposed by Joseph Poon and Thaddeus Dryja, detailing the mechanics of bidirectional payment channels, including opening channels, commitment transactions, and updating the channel with new transactions. It also discusses cooperative channel closures and highlights the limitations of the Lightning Network, such as capacity and liveness requirements. The document further touches on trading mechanisms involving decentralized exchanges (DEX) and automated market makers (AMM).

1. Lightning network
Proposed by Joseph Pool & Thaddeus Dryja
July 2022

2. Multisig

3. Timelock

4. Hash values and Secrets

5. Bidirectional Payment Channels

6. Open channel
• To open the channel, Alice and Bob each send 5 bitcoins to a 2-of-2 multisig
address.
• Bitcoins can only be spent from this address if both Alice and Bob sign.
• Additionally, Alice and Bob both create a secret (a string of numbers), and
exchange the hash.

7. Commitment transaction
• Alice sends 4 bitcoins to herself, and 6 bitcoins to a 2nd-multisig address.
• Bob can unlock the 2nd-multisig addr, but only after 1000 extra blocks
mined. Or, it can be opened by Alice on her own, but only if she also includes
the secret for which Bob has just now given her the hash.
• Similarly, Bob sends 6 bitcoins to himself, and 4 bitcoins to the 2nd-multisig
addr. Alice can unlock this address if she waits an additional 1000 blocks, or
Bob can unlock it with Alice using her secret.

9. • After all this exchanging of “half-valid” commitment transactions and hashes of
secrets,
• They both sign and broadcast the opening transaction, to make sure it's
recorded on the blockchain.
• The channel is now officially open.

10. • Alice and Bob could sign and broadcast the half-valid commitment transaction
they got from the other. If Alice does, Bob gets six bitcoins immediately.
• If Bob does, Alice gets four bitcoins immediately. But whomever signs and
broadcasts the transaction will have to wait 1000 blocks to unlock the
subsequent multisig-address, and claim the remaining bitcoins.
• However, and this is the key trick of a payment channel: neither sign and
broadcast their half of the transaction at all.

11. Updating the Channel
• Bob wants to send Alice 1 bitcoin back (now, 5 btc for each)
• Similar process..
• They both sign their new half valid commitment transaction, and give it to each
other + exchange new secret’s hash.
• Alice and Bob hand each other their first secrets, as used in the first set-up.

15. Broadcast old commitment tx
• Bob cannot safely sign and broadcast the older commitment transaction any
more, because Alice now knows Bob's first secret.
• If Bob were to sign and broadcast that commitment transaction, he would
immediately send 4 bitcoins to Alice... and he would have to wait 1000 blocks
to claim his own six bitcoins.
• That's a problem, because now that Alice knows his secret, she could use this
time to beat Bob to the punch, and claim the other six bitcoins as well!

16. Cooperatively closing out a channel

17. Alice send BTC to Carol through Bob

19. From: Carol Bob 10BTC
To: Bob 4BTC
Required to unlock:
To: Carol Bob 5BTC
Require to unlock:
or
To: Carol Bob 1BTC
or
or
Bob Sign
Bob Sign
Carol Sign
Bob Sign
Carol Sign
1st
Carol Sign
Bob Sign
Bob Sign 1st
From: Carol Bob 10BTC
To: Carol 5BTC
Required to unlock:
To: Carol Bob 4BTC
Require to unlock:
or
To: Carol Bob 1BTC
or
or
Carol Sign
Carol Sign
Bob Sign
Carol Sign
Bob Sign
1st
Carol Sign
Bob Sign
Carol Sign 1st

22. Settling the Status
• Carol send Bod (or
broadcast) the secret to
receive btc, Bod forwards
this secret to Alice.
• I.e. Bod could claim his btc
any time.
• 🡪 to terminate an HTLC off-
chain requires both parties
to agree on the state of the
channel.

23. Notice about HTLC timeout
• If Bob gets the value from Carol only after Alice already reclaimed her coin
back, Bob is stuck in the middle after all.
• Therefore, The time-out in Bob and Carol’s HTLC must therefore
expire before the time-out in Alice and Bob’s HTLC expires.

25. Limitation of Lightning Network
• Inbound and Outbound Capacity
• Inbound cap: the amount of money you can receive (= remote cap)
• Outbound cap: the amount of money you can send

26. Limitation of Lightning Network

28. Limitation
• High liveness requirements
- Nodes are required to be online in order to send and receive payments
• The network is congestion 🡪 not be able to get money back fast
• Opening and Closing Channel Fee + Routing Fee

29. Lightning network CLI
1. lncli openchannel
2. lncli addinvoice
3. lncli sendpayment

30. DEX with LN

31. AMM
Oracle
trader DEX
Token A commitment
Token B commitment
DEX
Trader X Bid A/B
Request rate A/B
Trader Y
Ask B/A
AMM MODEL
TRADITIONAL MODEL

32. pBTC : PRV
10 : 20
trader DEX
1 pBTC channel 0
0 PRV channel 2
Rate BTC:PRV = 1:2
OPEN
pBTC :
PRV
10.5 : 19
trader DEX
0.5 pBTC
0.5
1 PRV 1
TRADE 0.5 BTC
1. Trader send pBTC half commitment
2. DEX send PRV half commitment
3. Trader send PRV half commitment
4. DEX send pBTC half commitment
AMM: UNISWAP MODEL

33. pBTC : PRV
10 : 15
Trader A DEX
BID 0.5 pBTC for 1PRV
BID
Trader A DEX
1 pBTC 0
0 PRV 2
MATCHING WITH OTHER TRADER
COMBINE TRADITIONAL TRADING MODEL & AMM MODEL
Trader B
Trader B
2 pBTC 0
0 PRV 7
Trader A DEX
0.5 pBTC
0.5
1 PRV 1
Trader B
1.5 pBTC +0.5
+1 PRV 6

34. Thank you