Lightning network: will it save Bitcoin? Or break it?

Lightning network has been heralded as the way to scale Bitcoin into the future, but as it is starting to become apparent that two very separate camps with differing opinions on how to scale Bitcoin are starting to draw lines in the sand, it’s worth taking a pragmatic look at this technology, seeing as it seems to be shaping up that once adopted, it will be very difficult to back out¹

First off, I want to say that Lightning as a concept is pretty interesting.  I think that it will have many uses in the world of Bitcoin.  Yes, I have read the white paper (both long and short version) and I believe I have pretty good understanding of how it works.  A disclaimer, as most of the development is happening behind closed doors via BifFury, it’s hard to comment on any of the new yet unreleased progress, such as developments on the routing algorithm.

Let’s examine the pros and cons of the Lightning overlay network.

  1. Unlimited txn/s
  2. Secure from double spends
  3. Requires Bitcoin to use

The first and biggest feature about the LN overlay network is that it allows for an arbitrary number of txns between parties to be transmitted without touching the Bitcoin blockchain.  This means, theoretically speaking, if I opened a channel with you, and we each put in 10 BTC, then any number of payments between us that would result in 20BTC for me and 0BTC for you or vice-versa can be done completely off-chain. Moreover, these 2-way channels can be strung together to bridge payments between people who don’t have channels open directly between them.  This is great for scaling point to point transactions between parties that you normally always pay (your utility company, the Starbucks at your workplace).  Where this becomes unclear is how many connections between people and employers would be needed in order for money from any person to reach others in a circular fashion, without the use of payment hubs. A payment hub would simply open deposit channels with the client depositing 100% of the BTC (hub contributes nothing) and when it comes time that the client would want to withdraw a new channel for withdraw would be opened up with the hub depositing 100% of the channel funds perhaps set to the maximum withdraw amount per month. Sounds familiar? It should, as it mirrors how your bank operates today.

Secondly, Lightning solves the double spend problem by way of cleverly exchanging cryptographically signed commitments to bitcoins.  Double spends are prevented by always providing the counterparty in the channel the ability to revoke the whole channel and take all its funds if any attempt is made to cheat by publishing an invalid state of the channel (such as one prior to a payment that has already been made).

Thirdly, Lightning requires some token of value to ‘lock up’ in the channel so that the channels are worth something.  Currently it is being built on Bitcoin, which means that it will as a secondary effect require more people to purchase BTC to be used in channels.  This has the potential to grow the user base of Bitcoin somewhat.  Though developers of LN also mention that it would just as easily work over Ethereum or any other crypto token, and have not ruled out implementing it for those blockchains in the future. Perhaps even use LN as a bridge between blockchains as a sort of decentralized exchange or pegging mechanism. (a channel that has BTC on one end and ETH on the other is theoretically possible)

Now for negative tradeoffs:

  1. Unlimited txns scales txns, not users; only works for payments
  2. Inversed security model compared to Bitcoin
  3. Locks and encumbers Bitcoins into channels, affecting fungibility
  4. Encourages centralization in payment hubs

So first off, the misconception is that unlimited txn scaling will solve all the problems. When in fact it doesn’t.  Because every open/close of an LN channel means a (slightly beefier) txn on the Bitcoin blockchain, an interesting effect of this is that the on-chain scaling problem becomes an 2nd order effect, the bottleneck shifts from a limit on the transactions that can be processed on chain to a bottleneck on how many payment channels can be opened or closed at any given time.  This creates an interesting case that if Lightning txns scales to encompass the entire world worth of daily transactions (the often touted “VISA” standard) then it would be a problem if for any reason a massive number of payment channels would need to be closed all at once.  This situation is not unlike the ‘fire drill’ effect that bank runs have in the real world, when a panic rush to withdraw money from bank accounts which precipitates a liquidity crisis, which in turn exacerbates the panic, and a vicious cycle is created until all money flees the bank and the economy collapses.  Basing an infinitely scalable (in the txn dimension) system on top of a hopelessly limited one that controls the on/off ramp onto the system is dangerous.  Additionally scaling in this dimension only helps payments.  Lightning won’t help all the other uses of Bitcoin blockchain, such as 2nd layer colored coin overlay networks that use OP_RETURN, or OP_MULTISIG operations to embed metadata into the Bitcoin blockchain.

