Crypto News & ICO Reviews
I commented to a similarly titled post, but I figured I would just make my comment it's own post.
Carol wants to pay Bob over the Lightning Network. They each send 0.5 Btc to a 2 of 2 multisig account. This means both of them need to sign any transactions releasing money from this account. Before they fund the account, they exchange symmetrical copies of "child" transactions which refund deposits back to Bob and Carol. The "parent" transaction would be the funding transaction, and is only broadcast after the refunding transactions are exchanged and validated. Bob can verify that Carol's signature is valid without Carol revealing her private key by comparing the transaction and the signature against the public key.
The first child (refunding) transaction would look like this:
Bob's Copy: (1a):
output 1: 0.5 to Bob, spendable in 1000 blocks. output 2: 0.5 to Carol, spendable now.
Carol's copy (1b):
output 1: 0.5 to Carol spendable in 1000 blocks. output 2: 0.5 to Bob spendable now.
Once the parent transaction has been confirmed on the network, and Bob and Carol agree that their respective copies of the child refund transaction are valid and agreeable, they have a payment channel open. If Bob broadcasts his copy of the refund, Carol may spend her half immediately, but Bob has to wait 1000 blocks. Likewise if Carol wants to close the channel, Bob can spend his half immediately, but Carol has to wait 1000 blocks. They may now use this new feature to exchange new child transactions each which invalidate the old ones. Here's how:
A new child transaction may look like this, if Carol wanted to pay Bob 0.1 Btc:
Bob's Copy: (2a):
output 1: 0.6 to Bob, spendable in 1000 blocks. output 2: 0.4 to Carol, spendable now. (If 1b is broadcast by Carol, Bob may spend output 1 of (1b) immediately, but Carol has to wait 1000 blocks.)
Carol's copy (2b):
output 1: 0.4 to Carol spendable in 1000 blocks. output 2: 0.6 to Bob spendable now. (If 1a is broadcast by Bob, Carol may spend Bob's output 1 of (1a) immediately, but Bob has to wait 1000 blocks.)
In this way, once Bob and Carol have signed and exchanged transactions 2a and 2b, 0.6 to Bob and 0.4 to Carol is the true balance of the payment channel. If Carol then tries to broadcast the old transaction 1b, Bob can spend his 0.5 from 1b which Carol broadcast, and he can also use the new, valid transaction 2a to sweep Carol's funds from 1b before she can get them after 1000 blocks.
Using these time locks and the fact that each new transaction reveals the outputs of the old transactions, each party is encouraged to cooperate.
Lightning network transactions can be done in chains, in other words you can pay someone you don't have a payment channel with by paying them through a payment channel owned by someone else who in turn has one with your final destination. For example, Alice has a payment channel with Bob, and Bob has a payment channel with Carol.
If Alice want to pay Carol, Carol creates a secret R and hashes it to H. Carol then gives H to Alice. Alice gives Bob a transaction that says Bob gets 0.1 BTC in Alice/Bob's payment channel if Bob can supply the R which hashes to H. Bob then gives a transaction to Carol which says Carol gets 0.1 in Bob/Carol's payment channel if Carol can supply the R which hashes to H. Carol knows R, and tells Bob, so she has effectively been paid by Alice through Bob. If Carol broadcasts this transaction to the network, she reveals R to Bob, and Bob can use R to get paid by Alice. But instead of broadcasting the transaction she got from Bob, she holds onto it along with the secret R which unlocks it, and accepts it as payment. Alice can then pay Carol again by repeating the process, and it can even go backwards. Bob can charge a small transaction fee, and Bob can even charge Alice negative fees to pay Carol, if Bob happens to pay Alice a lot.
The lightning network leads to unimaginable off-chain scaling because a virtually unlimited number of transactions can occur on a payment channel once the initial funding transaction has been confirmed on the network. A payment channel only consists of two on-chain transactions, one to open the channel and one to settle the final balance. Transactions are very small, 500 bytes at the largest. Using the lightning network effectively allows users to send a very large number of very tiny payments for little to zero fees.