deenfr

19 December 2018

Bitcoin’s Lightning Network & Innovative Business Models

Dr Lewin Boehnke

Dr Lewin Boehnke

CTO at Crypto Storage AG and Head of Research at Crypto Finance AG

About the author

Disruptive Technologies Drive the Emergence of Innovative Business Models:
a Peer
to-Peer Based Interest Rate and Savings Account Without Counterparty Risk

As blockchain technology matures, the market becomes more professional and measures are taken to eliminate its weaknesses. Bitcoin, as the most famous cryptocurrency, is often criticised for its scalability problem, i.e. the fact that only a limited amount of transactions can be done per second. A traditional payment solution provider such as VISA is able to process up to 56,000 transactions per second (around 2,000 on average), whereas bitcoin is only able to process between three to around ten transactions per second (depending on transaction type).

It is well known that necessity is the mother of invention. Consequently, an idea emerged where transactions are conducted off-chain but retain the security standard of on-chain transactions. This is the Bitcoin Lightning Network. This second layer protocol, run on the bitcoin blockchain, enables fast transactions through a network of bidirectional payment channels. The network makes it possible to process millions of transactions per second (using bitcoin as a payment method) via its second layer protocol called Lightning. Transaction settlement can be done instantly due to the off-chain architecture.

Does this mean that bitcoin will soon be usable as a currency?

Excepting the volatility risk, we would argue “Yes”. The Lightning Network offers incredible progress toward the use of bitcoin as a medium of (instant) exchange. However, this is not the subject of this article. Instead, we would like to focus on the interesting topic of the time value of bitcoin and the Lightning Network Reference Rate (LNRR), introduced by Nik Bhatia, and the idea of establishing a savings account without any counterparty risk and peer-to-peer based interest rate.

We will start by giving you a general overview of the Lightning Network, its payment channel structure, and the concept of routing. After that, we will go into more depth about these two business models and address the associated limitations. Lastly, we will then take things one step further in our next research report. Since the possibility of determining a risk-free interest rate of bitcoin would affect the price determination of bitcoin derivatives, we will analyse the resulting differences concerning the recent (and the potential future pricing) of bitcoin derivatives considering the Lightning Network Rate (LNNR).

About the Lightning Network and its Payment Channels Structure

As already mentioned, bitcoin is often criticised for its scalability problem. The root cause for this is also one of its highly appreciated core characteristics – the recording of every transaction on bitcoin’s main chain. Joseph Poon and Thaddeus Dryja proposed a solution with the implementation of the Lightning Network in early 2016, summarised in their whitepaper “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments”.

The Lightning Network is based on a second layer protocol run by the bitcoin blockchain. The three companies Blockstream, Acinq, and Lightning Lab are involved to the extent that they develop and provide the lightning protocol and the associated ecosystem, e.g. with c-lightning, eClair, and lnd. In order to solve the scalability problem, transactions are processed off-chain instead of on-chain, meaning that transactions can be conducted without actually transferring the custody of funds. This can be achieved by using an interchannel rebalancing mechanism, which makes the processing of several thousands of transactions per second possible in an instant and nearly commission free.

In Fig. 1 below, you will see an illustration of the relation between bitcoin and the second layer protocol Lightning.

Figure 1: Relation between bitcoin’s main chain and the Lightning Network

From Fig. 1, it can be derived that the Lightning Network is on the one hand independent of bitcoin’s blockchain, but, on the other hand, it is still interacting with bitcoin’s main chain. At any time when a payment channel is opened or closed, communication with the main chain will occur. The Lightning Network itself consists of nodes. If payment channels are opened properly, these nodes process and are able to route lightning transactions. The connection between two nodes is called a payment channel, or to be more specific, a bidirectional payment channel with a hashed timelock contract.