Secondly, the security model in Lightning is the inverse of the one used in Bitcoin.  In Bitcoin, you don’t have my money until I send it to you.  There is nothing you can do short of stealing my private keys to take my money from me.  Conversely in Lightning, the security of the payment channels requires constant monitoring to ensure that your counterparty is not stealing money from you by publishing an old channel state to the network.  This means you either have to have a constant node running software (yet to be developed) to monitor the blockchain for invalid channel states (at which point you would publish a force channel close, and wait the requisite hold time before your funds are released) or you can pay a service to do this for you.  This service may be provided by a new service provider called channel insurance companies or payment hubs for a fee.  If you choose not to use channel insurance and decide to do it yourself, then you may be vulnerable to eclipsing attacks if you are not careful, where malicious nodes will try to isolate and hide (or eclipse) your view of the blockchain, such that you don’t notice the attempt to steal your channel funds.  Basically, the security model of Bitcoin changes to one where you have to actively guard against theft, instead of the current one where you have passive protection from theft (assuming you manage your own private keys).

Thirdly, bitcoin in a Lightning channel cannot be readily used outside Lightning.  While proponents will say that this is not a problem if enough people use Lightning such that you can pay everyone in the network within it, for a large part of the growth phase of the network this will not be the case and there will be a price premium for bitcoins which are *not* encumbered in Lightning channels.  This is bad for fungibility of bitcoins as there will be a separate market for Lightning bitcoins vs ones which are *free*.  At the very _least_ the price difference is the time value of the lock duration that payment channels must wait in the case of an uncooperative channel close which is 2 weeks.  If you consider it, this means Lightning network is nothing more than a pseudo-decentralized² bank account. Unlike real world bank accounts, you don’t need to worry about the bank holding your money going bankrupt³, but you still have your money effectively encumbered in their system and it may be a hassle to move it out.  Worse still, if everyone creates channels poorly by allocating too much or too little, then this will create more required on-chain txns on the base bitcoin layer which may not be able to handle it.

Fourthly, the economics of payment channels and efficient routing between n-to-m endpoints means that the most efficient (in terms of minimizing the number of hops) configuration of the network would be large payment hubs that would have open channels to everyone else (and to each other).  That way if Alice wanted to send money to Ben, then the routing would be Alice->[hub 0..n]->Ben.  In the case where Alice and Ben are friends there will likely be no hub, but in the case where Ben is a stranger half-way around the world then there would be likely a number of hubs that would route the payment through. The system would tend to minimize the number of hubs as it is more efficient, limited only by the amount of free capital (in BTC) that the hub would require in order to maintain the payment channels.  This means whomever has more money available will be able to open and maintain more payment channels, becoming a payment hub.  Who would have the most free capital available? Banks.  Existing banks would be the best positioned to run payment hubs.  The only difference between this and the current system is that you won’t require a license to start a payment hub (aka bank).  Though, I would worry that if enough unregulated payment hubs were to emerge then the governments of the world may make running them illegal, causing a large exodus of BTC from them and a deluge of channel closes.  Exactly the kind of peak txn flow that Bitcoin won’t be able to sustain if we don’t simultaneously scale the base network.

Lightning is a definitely the way to scale Bitcoin to VISA levels of txns in the long run.  The idea of passing around cryptographically signed commitments to BTC is a brilliant one, but it isn’t an original idea.  We have had a ‘Lightning’ network for more than 600 years now, it’s called a bank account, where we essentially just shuffle around IOUs and commitments to value. The only thing Lightning brings is cryptographic signatures to prevent theft and the ability to make the system more decentralized so that you don’t require a license to operate as a Hawaladar.  For a system that is often touted as digital gold it is surprising that many supporters do not recognize what any real gold bug would immediately point out upon hearing of a 2nd layer IOU network.  Which is of course, that this was the exact same way the world’s last system of sound money was systematically eroded and dismantled.  Transacting in gold pieces was too costly, so the system of paper gold certificates was created to replace it.  We all know where that ended up.

 

