Lightning: How Payment Channels Build up a Network

The second part of the Lightning Saga; how can Payment Channels build a network? How is it possible to send bitcoins to someone else, without maintaining a channel with them? Why is no trust in a third party needed? And how can Lightning Nodes find a path through the network? After reading our explanation, you will know more.

The most important thing to be said about Lightning is, again, that the explanation will not be too easy. If you have been able to wrap your brain around how Bitcoin works, you will find the next challenge in understanding Lightning.

Before we come to the topic of this part of our series, we repeat the most essential basics; Lightning is a network of off-chain transactions, meaning transactions which do not go on the Bitcoin blockchain but are nevertheless valid and trustless. The advantage is that you do not need to wait until a miner confirmed to know you have been paid, and, maybe most importantly; you do not store your transaction on the public blockchain which is duplicated by every node of the network. With this architecture, Lightning solves some fundamental issues of Bitcoin regarding scaling and privacy.

If you think it sounds good, you should start to try to understand how it works.

Payment Channels

The basic units of Lightning are Payment Channels. You can imagine them like continuously editing and signing a transaction form without submitting it to your bank.

Precisely both parties of a Payment Channel send each other signed Bitcoin transactions, but never propagate the transaction to the network. As the transaction is updated with each payment, you can send as many transactions through the payment channel as you like. When the transaction finally is sent to the miners and confirmed on the blockchain, the channel is closed.

To build the Payment Channel, both parties use a shared multisig address which can only be updated when both agree. They open the channel by sending an amount of bitcoin to this address. Both parties have to send bitcoins in, and usually, with a channel, you can only receive as many coins as you initially put in.

Several smart contracts guarantee that both parties do not need to trust each other, as it is not possible to cheat. Neither can a party hold back the funds of the other party nor can it release an old transaction to the network and thus undo a later payment. The only condition for Lightning’s Payment Channels to work without trust is that both parties are permanently online, or, at least, once in a specific amount of time.

If you want to understand deeper how the Payment Channels are built, you can read the first part of our Lightning Saga. In this part, we turn toward how the channels build a network. This is the most important part of Lightning, as Payment Channels might be a charming technology, but as the implementations of both 21.co as SatoshiPay demonstrate, there is not much market demand for it. You can only use them in some special cases. To make Payment Channels mainstream, you need to merge them into a network. The big question is; how can this be done?

How the Channels Build up a Network

Now we come to the funny part. While Bitcoin transactions, as we know today, are received, validated and relayed by every peer and stored after they are confirmed by the miners, Lightning transactions only flow from the sender to the receiver, who store and validate them.

It is easy if you have only two parties, let us call them Donald and Wladimir. But what happens when we introduce a third party, for example, Angela? Image Donald has a channel with Wladimir, and Wladimir also has a channel with Angela. The idea is that Donald can now use Wladimir as a hub to send his transaction to Angela. But how is this possible?

Basically, it is easy. Donald sends one Bitcoin or, more precisely, the transaction for a Bitcoin – to Wladimir, and Wladimir sends one Bitcoin to Angela. Maybe you know the popular board game Risk. The rules of this game say that after each turn every army is allowed to move across one border. For example, you can move one army from Brazil to Northwest-Africa. Since the army, which has been in Northwest-Africa before, has not moved yet, you can transfer it to Egypt. And so on. Similar to the couriers of the 18th century which changed the horse on post camps.

Image from Islam Hassan via flickr.com. Lizenz: Creative Commons

The yellow player can move armies from Mexico to Egypt, even when each army can only cross one border each round.

With this scheme, we have the basic topography of the Lightning Network. The payments run through the channels. If you add more parties – let’s say, Francois has a channel with Angela, and Mariano with Francois – you can route the transaction from Donald to Mariano via Wladimir, Angela, and Francois. And so on.

The exact architecture of the network is not known by now. There are endless possibilities. It might be completely decentralized with every user maintains several channels and the payments route through a myriad of possible paths. At the same time, there might emerge powerful hubs, which locks a lot of money in a lot of channels and make it easy for every user to find the path to the goal. Those channels might earn a lot of money by observing the payment habits of their customers or by collecting fees for routing services.

The golden question however is; how can this work without trust? If Donald gives Wladimir a payment with the request that he passes it to Angela – how can he knows that Wladimir does not say: “Guys, I just keep it?”

The answer is not easy to understand. But let’s give it a try.

Hash Time-Locked Contracts

The solution is known as Hash Time-Locked Contracts. It is an ugly term, but it makes sense; to receive money from Donald, Angela generates a random value. Let us call it R. R is just a number of signs, like a password.

Then Angela creates a hash from R. A hash is the result of a cryptographic operation which transforms a given string of signs in another string of signs. It has two important properties: The result of the operation is always the same, and it is not possible to recalculate the initial value with the hash. That is why it is called a one-way function.

