What is the Lightning Network? In this article, we try to explain how this miracle of bitcoin scalability works. Part 1 is about payment channels.

You only hear the very best of the lighting network. This concept, it is said, solves all scalability problems of bitcoin solving, improves privacy and enables instant transaction.

Yeah. That’s what they say, and it’s not wrong. But if someone promises you now to explain the Lightning Network “quite simply”, you can be sure to have a liar in front of you. Because the Lightning Network is not simple, but monkey complicated. I twisted some nodes into my brain while researching this article, and I will not get around passing these nodes on to you. But I’m trying to make it as simple as possible.

At Bitcoin Every Node Makes Its Own Soup

To understand the lighting network, we have to start with the Bitcoin network. That is, the fact that this is a broadcast network, which means that each node must receive, validate and store each transaction. There is a point to this, but it is obviously terribly ineffective.

 

Imagine a group of 250 people driving from Heilbronn to Antwerp and everyone using their own car. Or: a group of students has to solve 5 math problems together, and everyone calculates all five tasks. Or, another last analogy: Seven guests download the same recipe for the same asparagus soup for eight people from the chef, print it out and buy the ingredients at the same supermarket. Then they go to the host, where everyone makes their own soup in a potty, for which they divide the amount of ingredients by eight.

I could go on like this forever. But I think you understood what the problem is and why some people say: Bitcoin does not scale.

The Lighting Network’s Scalability Is Excellent

The lighting network, which is the subject of the following section, is now eliminating precisely this problem. It forms a network of payment channels that only sends a transaction from the person who sends it to the person who is to receive it.

That means, if I transfer money to Martin now, it does not have to be stored on every node in the Bitcoin network, but basically only on my and Martin’s node. This eliminates some serious weaknesses of bitcoin with a single stroke:

• Privacy: With Bitcoin, everyone notes what everyone does. Blockchain analyses are possible and massively impair privacy. However, if everyone only reads and stores the transactions that are important to them, the blockchain reveals nothing about other people’s money.
• Scalability: A broadcast network like Bitcoin cannot scale or is very poor at it. More participants do not make the network more effective, but only increase the overall data load. It is therefore unlikely that Bitcoin will ever be able to handle the volume of transactions that networks like VISA can handle. With Lightning this is possible without any problems.
• Speed: A bitcoin transaction can be seen almost instantly, but is only confirmed after a few minutes to an hour. Until then, it is possible to reverse the transaction. With the lighting network, on the other hand, transactions are instantly valid.

Strong, isn’t it? The big question now is: Is that even possible? And how is that supposed to work?

That brings us to the cerebral convolutions I promised you. Let’s start with the first part:

The Payment Channels

What is a payment channel? The answer is not easy, so I must ask you to give me some concentration. You’ll understand, I promise.

To open a payment channel, you and I transfer an amount – say 0.1 bitcoin or 40 euros each – to a 2 out of 2 multi-sig address. 2-from-2 means the following: Once the bitcoins are on this address, both you and I must sign a transaction to withdraw them. It’s like a rent deposit account.

After we have transferred the bitcoins to this address, we make a payout – 0.1 bitcoin for me, 0.1 bitcoin for you – and sign it. However, we do not send them to the other Bitcoin nodes, only to us. We then modify the bitcoin transaction over and over again.

You can imagine the payment channel as if I would give you a completed bank transfer form that you can deposit at your bank at any time. Instead of redeeming it, however, we are constantly changing this referral slip. When I pay an invoice to you, I do not instruct the bank to transfer money to you, but send you a new transfer form, on which I have increased the amount. And so on.

Imagine you and I have the mentioned payment channel, into which we both deposited 0.1 Bitcoin. If you want to donate 0.0001 Bitcoin, write and sign a transaction that pays 0.0999 to you and 0.1001 to me. If I now redeem the transaction, I close the payment channel. But I can leave it open and you can donate 0.0001 Bitcoin every day for a year. At the end of the year I can close the payment channel and you get 0.0535 and I get 0.1365 bitcoin. They’ve made 365 transfers, but only one lands on the block chain.

Such payment channels may be practical if the same two parties keep making transactions. But to be really useful in the masses, we have to connect them to a network – to the lighting network. This allows me to make a donation of 5 Euro, which has arrived in my payment channel, to another payment channel route, for example to top up my account at Bitcoin.de.

That’s the idea. Before we get to how the payment channels connect, we need to explain some challenges in setting up the payment channels. Because with these you understand (to some extent) why the confusing new scripts of Core Version 0.12.1 are necessary – and why the structure of payment channels is relatively complicated, but works without having to trust anyone.

Because anything else would no longer be bitcoin.

What’s the Problem?

There are two big problems why a payment channel does not work as easily as I just described. In the Lighting Network white paper, Joseph Poon and Taddeus Dryvja explain these problems and their solutions intensively.

The Hostage-Taking Problem

First, please imagine you and I opening a payment channel. Each of us transfers a bitcoin to the 2-of-2 multisig address. But before you get around to sending me a small donation, I show my true face and say: Hi, I will never close the channel, your bitcoin is locked on it forever, unless you transfer half a bitcoin to this or that address. The deposit of each party in a payment channel can be taken hostage by the other party.

