Lecture 16: Bitcoin payment channel
Visa ~ 10, 000 transactions per second Bitcoin ~ 3 transactions per second => 60 GB of blockchain data per year
Waiting for 6 blocks ~ 60 mins is a huge wait for Bitcoin. Therefore, tipping or having an ongoing channel of payments on the blockchain is hard. Payment channels help with that.
Funding channel - unidirectional payment channels
Alice is planning to pay Bob.
- Alice creates a funding transaction. She puts, say, 100 bitcoin in 2-of-2 multi-sig account C.
- When Alice wants to pay Bob, she gives Bob a single funding transaction which sends money from C, 1 Bitcoin to Bob and 99 to Alice.
- A later transaction would be sending 2 to Bob and 98 to Alice. This overwrites the previous transaction.
Finally… say the last transaction is 40 go to Alice and 60 to Bob then Bob signs the last transaction and submits it to the chain. Since the last transaction is the best value for Bob.
Bob can host money hostage. Time-locked transactions ensure that Bob can hold Alice’s 100 Bitcoin hostage.
To build a bidirectional channel, one can have two unidirectional channels but they have a limitation, once Alice has exhausted her channel, she cannot send more money to Bob even if Bob has sent Alice money via the other channel.
Alternatively, one funding channel with time lock of 100 can be forked into another funding channel of time lock of 99, which can further be forked into funding channels with the smaller time locks. It is recommended not to go beyond the depth of 11 and time lock of 50 for such an approach since in the worst case, all the funding transactions will have to be committed.
Payment Channel Network (Lightning)
A -> D can be settled as A -> B -> C -> D off-chain using HTLC (Hash-time locked contracts). To do this, D sends a secret S to A and A commits P2SH with H(s), B and C do the same. D will reveal S for C -> D and now C reveals S and uses than for B -> C transaction and B uses that for A -> B transaction.