Now Angela takes the hash and gives it to Donald, who promises Wladimir one Bitcoin if he gives her the initial value of the hash. It is like a riddle; Angela gives Donald the riddle, and Donald promises Wladimir a reward for the solution. Since we do not trust anybody, Donald does not just promise something, but generates a special kind of transaction; a so-called Hash Contract.

To understand this, you need to know that every transaction uses a script. A standard transaction says: “You are allowed to spent me if you sign a new transaction with the private key corresponding to this or that address.” A Hash Contract, however, says: “You can spend me when you give me the correct signature AND the solution to the hash riddle.”

Donald sends such a transaction to Wladimir. To spent the outputs of this transaction, Wladimir needs to ask Angela to give him the value which was used to build the hash. It is like he needed a password. Angela gives him only the value if Wladimir gives her one bitcoin, and when Wladimir has the value, he can receive the bitcoin from Donald. Operation successful.

But wait. How can you know that Wladimir really passes the transaction on? He could be just happy to see Donald’s bitcoin locked, even if he does not receive anything? Donald’s transaction sticks in nowhere, and maybe Wladimir can demand an extra payment from Donald to release it.

Here the Time-Locked-part of the contract enters the scene. A Lightning transaction can be redeemed by two methods; first, as already mentioned, if the receiver shows the value of a hash and signs the transaction with his private key. Second – and this is the safety net – if the sender signs it with their signature. To prevent the sender from cheating, this option is time locked; it can only be used after a certain amount of time has passed. So if Wladimir does not pass the transaction to Angela, Donald can take it back after some time. The worst outcome is that a transaction is frozen for some time.

So. It was not as complicated as expected, was it? We could extend the scenario, by introducing Francois and Mariano. In this case, the sender gives the hash forward the path to the receiver, while the receiver pushes the solution for the hash-riddle back the path to the sender. It’s generally nothing new, only that the time-locks have to be set that the channels cascadingly collapse.

With this, the question, how Lightning works without trust, is more or less answered. More difficult however is the question how each user learns to know the path their transaction has to take to reach its destination.

Flare, Sphinx, Onion Routing

To initiate a Lightning transaction you ideally need nothing more than a hash. Angela wants money, so she sticks a hash somewhere, and when Donald wants to pay her, he sends money to the hash. This is how it goes in a perfect world.

The trick however is to tell the Lightning nodes which way a transaction has to go. How can you achieve this without a central node? This becomes further complicated as not every intermediary is equal. Each can only pass as much bitcoin as he has locked in the channel. When Donald wants to send one bitcoin to Angela, but Wladimir has only locked 0.5 bitcoin in the channels, Donald needs to find an alternative path.

Some say that this routing problem is the real challenge of Lightning and that it is a problem impossible to solve without introducing central hubs, which would be a privacy disaster. However, others say that a decentralized routing is not only possible but already implemented. Since Lightning is currently not tested in a real environment, it is hard to say which side is right.

The most competent source for it might be the Lightning developers. Rusty Russell from Blockstream, blogged about the so-called Onion Routing in late 2016:

“On the Internet, routing is easy. You throw a packet out with an address stamped on it, and the recipient figures out how to get it closer. It mostly Just Works. If you want anonymity, that scheme doesn’t work.”

Since anonymity is a big issue for everybody working at Blockstream, Rusty writes, they needed to search for a solution. And they found it in the so called Sphinx scheme, which has been published earlier and already implemented by Christian Decker and Olaoluwa Osuntokun.

Sphinx is a protocol developed by George Danezis and Ian Goldberg. According to the whitepaper is is “a cryptographic message format used to relay anonymized messages within a mix network. It is more compact than any comparable scheme, and supports a full set of security features: indistinguishable replies, hiding the path length and relay position, as well as providing unlinkability for each leg of the message’s journey over the network.”

Implementing Sphinx in Lightning has the result, Rusty continues, “that no node can tell how many hops have already passed, or how many remain; only the previous and next hops.” It is not easy to achieve this robustly, but the developers are on it.

An alternative to Sphinx is the Flare protocol which was developed by BitFury. The company wrote a whitepaper about it in late summer 2016. Flare was tested by ACINQ, a French startup which built the first Lightning prototype. According to BitFury ACINQ has been able to find a route between 2,500 AWS nodes quickly and robustly. This gives Flare the potential to be the routing algorithm for higher scalability:

“The design goal for the algorithm is to ensure that routes can be found as quickly as possible for the Lightning Network while minimizing the amount of data stored on devices and maintaining decentralization. This is accomplished at the cost of each node proactively gathering information about the Lightning Network topology, as well as reactively gathering information about the topology as needed for transaction requests.”

So it seems that the challenge of Onion Routing is not entirely solved. But the developers seem to be on a good path to solve it.