How do you prevent that? Poon and Dryvja have found a clever solution. It sounds more complicated than it is, and once you understand it, it’s very simple: we first make the transaction to open the payment channel, but we don’t send it to the network or sign it. That is, everyone knows what should happen, but nobody has the necessary signatures to trigger the action. So far, the payment channel only exists as an idea.

After that, each of us, starting from this transaction, which theoretically exists, forms the transaction that will close the payment channel. In other words, the transaction with which each of us repays his or her share. If we both want to deposit 1 bitcoin, we now form the transaction to pay 1 bitcoin to each of us. This transaction is signed and exchanged, but not yet sent. Everyone is therefore able to send this transaction.

Only when each of us has the transaction (or signatures) to close the channel, do both parties sign the transaction that opens the channel and send it to the network. This means that anyone can close the channel at any time.

Result: The Bitcoins in the channel cannot be taken hostage, as either party can free them at any time. This model is not yet possible because you need the ID of the previous transaction to sign a subsequent transaction. But introducing the script command OP_Signohash with a soft fork will make this possible.

But this does not solve the second problem.

The Problem of Old Commitment Transactions

Imagine this time you donate me 200 days of bitcoins and shift the balance of our payment channel from 0.5:0.5 to 0.3:0.7. On day 201 you decide to close the payment channel. Instead of the most recent transaction, however, you use the first transaction that was signed by both of us. The result would be that each of us would receive 0.5 bitcoin and it would be as if you had never donated anything to me.

Poon and Dryvja have also solved this problem (theoretically). Unfortunately, a house number gets more complicated now. But trust me, you’ll understand that, too.

Briefly to the terms: Poon and Dryvja call the transaction that opens the payment channel – that is, the bitcoin transfers to the multi-sig address – funding transaction, and the one that closes the payment channel, commitment transaction. To change the credit in the payment channel, we write and sign new commitment transactions.

So as soon as we change our payment channel balances, several commitment transactions exist simultaneously, each with the same right to the blockchain. How can this problem be solved? How do you make sure that only the latest commitment transaction goes to the block chain?

Poon and Dryvja have developed a transaction model that punishes those who emit an older commitment transaction by losing all their credit in the payment channel. This model consists of two parts.

On the one hand you have to recognize who sent the wrong (outdated) transaction. This is relatively simple: you only need to create two distinguishable but virtually identical commitment transactions. The cryptographic framework of Bitcoin makes this possible by each party signing inputs and giving them to the other party signing the entire transaction. Imagine me signing a piece of paper that you put in a letter on which you put your signature, and vice versa. You don’t need to know the details, just the following: This results in two different transactions that do the same thing. It’ll be important a little later.

On the other hand, one must find a way to reverse “false” – that is, fraudulent transactions that violate the contract. The goal must be that only the most current transaction goes through without being revoked or causing a penalty.

This is where a script called OP_CHECKSEQUENCEVERIFY (CSV for short) comes in. This uses the sequence field of a transaction to “freeze” its output: A transaction must receive a certain number of confirmations so that its content can be output. For example, I can send you a bitcoin, but I can write in the transaction that you cannot use this bitcoin until the transaction has been confirmed for 1,000 blocks. So you put a time lock on the transaction.

It is very complicated in detail, but with OP_CSV you can create a transaction model that allows you to change transactions under certain conditions: Each party forms a two-path commit-ment transaction. First, the money is paid out to each party as agreed in the payment channel. This output is “frozen” and requires a certain number of confirmations. Second, the entire content of the payment channel is paid out to the counterparty. This output can only be triggered by the other party and only after the transaction has already been sent – but it can be paid out immediately.

So: If you close our payment channel with an outdated transaction, after which you get 0.5 and I get 0.5 bitcoins, although actually I should get 0.6 and you get 0.4, the output of this transaction only becomes valid after, say, 1000 blocks. As soon as you have sent this transaction, however, I have the possibility to withdraw the entire credit balance of the payment channel to me immediately.

This second output accordingly invalidates a commitment transaction. If you transfer 0.1 bitcoin in the payment channel, you send me not only the signed input for a new transaction, but also the information with which I can bend the previous transaction in such a way that all the credit goes to me if it is broadcast.

This means that as long as we both monitor the payment channel, we can always see if the other is sending an outdated commitment transaction and punishing it by redirecting all outputs of the transaction to us. This makes it virtually impossible to send outdated commitments and makes it a punishable attempt alone. The only associated problem is that both parties to a payment channel must occasionally be online to see if the other party is at risk of bringing an outdated commitment transaction into the blockchain.
vista

The lighting network is therefore the concept of payment channels where we do not need to trust the other party to ensure that the latest transaction draft is the only one that will be valid.

So far, however, this has only been possible in theory. To work, you need CSV – introduced in Core 0.12.1 but not yet activated – and Segregated Witness – which completely eliminates transaction malleability.

The routing problem – the question of how the transaction drafts find their way through the channel network – has not yet been resolved. Hopefully, we will come to this in a follow-up contribution.