As soon as two parties have funded a payment channel, the funds become locked via a multi-sig contract between the corresponding parties. From an application-oriented perspective, this can be compared with the storing of funds within a safe “off-chain”. Every channel is limited to its funding amount, meaning that transactions routed by a channel can only be processed up to the initial funding amount (more details on this below in “The Concept of Routing”). Additionally, multi-sig implies that the safe can only be opened if both parties sign a transaction. As long as the funds remain in this safe, they can be transferred instantly between the corresponding participants. After any transaction, the two parties then update the recent state amongst themselves like an ever-shifting balance sheet. This is somewhat akin to the decentralised concept of real time gross settlement (RTGS) and CLS (continuous linked settlement) found in traditional banking with the significant difference of being trustless.

When one party submits the state back to the blockchain, the payment channel will be closed and the latest transaction balance will be broadcasted to the blockchain – but potentially, the timelock will need to be expired. Finally, the funds are available again on bitcoin’s main chain. Since there is no possibility of receiving and sending more money than initially funded and locked, the entire concept results in a zero-sum game.

The participation in or the usage of the Lightning Network is possible by either running a full lightning node (internal node) or by using a lightweight wallet (SPV) software application to send transactions (external node or leaf). The terms internal and external nodes stem from data structure theory. Whereby an internal node describes a node with at least one child, a leaf is characterised by no children. Currently, the receiving of transactions is only possible by running an internal node; however, an increasing interest in Lightning has fostered several initiatives to develop a lightweight wallet, which will allow for the participation in Lightning without the need for a full node.

In the wake of the Lightning Network, both node forms differ also in transaction liquidity: whereby the usage of a leaf is limited to the conducting of transactions (restricted using of the liquidity), an internal node may function as a routing provider (liquidity provider). Due to the nature of our research, this report focuses on the running of a full lightning node (internal node), and the possibility of earning an interest rate for providing funds to the network.

The Concept of Routing

Apart from the payment channel structure, the Lightning Network is characterised by its routing systematic. In order to send transactions through the entire network and not only to any direct peer using already established payment channels, nodes with enough liquidity into the right “funding direction” might act as a kind of bridge. These nodes are referred to as “routing-nodes”.

Let me explain this functionality with an example: Cornelius would like to make a Lightning transaction with Florence to settle his debts resulting from yesterday’s dinner. Unfortunately, the two friends have not yet opened a direct payment channel between them. They then realise that they have an “indirect” channel via Daisy and Eric. And since there already is a payment channel between Cornelius and Daisy, who also has a channel with Eric, who in turn has a Lightning channel with Florence, an indirect payment channel is found. In Fig. 2 below, you can see an overview of this rather complicated constellation.

Figure 2: Concept of Routing: Initial Positions

Apart from the fact that there is a payment channel connection in general, there is no information as to “how” the single channels are currently being funded. The channel funding and the associated channel allocation has a significant impact on the routing capability and the resulting possibility of forwarding the transaction. In order to give an overview of some extrema, please take a second glance at Fig. 2 above and the three different initial positions exhibited.

A payment channel can be compared with slide control. Aviv Zohar, Associate Professor at the School of Engineering and Computer Science at The Hebrew University and The Chief Scientist at QED-it, states that “you can think of it as if we are in a state space between 0 and 10. If we are just transacting in single units of bitcoin, we are just moving around there”. Therefore, we tried to integrate the “funding direction” in the overview. So, let us explain this statement more in depth and let us assume the following channel allocations (c.f. Fig. 2):

Channel Allocation 1:
– Cornelius fully funded a channel with Daisy in the amount of 200 satoshis
– Daisy fully funded a channel with Eric in the amount of 50 satoshis
– Eric fully funded a channel with Florence in the amount of 100 satoshis

Channel Allocation 2:
– Cornelius partially funded a channel with Daisy, both in the amount of 100 satoshis
– Daisy partially funded a channel with Eric, both in the amount of 25 satoshis
– Eric partially funded a channel with Florence, both in the amount of 50 satoshis

Channel Allocation 3:
– Daisy fully funded a channel with Cornelius in the amount of 200 satoshis
– Eric fully funded a channel with Daisy in the amount of 50 satoshis
– Florence fully funded a channel with Eric in the amount of 100 satoshis

