Category: layer 2

Atomic Swaps and HTLCs

Atomic swaps are a method of exchanging one asset for another, such as two cryptocurrencies, even if they exist on distinct blockchains. The idea is to do this in a trustless way, avoiding counterparty risk, so that the swap either goes ahead and both parties receive what was agreed, or the whole thing is cancelled. It should not be possible for one ‘leg’ of the exchange to go through on its own without the corresponding payment. So, we can treat the entire exchange as a single trade which either goes through or not. As separate blockchains exist in isolation, and cannot directly communicate, atomic swaps are a useful cross-chain solution. They help to build a more interoperable ecosystem of interacting blockchains. Furthermore, atomic swaps can also be used with off-chain payments such as on the lightning network, connecting these with on-chain transactions.

atomic
If Alice hands over her bitcoin first, can she trust Bob to give her the ether?

Consider the scenario: Alice owns bitcoin, which she wants to use to purchase ether from Bob. The exchange rate (BTCETH) at the time is about 13. So, they agree to a swap where she sends one bitcoin to Bob and, in return, he sends 13 ether to Alice’s Ethereum account address.

This is fine in theory but, before sending her payment transaction to the Bitcoin blockchain, she has second thoughts. What happens if Bob does not submit his corresponding transaction? In that case, she will have sent him the bitcoin with nothing in return. Can he really be trusted? So, she asks Bob to submit his transaction first. However, Bob is also not really sure that he can trust Alice. If he submits his Ethereum transaction before Alice’s payment is confirmed, how can he be sure that he will be paid? To be safe, both parties in this transaction want the other to confirm their payment first. Consequently, they do not go ahead with the exchange.

What can be done to resolve the issue of trust and counterparty risk? This is not something specific to cryptocurrencies. Whenever two parties want to exchange any items of value, there is the possibility that one of them will not follow through with their side of the agreement. Here are three possible solutions. Continue reading “Atomic Swaps and HTLCs” →

Lightning Channels

lightning

The Lightning network is a layer 2 solution allowing for cheap and near-instant bitcoin payments. As with standard ‘on-chain’ transactions, it works in a peer-to-peer fashion without requiring trust in third parties. This network is built up from a collection of connected payment channels between pairs of individuals, each of which operates by exchanging zero-confirmation bitcoin transactions which are not actually submitted for inclusion in the blockchain. This reduces load on the chain, and allows settlement to occur in fractions of a second — much less than the 10 minutes average block production time.

Here, I concentrate on explaining how a single payment channel between two parties operates. The method by which these channels are connected to route payments will be explained in a separate post. I did previously discuss the use of zero-confirmation transactions to speed up payments, and the considerations leading to the idea of Lightning channels. Now, I will give a more detailed description of how this works. For more information, see the Lightning whitepaper. Also, medium.com has a pretty good explanation of how and why payment channels work in the way that they do.

To aid the exposition, let us suppose that two parties named Alice and Bob set up a payment channel between themselves. It is initially funded with 100 coins, with 50 from each of the two parties. At today’s prices, 100 bitcoin would be rather a lot to commit to a channel. I choose this quantity simply for a nice round number, and you can suppose that it is in units of 0.0001 bitcoin or 10,000 Satoshi, for more reasonable values.

Next, Alice and Bob start making payments to each other. As they already have coins locked up in the channel, this can be done by simply updating the quantities of these coins belonging to each party. See figure 1 below where, once the channel is funded, one payment is made on each of four days. They keep a tally of the amount of coins owed to each person, updated after every transaction. After this, the channel is closed and Alice and Bob receive back their current balance of coins.

This is, of course, a much simplified example. In practice, many thousands of payments could be completed before the channel is closed. Also, multiple payments could be made per second, rather than just once per day as here.

Time Event Alice Bob
Start Channel open 50 50
Day 1 Alice pays Bob 5 45 55
Day 2 Alice pays Bob 7 38 62
Day 3 Bob pays Alice 20 58 42
Day 4 Alice pays Bob 6 52 48
End Channel close 52 48

Figure 1: Channel payments.

How does this look, in terms of transactions actually submitted for inclusion in the blockchain? The situation is shown in figure 2. There are only two on-chain transactions. The first of these is to fund the channel and has two inputs, one from Alice and the other from Bob, so they both must sign for it to be valid. The output is to a multi-sig address requiring both Alice and Bob to sign to release the coins.

channel on-chain
Figure 2: Lightning channel on-chain transactions.

Nothing further is done on-chain until the channel is closed. At this time, a single transaction is made from the multi-sig address and paying each of Alice and Bob their closing channel balances. Since it is multi-sig, both Alice and Bob must sign this transaction. Continue reading “Lightning Channels” →

Zero-Confirmation Transactions

The Lightning network is gaining in adoption, and is currently being used worldwide to enable fast and cheap bitcoin payments. I will describe some of the issues that led to its invention, and hopefully help to understand why it works in the way that it does.

Picture the scene. As the owner of a coffee shop, you make the decision to start accepting bitcoin payments. Your first customer, Alice, enters the shop and orders a coffee. She takes out her mobile phone, opens the app for her bitcoin wallet, and scans the QR code for your bitcoin address which you have displayed by the counter. All she needs to do now, is to send the correct payment. Easy!

coffee shop

Well…not quite so easy. To be certain that the transaction is secure, we should really wait for it to have the requisite six confirmations before giving Alice the coffee. That is, it should be added to the blockchain, and have a further five blocks added on top. As it takes an average of ten minutes for each block to be produced, we can expect to have to wait around one hour. This is rather a long time to keep people waiting.

What can be done? As it is just for a coffee — not a major payment — we might be ok with fewer confirmations. Maybe just one will be sufficient, meaning that we simply wait for the transaction to be included in a block. It still takes ten minutes though, and remember that this is just the average. The time taken for a block to be produced is random so, if we are unlucky, it could take considerably longer. An hour for a block is not unheard of.

We really want to be able to accept Alice’s payment within a few seconds. There is no way around it, we are going to have to accept zero-confirmation bitcoin transactions. Either Alice sends her transaction to the network, and we monitor Bitcoin nodes to check that it has been received, even if it has not made its way into the blockchain yet. Alternatively, Alice can send her transaction directly to us and we will make sure that it is transmitted to the network to be included in a block.

Accepting transactions with zero confirmations does leave us vulnerable to double spend attacks, which is one of the main things that the blockchain was invented to solve. This is where Alice, possibly with an accomplice, spends the same coins multiple times with different counterparties. Even if we were to do this, and risk losing payments to double spends, we still need to ensure that the bitcoin transaction fee is sufficiently large to be accepted by miners for inclusion in a block. So, Alice will be rather upset that this fee is several times larger than the cost of the coffee she is buying. More fundamentally, the Bitcoin blockchain simply does not have the capacity to include lots of such small every-day payments by millions of people around the world.

busy road

Scalability Problems

Summarizing the issues raised so far, the following three problems need to be solved in order for Bitcoin to be useful as a mechanism for small, quick and common payments such as buying a coffee.

  • Speed. We should be able to accept payments in a matter of seconds.
  • Cost. The fee for a transaction should be small. No more than a few cents at most.
  • Capacity. The network should be able to handle millions of people around the world making such transactions regularly.

Continue reading “Zero-Confirmation Transactions” →