Earlier this year, Joseph Poon and Thaddeus Dryja released the Lightning Network white paper. In it they theorize how a layer on top of the Bitcoin blockchain can allow for instant and cheap bitcoin transactions, while vastly improving its scalability.
As a result of the block-size limit debate, the Lightning Network has been getting a lot of attention lately. But, unfortunately, wild myths have started to dominate the discourse. Suddenly thrown in the middle of a long-lasting conflict of visions, Poon and Dryja's concept is hailed both as the great savior solving all of Bitcoin's problems – and as a source of deep corruption within Bitcoin's development community.
This article will not seek to explain how the Lightning Network is set to function on a technical level. Such explanations can be found
here
and
here
, and for those who really want to immerse themselves with all of the nitty-gritty details of how it all works,
here
.
Rather, this article addresses 11 common myths surrounding the Lightning Network, in hopes of putting these to bed for good.
Myth #1: Core developers are crippling Bitcoin to force users onto the Lightning Network.
Although Poon and Dryja, along with several others, are currently realizing their own Lightning Network-based startup, Blockstream has been the only company funding the development of the Lightning Network so far. Specifically, the Bitcoin business with a
$21 million seed round
under its belt empoyed Paul “Rusty” Russel to work on an implementation of the concept.
Meanwhile, some of Bitcoin’s most prominent developers -- such as Gregory Maxwell and Pieter Wuille -- are on Blockstream’s payroll, too. This has led some to believe that Blockstream is working nefariously. It’s been alleged that the company is blocking any increase of Bitcoin’s block-size limit, as this will drive up transaction fees, forcing bitcoiners to use the Lightning Network instead.
This logic, however, seems very farfetched at best.
First, it's not just Blockstream employees who prefer to keep blocks small. The “
decentralist
” side of the debate includes a diverse group of programmers and other bitcoiners, including Bitcoin Core lead developer
Wladimir van der Laan
,
Bitcoin Core developer
Peter Todd
,
digital currency veteran
Nick Szabo
,
former Bitcoin Foundation director
Jon Matonis
,
bitcointalk.org and r/bitcoin admin “
theymos
,”
and plenty of others.
Second, some of the most prominent Blockstream employees and Core developers opposing a block-size increase – most notably
Maxwell
and
Wuille
– were skeptical of raising this limit long before Blockstream was even founded, and long before the Lightning Network white paper was published. Both were, in fact, some of the first block-size conservatives, back when the controversy first arose early in 2013.
Third, even if transaction fees on the Bitcoin network do rise, that doesn't really “force” people onto the Lightning Network at all. It will always be possible to use the Bitcoin blockchain directly if one so wishes – it will just cost more. If anything, users might be
incentivized
to use the Lightning Network, which is categorically different from being
forced
to do so. And even that is debatable, as there are plenty of alternative solutions with which to transfer money.
But fourth, and most importantly, the case for smaller blocks is simply much more reasonable than the “force-bitcoiners-to-use-Lightning” argument would have you believe. The question of how to scale Bitcoin has been an issue since the early days, and almost all developers agree that oversized blocks pose a security risk. While it is debatable what block size is too big (and the decentralists might be off the mark on this one) it is hard to deny that the Lightning Network can solve real, existing problems in regard of scalability – not to mention cost and speed.
Myth #2: There is no conflict of interest for the Core developers employed by Blockstream.
On the other end of the spectrum, some developers employed by Blockstream and working on Bitcoin Core have claimed that their involvement in both projects are wholly separate and does not represent any sort of a conflict of interest.
This, however, is not true either, and claiming otherwise might be the result of a confusion of terminology.
According to Wikipedia:
“A conflict of interest (COI) is a situation in which a person or organization is involved in multiple interests, financial interest, or otherwise, one of which could possibly corrupt the motivation of the individual or organization.”
(Other sources cite similar definitions.)
In this context, the word “possibly” is key. The Core developers working for Blockstream do not actually
need
to be influenced by the company when they work on Bitcoin for there to be a conflict of interest. The simple fact that they potentially
could
be, is reason enough. Even if Maxwell, Wuille and others are all perfectly capable of separating their two occupations, and they work as honestly and properly as humanly possible for both Blockstream as well as Bitcoin Core, their involvement in both is still a conflict of interest.
It should be noted, however, that absent an independent and sustainable funding model for Bitcoin developers, there might
always
be conflicts of interest within the development community. Whether that poses a problem, and how big that problem is, is up for debate. But no one has presented a clear-cut and workable solution for this problem yet.
Myth #3: The Lightning Network will be controlled by Blockstream
It is sometimes suggested that Blockstream will effectively control the Lightning Network, and, as such, will be able to determine how people use it, and what for.
There is some truth to this argument. If Blockstream deploys a fully functioning Lightning Network, they will technically control the code base.
However, the Lightning Network is an open-source project. And, as opposed to Bitcoin itself, it's not even an open-source project that requires consensus among all Bitcoin users over the protocol rules. This means that anyone can fork the Lightning Network any time they want, potentially adjust the code in any way they want, and deploy their own version whenever they want. It might even be possible for users of different types of Lightning Networks to transact with each other, as long as there are nodes connecting the two.
Indeed, competing implementations of the Lightning Network, such as
Amiko Pay
,
are being worked on already, while Poon, Dryja and others are setting up a company to realize their own implementation. Moreover, two Lightning Network-type solutions, the
Thunder Network
and
Stroem
,
have been deployed already.
Myth #4: The Lightning Network requires large payment hubs that will control the network.
Some argue that the Lightning Network will impede some of Bitcoin's most valuable properties, such as decentralization and censorship resistance. According to this argument, the Lightning Network requires large hubs to route most of the payments through. These could then block certain transactions, such as donations to WikiLeaks or other political dissidents.
This argument is largely based on the assessment that the most efficient network configuration – the configuration that requires the least amount of hops from any node to any other node – is a hub-and-spoke model. As such, the Lightning Network might naturally evolve to resemble a hub-and-spoke model, too. Hubs in this network could very well be big Bitcoin entities that almost everyone uses in some way or another already, like exchanges, wallet services and payment processors.
Importantly however, and much like Bitcoin itself, anyone on the Lightning Network can open a payment channel with anyone else at any time. Therefore, if Lightning hubs do emerge, they cannot control the network. Even if all existing hubs refuse to open a channel with WikiLeaks, anyone else still can, hence routing around these hubs. In fact, WikiLeaks could opt to become a hub itself.
Myth #5: Lightning hubs will infringe on users’ privacy.
While it is simply impossible for potential hubs on the Lightning Network to control the flow of funds, a slightly more accurate criticism of the system is that these hubs might be able to keep track of payments on the network. Since most of the transactions will route through these hubs, they could observe the flow of funds, impeding on users' privacy.
This could be true. However, all transactions on the Bitcoin network are currently publicly available and traceable by anyone
already.
On the Lightning Network, on the other hand, many transactions will be seen only by the hub operators. As such, the Lightning Network by default offers more privacy than the Bitcoin network currently does, not less.
Moreover, recent
advancements
on the Lightning protocol suggest that it should be possible to route transactions on the Lightning Network in a similar way as messages over the Tor network are. This would entail that all nodes on the Lightning Network know only from which directly connected node a transaction came – and to which directly connected node it must be sent. But they would not know which node initiated the transaction, nor at which node it will end up. If this is worked out properly, the Lightning Network could offer far more privacy than the Bitcoin network currently does.
Myth #6: Blockstream will earn fees off of the Lightning Network.
It is sometimes argued that Blockstream is merely, or at least mainly, pushing the Lightning Network (and blocking an increase of the block-size limit) because it plans to earn fees by running a Lightning Network hub.
It's not unlikely that Lightning hubs will indeed charge a fee for their service as a middleman. And since anyone can set up a hub, it's possible that Blockstream might want to do so, too.
But since anyone can set up a hub and earn fees by doing so, it is unlikely that anyone will make a huge profit. In a free market, competition should keep prices competitive, minimizing profit for anyone involved.
In reality, there is very little reason to believe Blockstream aspires to be in the business of being a financial intermediary. So far, nothing indicates that they will want to, nor will they be particularly well positioned to be one.
Myth #7: Blockstream won't make any money off the Lightning Network.
Since Blockstream won't really be able to control the Lightning Network, nor seems likely to make a lot of money by charging fees as a Lightning hub, this begs the question why the company funds its development in the first place.
To answer that question, it should first be noted that Blockstream is by no means pouring huge amounts of capital into the Lightning Network. The company is paying one salary, that of Rusty Russell, and that's it. While we can probably assume that Rusty is doing well, the Lightning Network is by no means a multi-million dollar operation.
Still, that leaves the question why Blockstream is funding Lightning Network development at all.
The most likely answer is that Blockstream is not completely sure either. As far as an explanation from the company goes, it believes that its in-house expertise will somehow be worth money eventually. In a world where millions or even billions use the Lightning Network, Blockstream assumes a profit can be made somehow, for instance through support, training and consulting services.
A comparison has been made to Red Hat. Red Hat, an American multinational software company, has a similar business model for other open-source projects, most notably the Linux operating system. The company provides all sorts of Linux-related services to a host of different clients all across the world. And with an annual revenue of more than $1 billion, Red Hat has been doing quite well indeed – probably much better than any Lightning hub ever will.
Myth #8: The Lightning Network requires a controversial hard fork of the Bitcoin network.
Another argument against the Lightning Network is that it's far from certain that it can be implemented. Much like a block-size limit increase, it is said that enabling the Lightning Network will require controversial changes to the Bitcoin protocol, and perhaps even a hard fork.
The Bitcoin network will indeed require several updates in order to support the Lightning Network. These are, most notably, a solution to the malleability issue (perhaps
BIP 62
)
and the option to lock transactions until some future point in time
(BIP 65
).
Neither of these adjustments, however, require a hard fork. Instead, they can be soft forked into the protocol, and none of these soft forks seem to be controversial on a technical level.
(Of course, similar changes can be implemented through a hard fork, too, if that were to be preferred. But it would not be necessary.)
Myth #9: Because of the Lightning Network, the block-size limit will not need to be raised.
The Lightning Network is set to enable a virtually unlimited amount of transactions between two connected users, while only recording two transactions on the actual Bitcoin blockchain. As such, the Lightning Network is sometimes hailed – either implicitly or explicitly – as the savior of Bitcoin that will solve all scalability issues.
While the Lightning Network could, indeed, potentially help solve the scaling problem to a large extent, it is quite an exaggeration to claim that no further block-size increase will be needed at all. If Bitcoin does grow to its full potential, and the Lightning Network is used by billions around the globe on a daily basis, these users will still need to transact on the Bitcoin blockchain in order to open and close channels once in a while. If that happens, it’s safe to assume that 1 megabyte blocks will be too limiting.
In fact, Poon and Dryja acknowledge that the block-size limit would need to be raised in their white paper, estimating:
“If we presume that a decentralized payment network exists and one person will make 3 blockchain transactions per year on average, Bitcoin will be able to support over 35 million users with 1MB blocks in ideal circumstances (assuming 2000 transactions per MB). This is quite limited, and an increase of the block size may be necessary to support everyone in the world using Bitcoin.... While it may appear as though this system will mitigate the block size increases in the short term, if it achieves global scale, it will necessitate a block size increase in the long term.”
It should also be noted that the Lightning Network is not merely intended as a solution for scalability. It could also securely enable instant confirmations for the first time, and make microtransactions worth fractions of a cent economically feasible again. In fact, if these properties draw in a lot of new Bitcoin users, deployment of the Lightning Network might actually pose a challenge for Bitcoin’s scalability issue on the shorter term.
Myth #10: The Lightning Network is an easy fix.
While debating the block-size issue, some on the decentralist side contend that the Lightning Network will simply solve most of Bitcoin's scalability problems. This sometimes makes the solution sound like an easy fix. It is not.
For one, the Lightning protocol itself is still a work in progress. Rusty Russell, Poon, Dryja and others are doing their best to realize the project(s), but this is a long and slow process. Even the concept itself is not set in stone yet, and several problems still need solving. As such, it’s not quite certain the the Lightning Network will indeed work as promised.
Furthermore, and as stated above, the Bitcoin protocol itself will need improvements for the Lightning Network to be deployed securely. Some of the required fixes, moreover, are not that easy to implement, and, much like the Lightning Network itself, are still a work in progress. As such, they might take quite some time to deploy – if they are ever deployed at all.
Lastly, wallet software will need to adjust as well. The most likely outcome here would be that individual wallets – Bitcoin Core, Bitcoin XT, Electrum, mobile wallets, etc. – will include some kind of add-on. Users would then have the option to make a blockchain transaction, or use the Lightning Network instead. But like much of the rest of the Lightning Network, specifics of how this will work or what it would look like exactly are not yet fully flushed out.
Myth #11: The Lightning Network is urgently needed.
This 11th “myth” is more of a controversy than a myth.
It should first be noted that it is hard to say with certainty how urgently instant and (dirt) cheap transactions are needed. These properties have not really existed on the Bitcoin network so far, making it hard to asses how much demand there will be for these properties.
It is more commonly assumed that the Lightning Network is urgently needed to address scalability issues. The fact that the Lightning Network is far from ready is one reason some progressives have urged an increase in the block-size limit instead. If blocks fill up, they argue, fees might rise to undesirable levels, transactions will be too slow to confirm (or not confirm at all), and Bitcoin could even become overloaded. With no alternatives such as the Lightning Network, the outcome would be bad – perhaps even devastating.
As stated above, it is definitely true that the Lightning Network is far from ready. Luckily, however, blocks are not yet filling up either, at least not in such a way that it causes great trouble. Even Bitcoin XT developers Mike Hearn and Gavin Andresen – the two most prominent advocates of bigger blocks – acknowledge that it will probably take another year before this starts to happen. (Others believe it will take longer.) That means the Lightning Network probably has at least another year to deploy and gain traction.
Whether that is enough time is debatable. In one of his blog posts, Hearn
argues
that there are no credible technical proposals that could gain widespread adoption within one year, including the Lightning Network. Others, however, have been a bit more optimistic. While a year is not an awful lot of time to deploy something like the Lightning Network on a large scale, Bitcoin moves fast, and it’s not impossible either.
But more importantly, many on the decentralist side of the debate
argue
that full blocks wouldn’t be that big of a problem in the first place. Fees may rise a bit, and not all transactions would confirm within the first available block, but that would be fine. If this is true, it might take
years
before the Lightning Network is really, urgently needed for scalability reasons.
Thanks to Lightning Network white paper co-author Thaddeus Dryja and Blockstream’s Lightning Network engineer Rusty Russell for providing feedback to an earlier draft of this article.