Probing Channel Balances in the Lightning Network

Abstract

Payment channel networks (PCN) have been introduced to solve scalability problem of permissionless blockchains such as Bitcoin. The Lightning Network (LN), launched in 2018, is the most prominent PCN built on top of Bitcoin. As of March 2020, LN consists of over 11 thousand nodes and 36 thousand channels, collectively holding nearly 900 bitcoins (7.8M USD).A payment channel allows two parties to lock funds in a multisignature address and then modify the distribution of funds in nearly instant transactions, without confirming them in the blockchain. As LN transactions are not broadcast and not publicly stored, LN has been seen not only as scalability but also as privacy solution. The protocol guarantees that only the latest channel state can be confirmed on channel closure. LN also supports multi-hop payments, where the balances of multiple channels along a path are moved. The atomicity of this process is guaranteed by hash time-locked contracts (HTLC). LN nodes gossip about channels available for routing and their total capacities. To issue a (multi-hop) payment, the sender creates a route based on its local knowledge of the graph. As local channel balances are not public, payments often fail due to insufficient balance at an intermediary hop. In that case, the payment is attempted along multiple routes until it succeeds. This constitutes a privacy-efficiency tradeoff: hidden balances improve privacy but hinder routing efficiency.In this work, we show that an attacker can easily discover channel balances using probing. This takes under a minute per channel and requires moderate capital commitment and no expenditures (the attacker's funds are only temporarily locked). We describe the algorithm and test our proofof-concept implementation on Bitcoin's testnet. We argue that LN's balance between privacy and routing efficiency is suboptimal: channel balances are neither well protected nor utilized.We outline two ways for LN to evolve in respect to this issue. To emphasize privacy, we propose a modification of error handling that hides details of the erring channel from the sending node. This would break our probing technique but make routing failures more common, as the sender would not know which channel from the attempted route has failed. To improve efficiency, we propose a new API call that would let the sender query balances of channels that it is not a party of. We argue that combining these approaches can help LN take the best of both worlds: hide private data when feasible, and utilize public data for higher routing efficiency.

What is a Blockchain? A Definition to Clarify the Role of the Blockchain in the Internet of Things

“…It also opens the way to thrilling research challenges such as bringing network science and expertise into the domain of transporting and routing payments within Payment Networks, as explored in [175]. Major open problems include addressing the depletion of channel capacity, especially for the most loaded nodes in the center of the network, developing enhanced centrality-aware routing strategies [176,177], and rebalancing techniques [178][179][180].…”

Optimally Reliable & Cheap Payment Flows on the Lightning Network

“…Despite the fact that the most likely flow was used, some of the onions will not reach the target in most cases. So the sending node gathers information from the error codes of failed attempts as previously described in [11] as well as information from the paths that have not returned an error to update the probabilities as described in [10]. This step decreases the uncertainty of the channel balances and is crucial for the improvement and different results in the next round which is why we explicitly explain how the knowledge is updated in several cases.…”

“…Since the computation with base fees is not feasible 11 , we have ignored the base fees in all our computations. In fact, we started experimenting by not even optimizing for low fees at all but just for high probabilities.…”

“…So it is the acknowledgements is completely coincidental as we used that graph even before we had the discussion with the individual. 10 which should be easily avoidable at the moment by incorporating some buffer in the fee size, as long as it remains lightly used 11 and the fees are also currently low enough to not impact the results too much notable that the optimal results would be even better, although negligibly so.…”

Flood & Loot: A Systemic Attack On The Lightning Network

“…The network aims to keep nodes' balances private, and therefore a channel's exact balance is never announced. Several methods to deduce the exact balance of a channel have been suggested [13,31,33]. The main technique is to request a payment via the channel, then, based on whether the payment succeeds to traverse the channel or not, the sender learns whether the balance is greater or smaller than the requested payment amount.…”