The authors: Roberto Lorini, Marco Monaco, Emanuele Coscia
In the whitepaper introducing Bitcoin, the ambitious project created by anonymous Satoshi Nakamoto, Bitcoin is proposed to be “peer-to-peer electronic cash”.
Despite its native characteristics, many people argued that its scarcity property and the commission fees necessary to send Bitcoin transactions made it more similar to digital gold instead than “cash”.
Along with the spectacular growth of Bitcoin’s price occurred during the last months of 2017, a well-known issue of its technology as “electronic cash” became clear: the scalability issue. While the number of transactions, and consequently the volume exchanged, was increasing also thanks to Bitcoin’s gain of popularity, so were fees for transactions.
Figure 1. The average fee for a Bitcoin transaction during 2017. At its peak, the average commission for a transaction was 55 dollars (red dot).
Transaction fees are necessary to the mechanism of the Bitcoin network. Every time a user broadcasts a transaction to the network, in order for it to be included in the block the payment of a commission is needed. A block is the data structure where transactions are grouped after they have been “confirmed”. The average time for the creation of a block (where transactions will be stored) is 10 minutes, with a fixed size for every block. Given these two limitations, currently the Bitcoin network is able to process the maximum of a dozen transactions per second.
The issue was well known from the beginning among Bitcoin’s community, and it is at the center of an ideological and political “battle” between the participants and developers of the open-source project.
An ambitious project, developed by multiple parties including Lightning Labs, ACINQ and Elements Projects, Lightning is one of the most powerful possible solutions to Bitcoin’s scaling problem. Lightning Network is a proposed implementation of Hashed Timelock Contracts with bi-directional payment channels, which allow transactions to be routed securely across multiple peer-to-peer channels. Firstly envisaged in a whitepaper written by Joseph Poon and Thaddeus Dryja, Lightning promises the delivery of scalable, instant and commission-less Bitcoin transactions, attempting to solve the issues described above.
The underlying idea of Lightning Network originates from Payment Channels’ mechanism. The latter is a secure system of off-chain transactions, which are not included directly within the Blockchain, significantly reducing data to be recorded on it. It consists in the creation of a bi-directional channel between two users, who are able to transact between themselves instantly, freely and trustless. The channel between the users is opened with a funding transaction, which is included in the Blockchain just like an average Bitcoin transaction, thus requiring a mining fee. The same users also generate, sign and exchange a refund transaction that will allow the counterparties to recover their locked funds independently. Once the Channel described is opened, the users will be able to transact between themselves, inside the boundaries of their channel capacity (the amount locked) simply updating the refund transaction, each time substituting the previous one. No transactions occurring between the two users will end up on the Blockchain, thus not necessitating mining fees or confirmation time. Only one transaction will be broadcasted to the Blockchain: the final one, which will close the channel whenever one of the counterparties decides it. In this case, the user only needs to send the last refund transaction and wait for it to be mined, in order to regain control of his bitcoins. The protocol maintains the same trustless nature as Bitcoin, by implementing a penalty mechanism: if one of the counterparties (Bob) wish to spend an old refund transaction, thus withdrawing more bitcoins that are due to him, the damaged counterparty (the user on the other side of the channel) could spend the last valid refund transaction. The channel would be therefore closed, giving all the bitcoins to the damaged party. This mechanism disincentives the perpetration of fraud within Payment Channels.
Figure 2. Functioning of a Payment Channel
Even though Payment Channels are functioning properly, they are not able to solve Bitcoin’s scalability problem since users should create many channels between them in order to transact, locking too many bitcoins (and thus liquidity). An extension of Payment Channels is supposedly able to solve the scalability problem: Lightning Network, which allows to “extend” the Payment Channels thanks to cryptography, forming a “network” of channels. Lightning Network works through a ramified structure of Payment Channels. This means that it is not necessary to have an open channel with the user to whom a transaction is to be sent: it is only needed to “find a way” to reach the final user, passing through the different paths of channels.
In the case represented above, Alice wishes to send a transaction to Tim without having a direct channel with him. Alice is able to transact with Tim taking advantage of her channel with Bob, who owns a direct channel with Tim. For his “intermediary” job, Bob may ask a commission (in some cases it can be negative). After all, Alice will be able to send a transaction to Tim without including it in the Blockchain, instantaneously, trustless and almost freely thanks to Lightning Network. The transaction is sent trustless since the protocol is designed to not allow Bob to take Alice’s bitcoins and not pay Tim.
Figure 3. Lightning Network Paths
Lightning Network, by design, includes an algorithm that allows weighing all the hops (intermediaries), in order to minimize the total fee. For instance, in Figure 3 Alice could have paid Tim passing through Carol, but she has a hop commission (3) larger than Bob (1). It is worth noting that Alice could pass from Bob if he has enough bitcoins to actually pay Tim. If Bob does not have enough bitcoin in his channel, Alice’s wallet will detect it and find another path to pay Tim. This means that, the more bitcoins are locked in channels, the more traffic the latter can handle on Lightning Network, therefore being able to collect more fees.
Lightning Network therefore introduces several benefits. The most important and visible is a drastic decrease of payments’ commissions: currently, the commission per hop is around 1 satoshi, or less than 0.001 euros. In addition, transactions are instantaneous and users’ privacy potentially increases since the transactions are not recorded on a shared public ledger. By consequence, if Lightning Network will increase in adoption, there will be fewer transactions on the Bitcoin’s Blockchain, and thus fees could be lowered on-chain as well.
 A satoshi is the smallest Bitcoin’s unit. It equates to 0.00000001 BTC.