As already mentioned, if there is an indirect payment channel from Cornelius to Florence, he has the possibility to transfer his funds using the concept of routing. Moreover, he does not face the necessity to open (and thus fund) a new, direct payment channel because, in general, the opening of the payment channel is associated with a transaction fee because of the associated on-chain transaction. Coming back to the channel allocation opportunities, we can derive two extrema: one-sided, fully funded payment channels (c.f. Channel Allocation 1 and 3), and perfect equally funded channels, as can be seen in Channel Allocation 2. In practice, every slide control position is possible.

Depending on the current state of these routing channels and the corresponding slide control position, the following transactions (maximum gross channel amount) between them are possible:

Figure 3: Concept of Routing – Case Scenario: maximum transaction amount

At first glance, one might quickly recognise that in the case of Channel Allocation 3 exhibited in Fig. 3, no transaction from Cornelius to Florence is possible. Since the channels are funded “in the wrong direction”, only transactions from Florence to Cornelius could be routed. The same situation can be actually observed in Channel Allocation 1, but with the significant difference that a transaction is possible due to the “perfect” funding allocation for this transaction – but let us play this routing game step by step:

1. Cornelius might transfer up to 200 satoshis
2. BUT Daisy ONLY has a routing capacity of up to 50 satoshis
3. Finally, Eric would be able to forward 100 satoshis

Therefore, we can draw the conclusion that a routing path cannot forward more than the smallest channel capacity within the corresponding path. In this case, no more than 50 satoshis can be transferred. Other paths through the network might be able to route larger payments between Cornelius and Florence.

By considering Channel Allocation 2, one might observe the same issue with the difference that the situation is even worse. Due to the payment channel equivalence between Daisy and Eric, she is now only able to forward 25 satoshis.

To sum up, not only the funding amount of a payment channel, but also the channel allocation has a considerable influence on a node’s routing abilities.

We have neglected to mention the previously described “routing fees” so far. In exchange for routing the payments, the payment sender, who is in this case Cornelius, must pay a fee to the routing nodes. For the net calculation of our dinner scenario, please take a closer look at Fig. 4 below.

Figure 4: Concept of Routing – Case Scenario: maximum transaction amount, incl. routing fees

It is necessary to clarify that every node provider has the opportunity to determine its own routing fees within its node settings. These fees are composed of a base fee rate and a proportional fee rate (to the transaction amount). In our case scenario in Fig. 4 above, we used a base fee of 1000msat (= 1 satoshi) and a proportional fee rate of 100ppm (parts per million) = 0.01%, meaning that the sender must pay 100 satoshis for every 1,000,000 satoshis transferred. Even though a dinner between 50 or 200 satoshis is not feasible, these are realistic fee rates, which have been recently applied in the Lightning Network.

As soon as we take into account that Daisy and Eric charge the fees mentioned above, the maximum transaction amount of the corresponding channel decreases by one satoshi due to the smallest channel capacity of 50 satoshis between Eric and Daisy. Even if Cornelius transfers 52 satoshis, the remaining two satoshis would be stuck in the channel with Daisy.

The Lightning Network Rate (LNNR) – a Peerto-Peer based Interest Rate for Bitcoin

After having now described how the Lightning Network works, the one or other reader might already have an idea of the possibility concerning the “technological” determination of interest rates. Nevertheless, most readers will ask themselves how an interest rate might be determined if every node provider could set its own fee rates. To be honest, that makes no sense, does it?

The answer is a peer-to-peer based interest rate. One property of the Lightning Network is the “free choice” of the transaction path. Nevertheless, every default setting of a Lightning application generally selects the cheapest path due to the routing algorithm employed. This seems quite reasonable from an economical point of view due to the general rule that a market chases efficiency. Therefore, the channels, which are not in line with the fees of the great majority, will never be actively used.

The routing algorithm employed also considers influencing factors, e.g. the payment channel volume, the possible connections, but also (as previously mentioned), the associated transaction fees. In order to analyse which transaction paths are possible, the Light Pathfinder tool, provided by lightningfees.net, could be used (see Fig. 5). Such tools rely on public information of the network, where the current allocation of funds in a channel is private information between the two involved parties. While qualitatively accurate, the precise numbers might be off.

Figure 5: Visualisation of Transaction Paths
Source: Lightningfees.net

