Say, you and I want to open a payment channel.

1) Putting funds into Lightning

We both send 0.05 BTC into a shared 2-of-2 multisig address. This requires a transaction on the Bitcoin blockchain.

As a "balance sheet", we each create a 2-of-2 multisig transaction that pays out 0.05 BTC to you and 0.05 BTC to me. I sign one payout transaction and give it to you. If you want to put it in effect, you need only add your own signature and broadcast it to the Bitcoin network. Vice versa, you give me your copy of the payout transaction that you have signed and I have not yet.

These "balance sheets" are regular 2-of-2 multisig transactions in the Bitcoin network, they're just not valid yet, because they are each missing one signature. Note that these unilateral payout transactions lock the paid out funds of the executing party for some time.

2) Payment

Now, I want to pay you 0.01 BTC. We each create a new payout transaction ("balance sheet") as before, but this one says that you get 0.06 BTC and I get 0.04 BTC. Each of us gets a transaction signed by the other to that effect as before.

To make sure that neither of us can use the old payout transaction the other signed previously, we each create an "anti-cheat" transaction: It's a transaction that spends the outputs from our first payout transaction to the other.

I.e. when I try to activate the (now obsolete) 0.05 - 0.05 BTC balance sheet, my paid-out funds are locked for a number of blocks. This gives you time to broadcast the "anti-cheat" transaction in which I signed that my 0.05 BTC output gets send to you.

Still, it's safe for me to give that transaction to you, and the whole network, because the "anti-cheat" can only be activated as a response to the fraudulent use of an old balance sheet. By the way, this anti-cheat mechanism is why Lightning needs the Transaction Malleability fix from Segregated Witness.

With the setup as described above, I'd have to be online to catch you trying to cheat, but obviously it wouldn't be safe for me to keep payment channels open if I had to remain online all the time. So, to encourage others to help with the "anti-cheat" transaction, we set a small portion of the "anti-cheat" payout as a bounty that anyone can spend. Now, we can entrust the anti-cheat transaction to all nodes on the network, so everyone can watch for old balance-sheets being broadcast. When it happens, anyone can sign the bounty to themselves and broadcast the "anti-cheat".

3) Network payment

Alright, now you and I can send money back and forth thousands of times, with almost instant effect (depending only on how fast we can communicate with each other) without adding a single transaction to the Bitcoin blockchain. Yet, on the other hand, if one of us ever tried to defraud the other, they would be instantly taken to court by having the dispute resolved on the blockchain to their own detriment. Pretty spiffy, but not terribly useful yet.

By the theory of six degrees of separation, everyone is connected to any other participant by only a few hops. Let's say you want to send money to Bob, who is a barista and just made you some coffee. Bob is a friend of Alice, while I have a Payment channel with Alice. For illustration purposes, let's assume that each payment channel has two BTC in it, split equally. You do not have a direct connection to Bob.

Our "network" now looks like this:

You <-- 1BTC ----- 1BTC --> Me <-- 1BTC ----- 1BTC --> Alice <-- 1BTC ----- 1BTC --> Bob

Now, since you don't have a direct payment channel to Bob (and it would be very inefficient if you had to create a payment channel with every business partner you ever meet), you route your payment through the network. Instead of only writing an update of the balance between Bob and you as I described above, this becomes a concerted effort: Your wallet finds a route from you to Bob that has a) sufficient liquidity, b) least fees, and c) fewest hops. To make a payment, each involved payment channel updates its balances. With a payment of 0.01 BTC for the coffee, this updates our network to:

You <-- 0.99BTC ----- 1.01BTC --> Me <-- 0.99BTC ----- 1.01BTC --> Alice <-- 0.99BTC ----- 1.01BTC --> Bob

As you can see, the balances at the ends have shifted appropriately from you to Bob, but the other participants have the same balance (although shifted to other payment channels). It's important to realize, that the transaction can only go through completely or not at all. Either we all update the balances, or no one does.

Now, imagine that you don't have only the one payment channel with me, but you have maybe a dozen payment channels with other users! :)

4) Consensual channel closing

Other than in the above case where one side closes the channel unilaterally, one of us can request the other to consensually close a channel. When we agree, we create a final payout transaction together that doesn't lock any funds and allows immediate spending after confirmation. We could even use this transaction to spend some of our balance directly to a third party on the blockchain, or to create another different payment channel.

5) Trade-offs

You cannot receive more money through Lightning in one transaction than the sum of your payment channels' values.

Your transactions don't get stored on the blockchain for eternity, (i.e. better payment privacy), but on the other hand you keep using the same address allowing users that know who the address belongs to to monitor your balance (less personal privacy).

Instant transactions! But your money is locked up in a payment channel, which you first need to execute on the blockchain if you want to do a regular Bitcoin transaction with the money.

Less fees! Transactions on Lightning don't require a full blockchain transaction fee, but if you route through others' payment channels, they might want something for the liquidity they provide to you. However, as other Lightning nodes are competing to transfer your payment for you, this is likely to be much lower than a full transaction fee on the blockchain.

Further reading: