Why the Lightning Network is not a "Scaling Solution"

It’s honestly a little bizarre to see people still pushing the idea that the Lightning Network is a “scaling solution” for Bitcoin. It seems to me that the key observation in understanding why this is not the case is the recognition that the Lightning Network is a necessarily-imperfect money substitute for on-chain transactions, and moreover, that it becomes an even more imperfect substitute the more the blockchain it is operating on top of is constrained.

The Lightning Network Necessarily Defines a More Limited Payment Possibilities Graph

With on-chain transactions, the graph of possible payments is essentially a complete graph. Anyone who holds bitcoin can pay anyone else any amount up to all of the money the payer holds. And the possible recipients in this case don’t even need to be already “in the network.” Anyone who can generate and provide a valid payment address can receive payment.

In contrast, with the Lightning Network, anyone who is connected to the Lightning Network can pay anyone else who is also connected to the Lightning Network, and to whom a route exists and can be found, an amount that is limited by the hop in the route having the smallest available liquidity in the required direction. (If multiple routes exist and can be found, and don’t share the same limiting hop, the maximum possible payment can be increased accordingly, but the same general limiting principle applies.)

The Lightning Network Is Necessarily Less Secure - Part 1

The security model of an on-chain transaction is based on the fact that double spending a confirmed transaction “quickly becomes computationally impractical for an attacker” if a majority of the hash rate is honest. Thus, confirmed payments grow more secure over time—and very quickly become “irreversible” for practical purposes—as additional confirmations are received. Protecting funds received via such payments does not require any active monitoring or continued connection to the network.

In contrast, the security model of the Lightning Network requires eternal vigilance (that this vigilance can be outsourced to proposed “watch towers” does not change this problem, but merely moves it). If a channel partner broadcasts an old channel state in an attempt to steal funds from you, you must detect the attempted theft and act to block it in a timely manner by getting your own “breach remedy transaction” added to the blockchain within a defined “dispute period.” That is a fundamentally different (and weaker) security model. It depends on a user’s supposed ability to, when needed, get an on-chain transaction confirmed on the blockchain in a timely manner, which is, of course, exactly what’s compromised by an artificial constraint on on-chain capacity. This is the first way in which the LN becomes a more imperfect substitute the more the base blockchain is constrained, and is what I refer to as the LN’s “fractional-teller banking” problem.

It’s also worth noting that an individual’s inadvertent broadcasting of an out-of-date channel state (e.g., due to a faulty node backup) can result in their losing all of their funds in the channel. This represents a second risk vector that is not present with on-chain payments. A closely-related problem is the fact that funds in a LN wallet, unlike funds in a regular wallet, cannot be backed up statically (e.g., with a 12-word seed). Instead, a new backup must be created and securely stored every time any of your "channel state" information changes. This occurs every time you send a LN payment, every time you receive a LN payment, and every time someone else's payment is routed through one of your channels.

The Lightning Network Is Necessarily Less Secure - Part 2

If a channel partner becomes uncooperative, you will be forced to close that channel via a unilateral close, in which case your funds will be effectively frozen until the end of the dispute period. That’s a form of counterparty risk that simply does not exist with funds that are held on-chain.

The Lightning Network Has a Natural Tendency to Centralize That is Exacerbated by a Constrained Base Blockchain

It’s important to keep in mind that the Lightning Network is not a piece of software. It’s a network that grows and changes as people open channels, route payments through those channels (thereby changing their liquidity states), and close channels. There is of course a cost to opening a channel. This cost includes the cost of the requisite on-chain transaction as well as an opportunity cost, i.e., funds committed to one channel can’t simultaneously be used to fund another channel with someone else. There is also a cost associated with the risk that a particular channel will not prove useful, leading to its closure in the future and thereby necessitating a second on-chain transaction fee. On the other hand, the primary benefit of opening a channel is the possible future payments it will allow you to send and receive. The greatest benefit in these terms is provided by a well-funded (on both sides) channel connection to a channel partner who has a huge number of other well-funded channel connections (i.e., a “hub”). Of course, becoming such a “hub” will require massive capitalization to fund all of these channels. There’s also a positive feedback loop / network effect aspect to hub formation. As an emerging hub grows more connected, it becomes an even more desirable channel partner, encouraging even more connections, making it an even more desirable channel partner, etc., etc. A constrained base blockchain amplifies this naturally-centralizing dynamic by greatly increasing the cost of opening and closing channels. If, for example, it costs $50 every time someone goes to open (or close) a channel, individuals will have a strong incentive to be very reluctant to open channels with any nodes other than those who can provide the most benefit (i.e., massively-capitalized, massively-connected hubs). It’s interesting to consider that while the naturally-emergent topology of the Lightning Network is one of massive centralization, the naturally-emergent topology of the Bitcoin mining network is the exact opposite, i.e., a near-complete graph with all miners connected to all or nearly-all others. It’s thus incredibly ironic that those attempting to move us toward the former and away from the latter have attempted to justify their actions with appeals to protecting “decentralization.”

If the Lightning Network Were a Perfect Substitute, That Would Paradoxically Represent a Very Dangerous Situation

For at the least the reasons outlined above, the Lightning Network is not a perfect substitute for the blockchain. But the counterfactual is worth considering. If it were somehow the case that there were no downside to making a particular payment via the Lightning Network, that would paradoxically represent a very dangerous state of affairs. As the block subsidy is phased out, Bitcoin’s security will increasingly need to be paid for via transaction fees. If everyone could get all of the benefit of an on-blockchain transaction without actually using the blockchain and paying those transaction fees (or rather, if they could get all of those benefits by using the blockchain once to open a LN channel they kept open forever), that would create a tragedy of the commons.

Conclusion

Contrary to the claims of many of its proponents, the Lightning Network does not represent “trustless scaling.” At best, it promises a kind of “reduced-trust banking.” While the LN is obviously not traditional, fully-custodial banking (you put the coins in the bank’s vault and only they hold the key), more critically, neither is it the “be your own bank” of Bitcoin proper (the coins are in your own vault and only you hold the key). It’s essentially a hybrid model--which we might call “semi-custodial banking”--in which you and your “bank” (i.e., hub) both lend funds to an entity (the channel) over which control is shared. It’s an interesting idea, and one that might even prove to be useful one day. But it simply cannot eliminate the need for actual (i.e., on-chain) scaling. There will always be a natural balance between money proper (in Bitcoin’s case, on-chain transactions) and various money substitutes. The problem with an arbitrary limit on the capacity of the former is that it distorts this balance.

submitted by /u/Capt_Roger_Murdock
[link] [comments]

from Bitcoin - The Internet of Money https://ift.tt/2XmA7xn