Using this example, we tried to conduct a transaction from our Crypto Finance Research Node (“CRAG”), in Fig. 6, called “Source”, to a BitMEX Research Node called “Destination”. As you can see, there are several routing paths available for this transaction. The paths differ in transaction fees and the number of nodes involved. In this particular case, there is either the possibility to route via one node to four nodes.

According to the whitepaper by Poon and Dryja, the general rule states “smaller transfers with more intermediaries imply a higher percentage paid as Lightning Network fees to the intermediaries.” In practise, however, every node has its own routing fee settings. Taking a second look at Fig. 5, you might recognise the corresponding channel fees exhibited by the arrows between the channels. The number in brackets below indicates the maximum routing amount for this corresponding channel. In our example, a maximum of 5 million satoshis (~ USD 177) could be transferred between CRAG and the BitMex Research Node for a fee of 1000 satoshis (~ USD 0.035). This equals a percentage fee of approximately 0.02%. An overview of the correlation between the transaction amount and the corresponding transaction fees for our sample transaction can be found in Fig. 6.

Figure 6: Transaction fees in proportion to the Transaction Amount
Source: Lightningfees.net

As you can see, the fee chart is shaped by terraces whereby each stagger represents a different transaction path. The different paths are marked in gold in the path visualisation above the terraces. Since the base fee is commonly one satoshi or 1000msat, respectively, the transaction fee is mainly due to the proportional fees of the different paths.

Using this example, one might recognise that transactions up to 1,700,000 satoshis are almost commission free. Suddenly, the first [second] terrace emerges implying that a different channel needs to be used for a transaction in the amount between 1,700,000 [3,000,000] satoshis to 3,000,000 [4,500,000] satoshis, whereby a higher proportional fee rate is applied. The maximum payment amount between these two nodes is limited to 5,000,001 satoshis. Generally, the maximum payment channel amount is limited to 16,777,215 satoshis, as defined by the current Lightning protocol restrictions. Additionally, the chart supports the described proportional relation between transaction amount and transaction fee.

Especially from an economical point of view, questions might be raised concerning the incentives of providing a Lightning node. In recent times, routing fees that might be earned by providing a node have varied significantly. Nik Bhatia referred in one of his articles to a Twitter post made by Alex Bosworth sharing their node statistics (c.f. Fig. 7). The data reveals that Alex earns a 0.4% interest rate on his principal amount provided, which, in turn, is “material income” in recent times by taking into account the interest rates offered by banks. Controversially, Andreas made less even though he provided a larger principal amount. This might be due to his node settings and positioning. While technologically sound in itself, the infrastructure around lightning is very much still evolving. How should a node choose its peers to position itself well as a route, and, subsequently, receive relevant fees? When should a channel be closed based on the changed global situation and reposition? Fully automated approaches, so called autopilots, are very much underperforming human experience these days. Successful heuristics are proprietary information.

Figure 7: Node Statistics
Source: Medium Post by Nik Bhatia

In this context, we have to mention explicitly that these stats are not representative. However, they do hint toward the general possibility of earning an interest by providing liquidity to the Lightning Network. This approach allows investors to measure their opportunity cost of bitcoin. The larger the Lightning Network becomes, the more representative data will be available. Of late, the network is based neither on rationality nor on efficiency. There are several people acting as Lightning enthusiasts and thus providing liquidity for free, implying that they are running a node without any economic incentive.

Ben Woosley, a developer of the Lightning wallet app Zap, stated, “As the network grows and a smaller portion are using it for ideological reasons, fees will move toward a more economic outcome.” Factors such as node positioning, the number of channels, and their funding amount might have a significant influence on the economic performance of a node.

From an economical perspective, the concept of routing fulfils two tasks akin to a centralised, traditional commercial bank and the central bank: providing liquidity and determining an interest rate. The difference is that the Lightning Network takes charge of this task in a decentralised manner. An interesting approach emerges to determine interest rates on a peer-to-peer basis and not the centralised determination by one or several central banks.

A Savings Account without Counterparty Risk