Along with the multiple benefits introduced by the off-chain solution offered by Lightning Network, there are several potential weaknesses in the network, both from routing, capacity and security perspectives. As mentioned above, in order to conduct a transaction via Lightning Network, a linked series of payment channels it is needed (where there is no possibility to have a direct Payment Channel with a specific user). Therefore, in order to make the payment happen, there is need to have a route. If Alice wants to pay Tim, she needs to know the entire ‘state’ of every channel of the entire network. This state needs to be updated ‘live’ as transaction occurs over the network in order to allow Alice to find a working ‘path’. With few thousands of nodes this can be managed by graph networking, but as soon as the network scales up to millions of nodes this will become a problem. Today there’s still no solution to the routing problem. When sending a transaction, every hop the transaction is passing from (meaning that the hop is routing the transaction) must have funds available in order to “manage” the transaction. If Alice is sending 1 BTC to Tim, passing through Carol, who acts as a hop, this means that Carol will need will need to have at least 1 BTC in her channel’s balance with Tim. It derives from it that, in order for Lightning Network to work, there is the need for channels to always have capacity, and thus bitcoins locked in channel.
This liquidity lock may not be attainable for a particular class of users like the merchants: here comes the idea of Payment Hubs. The latter could be represented by a big corporation, or financial institution. Institutions with a great number of customers and in possess of large liquidity to be locked, can open Lightning Network Channels with its customers/users acting as a single hop for transactions between them. Hubs can also create backbone channels between them, allowing them to connect all their global users in a few payment hops. Merchants are the mostly affected users of this problem as in order to receive Bitcoin payments they need to have open channels whit some counterparty that locks liquidity: if an ecommerce processes 10K€/day the operator needs an entity that is able to open at least a channel with him that is able to cover the expected amount that he’s going to receive. Here come the benefits of a Hub: this counterparty would open the channel to the merchant and apply the transaction fee on each payment the ecommerce receives. The revenue model of a Payment Hub enjoys several revenue streams: commissions from transactions, liquidity advance for merchants and added-value services, as paywall, Vending Machines and physical PoS, for instance.
Payment Hubs would solve also the routing problem (or at least allow to postpone it in the future) as the network in this case would move from a mesh (c) to a hub&spoke (b) where the routing problem it’s much easier to solve as it’s basically the same topology that Internet has today (as well as the global payment system of Banks and Financial Services).
Routing and capacity are not the only weaknesses in Lightning Network. By design indeed, in order for the system to work properly, nodes always need to be online. The penalty system described above, which is designed in order to avoid fraudulent activity within the network, only works if the defrauded party is able to notice the committed fraud in a specified amount of time. This means that, if the defrauded party is not able to be online and broadcast an on-chain transaction to recover all of the funds, the party will be definitely defrauded. A Payment Hub could be a solution to this issue as well: it could constantly watch the channels of their customer and kick in the penalty mechanism if some bad actor is trying to steal customers funds.
Figure 4. Network Tipologies
Another weakness which can be noticed in Lightning Network is still related to “online being”. In fact, in order to keep open channels within the Lightning Network, bitcoin funds need to stay online. By best practices, the safest way to hold bitcoins is to keep them in what is commonly called cold storage, in simple terms keeping them “offline”. With Lightning Network, this cannot happen, and thus there is the need for advanced cybersecurity solutions, which are able to protect funds from hackers. Such solutions will come also from the technological side but mostly on the internal processes definitions. Cybersecurity solutions are also needed in order to prevent bugs in software. If software has bugs, a channel’s counterparty may be able to take advantage of it, stealing funds from the channel.
Just like other “second layer” solutions, Lightning Network will be able to extend Bitcoin’s use cases. One of the most important and straightaway regards advertising, the most common business model on the Internet. Youtube may be taken as a straightforward example: with the current system, in order to watch a Youtube video, it is mandatory to watch advertising videos, which cost to the publisher an average of $0.20 (depending on several factors). A variable percentage of the sum ends up in the pocket of content creator and the rest covers up Youtube’s marginal costs. The system could be thought in a different way: instead of obliging a user to watch a video in order to earn revenues, people could be interested in paying the same amount of money directly to the content creator and to the platform in order to not watch the advertise. This concept is known as paywall: paying to enjoy contents directly. A test case of paywall on Lightning Network has already been implemented, namely Y’alls, developed by Alex Bosworth. Y’alls is basically a blogging platform, which implements micropayments. After having installed a Lightning Network wallet, each user can write or read articles: in order to read or write an article, the platform asks for a $0.01 payment in bitcoin, which gets processed using LN micropayments. Y’alls is one of the first real-world implementations of Lightning Network, which shows how the latter is potentially able to disrupt the current business model of most content creation websites, using micropayments for direct enjoyment of contents.
Digital advertising suffers too much from “middleman” which are paid good commissions, discouraging content creators to publish on centralized platforms. Of course, as mentioned before, sending micro-transactions (or small transactions), as would be one for watching a video, is completely undoable without using a solution like LN, given the current state of Bitcoin’s transaction fees. Sending a $0.01 in a Bitcoin transaction right now would be impossible, since transaction fees are not low enough. Even though opening Payment Channels with a service and thus getting a “prepaid” balance is already possible, the real change is offered by Lightning Network’s interoperability. The latter indeed may be able to solve the paywall problem: a user could have a unique Bitcoin LN wallet managed within his Internet Browser, paired with his mobile phone, and load it with enough bitcoins in order to enjoy its favorite services, both digitally and in physical stores. Each service could autonomously demand the user a micropayment, directly splitting the paycheck for content creator and the fee to run the platform service. Lightning Network could be able to implement the real first system of peer-to-peer micropayments.
By leveraging the concept of network routing, LN will benefit from the adoption network effect, behaving in the same way as phones did: the more people using them, the more useful the network become.
As mentioned above, Lightning Network was first envisioned in a research paper written in 2016. The public alpha release of Lightning Network was made on 10th of January 2017, while on 16th of November of the same year, first ever lightning cross-chain swap from Bitcoin to Litecoin occurred. On the 6th of December version 1.0 RC of the Lightning protocol specification along with a successful cross-implementation test on Bitcoin main net occurred. Elements Projects (Blockstream) also introduced c-lightning, a specification compliant Lightning Network implementation written in C and, along with it, Lightning Charge, a micropayment processing system for Lightning Network, which uses c-lightning. Finally, on 15th March 2018 Lightning Labs announced the Bitcoin mainnet beta release of their Lightning Network client implementation lnd 0.4, the biggest milestone in the Lightning Network’s development thus far. The last release indeed provides for many improvements, along with greater efficiency and security of the network.
Figure 5. A visual representation of Lightning Network main net. At the moment of writing, 12th April 2018, there are 1723 nodes, 5208 channels, and a total of 15 bitcoins locked, or the equivalent of 135.000 dollars.
Recently, Lightning Labs received $2.5 million in a seed-funding round to continue development of LN. Among the investors, there were important and big names belonging to the Bitcoin, blockchain and tech industries such as BitGo CTO Ben Davenport, Twitter CEO Jack Dorsey, PayPal ex-COO David Sacks, SpaceX and Tesla angel investor Bill Lee, Vlad Tenev (co-founder of Robinhood) and others. The Lightning Lab’s development team also includes very qualified programmers and engineers, along with other independent and skilled teams working on the implementation, such as French startup ACINQ that released the first Android mobile Lightning Network wallet called eclaire.
The use and development of Lightning Network is still restricted to a small circle of hobbyists and developers (even though there are already many LN nodes), for instance, a young developer named Jack Mallers has already released an early version of Zap, a user-friendly Lightning Network wallet for desktop.
Widespread adoption of Lightning Network is the driver where stakeholders need to put the most efforts. This is why many user-friendly initiatives (as for instance Y’alls, mentioned above) are arising, in order to approach a more widespread audience. Recently, Blockstream has introduced what the team called the Week of LApps, in which seven applications built on top of Lightning Network were promoted in 7 days to spread awareness on the subject. The apps were built using Lightning Charge, a micropayment processing system for LN that uses c-lightning implementation. The apps covered a variety of commerce use cases, hinting at the multiple possibilities that Lightning Network would be able to offer, moving towards full production release. The 7 presented LApps are:
Lightning Network is a complicated technology that could revolutionize Bitcoin payments, as mentioned above. Its success will depend on the public adoption and thus on the possibility to find user-friendly tools, which could make it available to anyone. A widespread adoption of Lightning Network may be able to make Bitcoin, more secure and reliable among cryptocurrencies, a true mean of payment, finally acting as “peer-to-peer electronic cash”.
FinTech Leader, PwC Italy
Tel: +39 02 667201
Senior Manager, PwC Italy
Tel: +39 02 66720567