As the lightning network implementation moves to the mainnet, the implementation is far from complete. There are several major requirements yet to be built in order to reach a fully functional state. These included but are not limited to, watchtowers, splicing, submarine swaps for channel reloads and Atomic Multipath Payments (AMP). While these will take time and could be difficult to develop, these are all mechanisms that, while important, are not critical. This article will be discussing routing, which I would consider to be the most critical issue facing the network due to its potential limitations on scaling, which was the initial incentive for the secondary network creation initially.

Bitcoin (BTC) is relying on success of lightning

Currently the fate of the underlying network protocol relies on the successful implementation and deployment of the lightning network to allow for scaling of Bitcoin transactions off-chain. A failure to deploy the lightning network in the near term could lead to latter-day generations of blockchain root protocols to overpower the existing network effect of BTC through enhanced functionality and become more attractive to new adopters.

This is due to several factors:

1. Smart contract support on the BTC chain relies on a successful implementation of lightning.

2. Tokenization of financial assets on the BTC chain relies on a successful implementation of lightning.

3. Sidechain development (with the notable exception of liquid) has been side lined until lightning is complete.

4. Bitcoin developers who favoured scaling through ‘big block’ have migrated to a new fork of the Bitcoin chain called “BCH” and likely will no longer developing on the BTC chain, even if the current block size restriction of 1MB is lifted.

New adoption of smart contracts and tokenization by existing non-crypto businesses on a global platform such as Ethereum could lead to snowballing success as greater credibility and pressure on the existing infrastructure to adopt whatever crypto-currency takes the lead.

Current status of routing on the Lightning network

The current implementation of the lightning network has approximately 2,000 nodes with 6,500 channels and a total capacity of 20 BTC (~$150,000) as of May 29, 2018.

This implementation relies on a “sending node” basis. That is, the sending node builds their own network map for routing. This network is constructed through the entire network, broadcasting their announcements of channels and channel balances. The sending node would then define their route based on their network map before making the payments. Now, that is not to say that the sending node needs to know the entire network but this is the rough equivalent of a home computer or mobile device trying to build its own map of the Internet. This is not sustainable for two main reasons:

1. It’s noisy on the network leading to significant control traffic as every transaction changes the state of every route node along that transaction’s route. This leads to ever increasing announcements.

2. The sender node network map needs to continuously be updated as channel states, balances and fees changes. This can lead to collusions due to propagation time causing failed payments. Payments on these damaged routes cannot be rerouted. All failed payments need to be sent back to the sending node due to the onion routing approach and any nodes going offline holding the payment funds can lock funds for 24 hours.

The current approach is not sustainable for a worldwide network. Rusty Russell’s calculation of a 10k node network would take 34.4M in storage and 1.123 GB in traffic daily scaling up to 3.44G and 112.3GB respectively for a node once the network reaches 1 million nodes. [1] Given that one of the goals is to be able to run nodes on existing low powered hardware such as a Raspberry Pi, these hardware requirements are not scalable.

The lightning white paper [2] states, “Building a routing table will become necessary for large operators (e.g. BGP, Cjdns) and “Similar to how packets still reach their destination on your home network connection, not all participants need to have a full routing table”.

This means that the current approach is not intended to be the final state of routing and this was further expanded in a recent blog post by Lightning Labs. [3]

The user channels will feed balances into Gateway routing nodes, which are connected to hyper connected centralize bridge routing node similar to how the Internet backbone operates.

However, the whitepaper lacks a detailed implementation outline for how this routing will occur. This is particularly worrying as the Border Gateway Protocol (“BGP”), referred in the whitepaper, used within the backbone ultimately functions as an easily exploitable zone of trust [4] . Due to the adversarial nature of the lightning network as a monetary network, a similar zone of trust can’t be established even if it was desired. This difficulty can’t be understated as the network is envisioned to be a 10 to 15 hop network.

For example, because there is no common graph or authority, any node can lie about open channels or lie about a parallel path. This would tie up funds or open those funds to attack (such as trap funds with a single high fee exit, etc).

While there is no official routing node based solution. However, there appears to be progress on a hybrid approach, the channel proof and a hybrid routing proposal called “flare” [5] .

The flare proposal

The proposal is the deepest drive on finding a routing node based routing solution and was longer than the lightning network whitepaper itself, strictly on routing.

The proposal would also allow the routing nodes to select preferred peers into global beacons and local beacons and utilize these as defined routes that can be expected to be maintained online constantly and then route the payments as quickly as possible through a network of landmarks nodes instead of directly and cheaply as possible through routing nodes. The Flare proposal is the most similar to cjdns while prioritizing different factors and considerations to determine the node scores.

However, this proposal isn’t a silver bullet. A test by the ACINQ team coded a payment routing algorithm based on the proposal and tested it with 2,500 AWS nodes. The algorithm was able to find a payment route in about .5 seconds with a probability of 80%. [6]

While this was only a feasibility test, this is disappointingly low level of performance in a simulation environment and highlights the difficulty in maintaining a mesh network where routing is done by routing nodes instead of the sending nodes. In addition, this test was conducted in 2016 and has been the only feasibility test conducted on the flare proposal.

A failure to implement the flare proposal or an undiscovered alternative would likely doom the current lightning network implementation due to the scaling limitations and the community demoralization that would occur once that scaling limit of sender node routing maps has been reached and lightning network experiences widespread intermittent failures.

Proposed alternatives

If the current lightning protocol is short-lived due to the network inability to transition to a routing node system of routing, that doesn’t mean that there is no future for lightning network. I propose the following potential ideas for further discussion and consideration:

1. Remove the ability for routing nodes to open and close channels whenever they want and instead synchronize a common channel state change event every x blocks. This would greatly reduce the unpredictability of the network and allow for the network to stabilize major routing tables. While this would increase on-boarding time for new network participants, it would be in exchange for enhanced network stability through long-lived channel lists.

2. Create equal double-ended channel funding for routing nodes. This could be done through a 2 of 2 multisig address which pays out the changed state balances to the two partners once closed. This would allow nodes to broadcast total channel balance capacity instead of tracking each side of the channel and prevent propagation time collusions where a transaction could steal the required liquidity for another transaction.

3. Create main hub of bridge nodes that require every routing node to connect directly to every other known routing node. This would allow for every node propagates channel state to other routing nodes in a single hop even if it is not optimized. This could also transform the graph from a mesh to a near complete graph for the key routing nodes. However, this will end the philosophy of using a network of the low-power devices such as Raspberry Pis to power the network.

4. Implement gateway and bridge routing node minimum liquidity requirements to remove volunteer or altruistic nodes whose uptimes will not be as reliable or can’t afford to open as many channels as possible to other routing nodes.

I can expand on these potential solutions or the other issues identified in the introduction. Did I get something wrong or miss anything? Please let me know in the comments.

[1] Russel, R. (2016, July). Lightning Routing: Rough background. Retrieved from https://medium.com/@rusty_lightning/lightning-routing-rough-background-dbac930abbad

[2] Poon, J., & Dryja, T. (2016). The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments.

[3] Vu, B. (2018, May). Exploring Lightning Network Routing. Retrieved from https://blog.lightning.engineering/posts/2018/05/30/routing.html

[4] Pilosov, A., & Kapela, T. (2008, August). Stealing The Internet. Presented at Defcon 16, Las Vegas, NV.

[5] Prihodko, P., Zhigulin, S., Sahno, M., Ostrovskiy, A., & Osuntokun, O. (2016) Flare: An Approach to Routing in Lightning Network.