A savings account is an interest-bearing deposit account held at a bank or other financial institution that provides a modest interest rate. In every traditional, interest-bearing financial product offered, the involvement of a counterparty such as banks, insurances, or other third-party companies is required. Even with the so-called risk-free treasuries, a counterparty risk is associated in form of state bankruptcy.

Besides the fact that Lightning offers a risk-free interest rate for providing liquidity in form of bitcoins to the Lightning Network, a further interesting property arises: there is no counterparty involved. In this context, Poon and Dryja compare the concept “to a gold lease rate without custodial risk”.

Counterparty risk is the risk to each party of contract that the counterparty will not live up to its contractual obligations. In Lightning, the funds are locked via a multi-sig contract due to hashed timelock contracts (HTLCs). When this timelock is due, the latest balance will be submitted. Therefore, the contract is enforced either when counterparties cooperatively close the payment channel or when the timelock is due. Thus, the counterparty risk is replaced by a protocol risk due to issues associated with the cryptographic pegging.

Starting from the Bottom, now we have around 13,000 Channels

The Lightning Network was launched in mid-January 2018. On December 10, there were around 4,000 nodes. Its current network capacity contains around 160BTCs in the amount of USD 1,700,000. According to Jonas Schnelli, one of bitcoin’s main developers, “channel amounts will slowly increase as confidence rises.” A recent snapshot of the Lightning Network, meaning a visualisation of the 4,000 nodes and its 13,093 payment channels, can be found in Fig. 8 below.

Figure 8: Visualisation of the Lightning Network
Source: Recksplorer (10.12.18)

Therein, the single nodes are shown as labels by their “nicknames”. Some inter-esting examples are “SWIFT.connect”, ”***ROUTE 66***”, “VISA Killer” or “RebelDinosaur [LND]”. The colourful lines between them represent the opened payment channels. On closer inspection, one might also identify a structure as to how they are linked to each other, resulting in a kind of hub and spoke system. Some nodes have many payment channels and thus act like a hub. According to Poon and Dryja “eventually, with optimisations, the network will look a lot like the correspondent banking network, or Tier-1 ISPs.”

This assumption is supported by a recent network trend: since mid-November, the network capacity has increased by around 320%. This development is mainly due to a provider of the so-called “LNBIG.com [lnd-xx]” nodes whereby “xx” represents a placeholder ranging from 01 to 42. In short, an unknown party provides at least 20 nodes with channel capacities ranging from 15BTCs to 26.7BTCs (~ USD 53,204 – USD 94,655 on December 10, 2018), with an ongoing upward trend in evidence. Unfortunately, we cannot make any specific statements about their transaction and routing volume, since the information is private.

Limitations of the Lightning Network

Although the concept of Lightning proposes a considerable approach concerning the scalability problem and other bottlenecks associated with bitcoin, the second layer protocol still has some limitations.

The major issues are due to the early development state of the network and the surrounding ecosystem. Since full participation (sending and receiving of transactions) is only possibly by running an internal node, access is more or less restricted to people having the necessary expertise to set up and run a node. This leads to a limited number of participants and liquidity within the network.

Additionally, the Lightning Network can easily be dominated in the current state, c.f. the entrance of LNBIG. Thus, the decentralised establishment of an interest rate is not possible and the network might be easily centralised. Moreover, the routing systematic is not completely matured. In consideration of Lightning’s upper limit on channel funding amounts, larger payments are most likely to fail since they cannot be successfully routed. This leads to the fact that Lighting is currently (only) suitable for smaller transactions.

However, optimisation measures have already been taken with the implementation of the so-called multi-path routing for payments. This mechanism allows the splitting up of a payment in multiple partial payments, which will be routed by all channels available that together make up the total amount. Therefore, it becomes possible to overcome limitations of a single funding channel amount.

In conclusion, we can state that Lightning represents an effective approach to solving the scalability problem of bitcoin. Furthermore, some interesting business models have emerged in this context. When the network grows, it becomes more stable, and thus a representative LNNR might be established, which influences the derivatives pricing of crypto assets. In our next research report, we will be conducting a thought experiment, where we analyse how this interest rate could influence the pricing of bitcoin futures.

Download Lightning Research Paper as PDF

Read more