¹ Segregated Witness, a necessary change that Lightning requires, if activated and used cannot be reverted without potential loss of funds.

² “Pseudo” because I believe market forces will cause centralized payment hubs to develop

³ In reality nobody really worries about their bank account going bankrupt in a central banking system anymore with government assurances like FDIC. And in the case where an apocalyptic event makes it such that government will try to claw back deposits, then all bets are off and they may very well criminalize LN payment hubs.

11 thoughts on “Lightning network: will it save Bitcoin? Or break it?

  1. Hi! Great and insightful piece! Some minor factual corrections:
    1. There are multiple open implementations, and at least one attempt at a spec: https://github.com/rustyrussell/lightning-rfc Expect more formalization after Scaling Bitcoin Milan.
    2. Consensus so far has been that the protocol only covers small transactions, less than 0.042 btc. This is great for bootstrapping and still covers interesting cases.
    3. You can directly pay out of a lightning channel to a normal Bitcoin address with no delay. That should limit the differential you talk about.

    Centralisation is the chief concern, but larger nodes will have larger hot wallet risk. With no barriers to entry, I hope (for privacy reasons and health of the network) there will always be plenty of nodes willing to offer service.

    • Great comments, thanks Rusty.

      One point I would add is that the large hot wallet risk of payment hubs is vastly mitigated by opening 2 Uni-directional channels instead of matching amount bidirectional ones. That way the payment hub doesn’t need to lock up too much of its funds. (Opening withdraw channels only when needed and only on small daily withdraw limit sizes) They would naturally tend to try and optimize this (reduce the amount of hub funds that need to be encumbered to maintain the channels) so hubs will end up being the ones who can afford to pay the higher fees on the underlying Bitcoin blockchain to do more channel open/close operations. This leads me to believe hubs will have a naturally centralizing force.

      Also due to the distributed nature of channels they never are exposed to the same risk as an exchange with hot wallets. They can only lose funds to its clients in the amount that they have locked up with them.

  2. Sorry, but if we each put 10 BTC and then it results in 20BTC for me and -10BTC for you, algebra shows that somebody stole 10BTC. Moreover, I don’t think that any Lighting Network implementation allows for negative balances. You might wants to fix that paragraph.

  3. Pingback: Segwit tackles short term Bitcoin blocksize problems, and helps long term scaling solution Coin Academy

  4. Pingback: Segwit tackles short term Bitcoin blocksize problems, and helps long term scaling solution | Bani-Digitali.ro

  5. Pingback: ScalingBitcoin Milan, not so much about Scaling Bitcoin. | Wall Street Technologist

  6. Interesting post! One passage is not very clear though. What do you exactly refer to when you write: “the large hot wallet risk of payment hubs is vastly mitigated by opening 2 Uni-directional channels instead of matching amount bidirectional ones.” ?

    • for instance, if you are a large hub, with lots of capital but with many many connections to individual users and businesses, this means that everyone would want to route payments through you because less hops means less fees. If you had to open up channels by putting matching amounts of your money in with every other user, then this would be a limiting factor. (as you would have to have 100% reserve amounts for all your channels) and inefficient as a whole as the network would require 2 dollars locked up in order to send every 1 dollar.

      Instead you only open up channels where the depositor puts in funds. The hub then credits their account balance with that amount. When they are paid money by other parties, the hub just increases the balance by that amount, they don’t actually move the money through a LN channel. This can be done as long as the payee is also another client of the same hub. When a client wants to withdraw, only then do they open up a withdraw LN channel to the client which they can pull money back out. This way the hub only locks up their own funds only when clients withdraw, which most of the time, will be minimal as long as people continue to use the same hub.

      When a hub grows large enough, it will start opening bidirectional channels to other large hubs. If they trust each other enough, then they start crediting each other in IOUs instead of real payment channels. You can end up with a fractional banking system existing as long as hubs trust each other to make good on their promises to pay each other back, and no crisis of confidence happens that causes a bank run.

Leave a Reply

Your email address will not be published. Required fields are marked *