Counting Down Thunder: Timing Attacks on Privacy in Payment Channel Networks

BY KEYHUNTER 06.03.2025
Counting Down Thunder: Timing Attacks on Privacy in Payment Channel Networks

The Lightning Network is a scaling solution for Bitcoin that promises to enable rapid and private payment processing. In Lightning, multi-hop payments are secured by utilizing Hashed Time-Locked Contracts (HTLCs) and encrypted on the network layer by an onion routing scheme to avoid information leakage to intermediate nodes. In this work, we however show that the privacy guarantees of the Lightning Network may be subverted by an on-path adversary conducting timing attacks on the HTLC state negotiation messages. To this end, we provide estimators that enable an adversary to reduce the anonymity set and infer the likeliest payment endpoints. We developed a proof-of-concept measurement node that shows the feasibility of attaining time differences and evaluate the adversarial success in model-based network simulations. We find that controlling a small number malicious nodes is sufficient to observe a large share of all payments, emphasizing the relevance of the on-path adversary model. Moreover, we show that adversaries of different magnitudes could employ timing-based attacks to deanonymize payment endpoints with high precision and recall.

1 INTRODUCTION

In the years since its introduction, Bitcoin [36] has proven the feasibility of conducting financial transactions without a centralized clearing house. While it enjoys increasing popularity around the world, it has been shown that its open and transparent design severely limits the achievable transaction throughput [11] as well as the privacy on, both, the consensus [34] and networking layers [18].

Second-layer solutions, such as Bitcoin’s Lightning Network [43], promise to mitigate these shortcomings by establishing a network of off-chain payment channels, i.e., a payment channel network (PCN). PCNs enable rapid payment processing between any two channel endpoints without consulting the blockchain every time. That is, incremental updates are negotiated locally instead of requiring a global agreement. Local transactions are not only much faster, but also do not leak information to noninvolved third parties. This local negotiation is however only possible in a secure manner, because the parties deposit a collateral during channel establishment. In combination with a clever exchange of multi-signature transactions, the blockchain serves as a mechanism to resolve conflicts. In addition to payments between neighboring nodes, the Lightning Network allows payments to traverse over multiple channels in the network graph, i.e., multi-hop payments. Therefore, channel balances have to be updated atomically, which is enforced by the utilization of Hashed Time-Locked Contract (HTLC) payment protocols. In an attempt to avoid information leakage to intermediate nodes, sender and receiver exchange messages by applying an onion routing encryption scheme; more specifically, the Sphinx mix packet construction [12].

In this work, we however show that the privacy guarantees of the Lightning Network may be subverted by an adversary conducting timing attacks on the message exchange during payment processing. In particular, an on-path adversary may reduce the anonymity set of potential sender and receiver nodes based on the payment amount and the HTLC’s time-lock delta value. Following this initial reduction of privacy, the adversary may apply timing-based estimators to infer the likeliest payment path endpoints, potentially deanonymizing the sender and receiver of a payment. This attack is especially fatal, since countermeasures directly conflict with the design goal of secure and rapid payments. Moreover, as our analysis shows, the single most central node is already capable of observing close to 50% of all payments in the network, while the four most central nodes observe an average of 72% payments. These findings are in accordance with recent results [50] and emphasize the relevance of the on-path attacker model.

We expose that an adversary can probe the network and is able to derive a model of edge latencies, which enables timing attacks. Furthermore, we show how the observation of timing patterns, inherent to interactive multi-hop message exchanges, may be used by the adversary to calculate time differences that correspond to her distance from the respective payment endpoint. To this end, we introduce timing-based estimators that first exclude invalid payment paths, before ranking candidate nodes according to their likelihood, i.e., return a maximum likelihood estimation. To confirm the feasibility of retrieving such measurements, we developed a proof-of-concept implementation of the measurement functionality and deployed it on a segregated part of the Lightning Network testnet. Furthermore, to enable evaluation of the attack vector in larger scenarios, we developed a discrete-event network simulator that allows to simulate the payment routing protocol based on real-world snapshots of the public Lightning Network. Utilizing the simulator, we study the timing attacks in scenarios modelling adversarial capabilities of different magnitudes. The results show that an adversary controlling more than 10 nodes could easily deanonymize payment sources and destinations with a precision of more than 50%. The sensitivity highly depends on the malicious nodes’ position in the network, though, but can reach up to 50% recall. Moreover, we show that our time-based estimators are generally outperforming a First-Spy estimator, which serves as a baseline. This superior result becomes particularly apparent when considering full deanonymization, i.e., the case in which the adversary was able to correctly identify both payment endpoints.

To summarize our contributions, we (1) present a unified model for the Lightning Network that captures the payment channel graph…

as well as properties of the underlying peer-to-peer network, (2) propose a method for probing the network to build an (adversarial) edge latency model, (3) introduce timing attacks on privacy in payment channel networks that make use of time difference measurements of interactive multi-hop message exchanges, and (4) analyze the feasibility and adversarial success of the introduced attack vector based on a proof-of-concept measurement node and comprehensive network simulations.

The remainder of this paper is structured as follows. Section 2 gives a primer on the Lightning Network and its payment protocol. Section 3 introduces models and notations that serve as the basis for our further analysis. In Section 4, we introduce timing attacks on privacy in payment channel networks, and evaluate their feasibility and adversarial success in Section 5. Section 7 discusses related work, before Section 8 concludes the paper.

2 LIGHTNING NETWORK PRIMER

The Lightning Network is the most prevalent payment channel network (PCN) to date, i.e., it is a network of payment channels that are established between two endpoints by locking a certain amount of funds (the channel capacity) on-chain, whose individual allocation (the respective channel balances) can then be negotiated rapidly between the two involved parties. Payments routed over multiple intermediate channels allow to send money to only remotely connected receivers while being secured through the application of Hashed Time-Locked Contract (HTLC) payment protocols. The HTLC protocol ensures that a forwarding intermediary node is reimbursed in the case of payment success, and in case of a failure may still retrieve its locked funds after expiration of the time-lock delta safety period. In the following, we give a technical overview of the Lightning Network’s channel construction, routing, and payment processing mechanics.

2.1 Connection and Channel Establishment

A new peer joining the Lightning Network has first to establish a network connection to a node connected to Lightning’s TCP-based peer-to-peer overlay network. Since every node in the network holds an associated long-term secp256k1 [8] public key by which it is identified, all inter-peer communications following the initial key exchange handshake are authenticated and encrypted based on the Noise [42] protocol framework.

In order to initiate the establishment of a new payment channel to a neighboring node, the peer sends an open_channel message that is typically answered by an accept_channel message, through both of which the channels parameters, in particular the channel capacity and initial balances, are negotiated. Using the exchanged information, the initiating peer is then able to issue a funding transaction which it broadcasts in the Bitcoin network. After the funding transaction is confirmed on-chain, the channel is established and may be used for payment processing. Furthermore, if the new peer wants to act as payment hub, i.e., forward payments for others, it can announce the node’s and channel’s existence to the network by disseminating the respective node_announcement and channel_announcement messages in the peer-to-peer network. As these messages also contain the necessary routing information, such as the channel capacity and associated routing fees, they are broadcasted in Lightning’s overlay network. These messages also include the cltv_expiry_delta parameter, which allows a node to declare the maximum time it is willing to have its funds locked up in case an HTLC is not fulfilled in an orderly fashion.

2.2 Payment Routing

Let’s assume that Alice already connected her node A to the network and established at least one channel over which she is able to send and receive payments. If she now wants to send a payment to a destination node C, she has to first find a suitable path in the network and then has to setup the corresponding HTLC to conduct the payment. In order to illustrate this example, the sequence of exchanged messages is shown in Figure 1.

Initially, it is required for A and C to have some out-of-bounds communication channel over which C can supply an invoice to A that includes, without limitation, its identifying public key, the amount to be paid, as well as the payment hash, i.e., the hash $H(r)$ of a random secret $r$. Based on the publicly available routing information, A then employs source routing in order to determine a path to C that has sufficient capacity to possibly be able to route her payment. While the behavior of the source routing algorithm is not specified as part of the BOLT specifications [39], typically a modified version of Dijkstra’s shortest path algorithm [15] that considers routing fees and past payment success is utilized for route selection. Note that this algorithm might fail, if there is no path of sufficient capacity available. However, let’s assume without loss of generality that this is not the case and the algorithm yields a path over the intermediate node B.

Given this path, Alice is able to initiate the HTLC construction, i.e., a number of conditional payments that either may be redeemed by producing the pre-image $r$ to the challenge $H(r)$ or would time out after a certain lock-time. In order to facilitate the payment, A calculates two essential values for each respective hop:

the amount this hop should forward, which is calculated by adding the accruing fees for each respective hop to the payment amount, which is hence increasing towards the destination.

(2) the necessary remaining time-lock value for the outgoing hop, which is decreasing towards the destination.

Alice then encodes this information in an onion routed packet corresponding to the Sphinx packet scheme [12]. That is, the packet is constructed through multiple layers of encryption, each wrapping information identifying the next hop, the amount to forward, as well as the remaining lock-time value. She then initiates the payment by sending an update_add_htlc message carrying the payment hash ( H(r) ) as well as the onion packet (represented as ( \otimes )) to the next hop, i.e., ( B ). The latter, as each intermediate node along the payment path, is then able to decrypt the packet to receive its payload and forward the HTLC offer to the next hop. However, ( B ) only proceeds after the new conditional payment based on the challenge ( H(r) ) is incorporated in the state of the affected payment channel and this state change is irreversibly committed through a handshake of commitment_signed and revoke_and_ack messages.

After the pending state updates have been negotiated, ( C ) forwards the HTLC by attaching the remainder of the onion packet to an update_add_htlc message sent to the next hop, which proceeds in the same way. In case any of the intermediary nodes does not agree with the payment, e.g., when the channel does not hold a sufficient balance or fee and time-lock values determined ( A ) do not meet their expectations, they may fail the HTLC by replying with an update_fail_htlc message carrying failure message that is onion-encrypted and propagated back along the path to the origin node ( A ). As this may happen at any point in time, Lightning does not provide any guarantees on payment reliability and hence can be classified as a best-effort network.

Once the HTLC construction reaches the final destination, ( C ) supplies the solution ( r ) to the payment hash challenge ( H(r) ) via a corresponding update_fulfill_htlc message, which is propagated back on the inverse payment path, allowing intermediary nodes to redeem their conditional payments. Thereby, they settle the pending HTLC and gain the determined fee. Note that while the commitment_signed and revoke_and_ack messages are only exchanged between immediate neighbors, the update_add_htlc, update_fulfill_htlc, and update_fail_htlc messages are forwarded back and forth the payment path, which makes them observable by intermediate nodes.

3 MODEL

In the following, we introduce the models and notations that serve as the basis for further analysis.

3.1 Network Model

As discussed in the previous section, PCNs typically exhibit multiple layers: while peer-to-peer communication is handled by the peer-to-peer network layer, the payments themselves are sent and forwarded in the network of payment channels. While peers may join the peer-to-peer network without establishing payment channels, peers with an established payment channel have to be connected in the peer-to-peer network. We in the following assume the peer-to-peer network to be congruent with the channel layer and build a unified model based on the public network of payment channels.

A PCN can therefore be modeled as a single graph ( G = (V, E, \phi) ), where ( V = {v_0, \ldots, v_n} ) is the set of the network’s nodes and ( E = {e_0, \ldots, e_m} ) represent the set of edges, i.e., payment channels. Since every node may have multiple payment channels to any other node, ( G ) is a loopless multigraph and ( \phi : E \to {{u, v} \mid u, v \in V \land u \neq v} ) associates the set of edges with their endpoint nodes.

In each direction, an edge ( e ) is associated with a balance ( \text{bal}(e, u, v) ) that denotes the available balance from ( u ) to ( v ) on channel ( e ), where ( u, v \in \phi(e) ). Edges also have an associated fee function, defined by ( \text{fee}(a|e, u, v) ) that takes the payment amount ( a ) as a parameter and yields the fees that accrue when forwarding over this channel. Note that during routing directionality matters and hence balance and fee functions are asymmetric. That is, generally ( \text{bal}(e, u, v) \neq \text{bal}(e, v, u) ) and ( \text{fee}(a|e, u, v) \neq \text{fee}(a|e, v, u) ). In contrast, the edge capacity is symmetric and defined as the sum of balances, i.e., ( \text{cap}(e) = \text{bal}(e, u, v) + \text{bal}(e, v, u) ). Furthermore, associated with the edges are the respective time-lock delta values ( \text{tl}(e, u, v) ) that indicate the maximum time in block height the forwarding node is willing to have its funds locked in case an HTLC fails. And lastly, the function ( \text{lat}(e) ) assigns a latency distribution to each network edge that represents the network and processing delays, which are induced when messages traverse the edge in the underlying peer-to-peer network. Note that while balances and latencies are changing frequently and are only known locally, fees, capacities, and time-lock requirements are considered static and are publicly accessible by all nodes in order to enable the source routing process. We denote this public graph information as ( G_{\text{pub}} = (G, \text{cap}, \text{fee}, \text{tl}) ).

Based on this model of payment channel networks, we can now introduce the following definitions.

Definition 3.1 (Payment). A payment is defined as the tuple ((s, t, a, \text{max})), where ( s ) and ( t ) respectively denote the origin and destination nodes, ( a ) is the amount sent by ( s ), and ( \text{max} ) signifies the maximal total time the payment amount may be locked.

Definition 3.2 (Path Validity). A path from node ( s ) to node ( t ) in the network is a sequence of connecting edges, denoted as a tuple ( p = (e_0, e_1, \ldots, e_i) ), where ( \phi(e_0) = {s, v_1}, \phi(e_1) = {v_1, v_2}, \ldots, \phi(e_i) = {v_i, t} ).

A path ( p ) is called time-lock-valid w.r.t. a total time-lock delta ( \text{tl} ); if the remaining time the payment might be locked is smaller than the time the forwarding node would be willing to accept, i.e.,

[ \forall e_i \in p, u_i, v_i \in \phi(e_i) : \text{tl}(e_i, u_i, v_i) \geq \text{max} – \sum_{j=0}^{i-1} \text{tl}(e_j, u_j, v_j) ]

Furthermore, a path ( p ) is called capacity-valid w.r.t. an amount ( a ), if all edges have capacities higher than the forwarding amount including accruing fee, i.e.,

[ \forall e_i \in p, u_i, v_i \in \phi(e_i) : \text{cap}(e_i) \geq f_i ]

where $f_i$ is defined recursively as $f_1 = a$ and $f_{i+1} = f_i + \text{fee}(f_i, e_i, u_i, v_i)$. Note that a path $p$ being capacity-valid for amount $a$ does not necessarily imply that a payment of size $a$ can actually be routed over $p$.

A payment can be routed only if the path does not only exhibit sufficient capacities, but also balances to forward the respective amount,

$$ \forall e_i \in p, u_i, v_i \in \phi(e_i) : \text{bal}(e_i, u_i, v_i) \geq f_i, $$

in which case we call it balance-valid or a-routable.

Independently of this special case, however, we call a payment path generally valid or just valid, if it is timelock-valid and capacity valid. Note that therefore path validity describes if a path could potentially be used to route a payment with respect to the parameters, not if it actually may be used or is being used.

Definition 3.3 (Routing Algorithm). A routing algorithm $R$ is a function that takes a payment $x = (s,t,a,\Delta_{\text{max}})$ and the public graph information $G_{\text{pub}} = (G, \text{cap}, \text{fee}, \Delta_{\text{t}})$ as arguments and outputs a valid payment path, i.e.,

$$ R(x, G_{\text{pub}}) \rightarrow p, $$

where $p$ is a capacity-valid and timelock-valid path from $s$ to $t$.

Definition 3.4 (Reachability). In the graph $G$, a node $t$ is reach-able from a node $s$ if there is a path between them. Similarly, we call $t$ capacity-reachable, balance-reachable, or timelock-reachable from $s$, if there exists respectively a capacity-valid, balance-valid, or timelock-valid path from $s$ to $t$, w.r.t. a given payment $(s,t,a,\Delta_{\text{max}})$.

Note that these reachability notions induce subgraphs $R_{\text{cap}}, R_{\text{bal}}$, and $R_{\text{t}}$, where

$$ G \supseteq R_{\text{cap}} \supseteq R_{\text{bal}} \quad \text{and} \quad G \supseteq R_{\text{t}}. $$

3.2 Adversary Model

3.2.1 Lightning’s Security Goals.

Given payments are routed directly between source and destination nodes, secured by the HTLC construction, and the path is obscured by employing the Sphinx-based onion routing scheme, the Lightning Network aims to deliver the following security goals:

Balance security: No third party should be able to steal funds, or otherwise alter channel balances without the implicit consent of the involved parties.

Off-path local unobservability: Only nodes on the payment path should be informed about an occurring payment.$^1$

Off-path value privacy Since all communications during payment processing are encrypted, only on-path nodes should get to know the amounts forwarded.

On-path sender/receiver-anonymity: As every node only knows its predecessor and successor on the payment path, it should not be able to identify the sender or receiver of a payment.

$^1$Note however that this assumes a local perspective on the network. Payment unobservability may not hold when we assume a more powerful attacker model, such as an adversary that has access to large parts of the underlying network infrastructure. Such adversaries are known to be potentially capable of advanced deanonymization attacks, and are notoriously hard to defeat.$^{[22]}$

Receiver’s sender-anonymity

The receiver of a payment should not be able to identify who initiated a payment.$^2$

3.2.2 Adversarial Goals and Capabilities.

While the off-path unobservability of payments could potentially be subject of a deanonymization attack run by a global passive adversary, in this work we analyze the feasibility of subverting the on-path anonymity properties of nodes that send and receive payments. In particular, we focus on attack vectors that allow a local adversary incorporating side-channel information to potentially subvert on-path sender/receiver anonymity as well as receiver’s sender-anonymity.

To this end, we assume an internal local adversary that controls a set $M = {m_0, \ldots, m_k}$ of malicious nodes in the network that act as payment-processing intermediaries, which in accordance with literature may also be referred to as spies. We furthermore assume that the adversarial nodes $M$ behave according to protocol and are able to send and receive protocol-compatible messages, e.g., in order to probe the network to build a latency model of their surroundings.

When payments are routed over an adversarial node $m_i \in M$, it keeps track of each network message $\text{msg}$ arriving over the edge $e_m$, as well as the corresponding timestamp, i.e., they store the datasets

$$ D_i = {(m_i, e_m, \text{msg}, \text{lat})}. $$

Based on the merged dataset $D = \bigcup_i D_i$, the public graph data $G_{\text{pub}}$, and the estimated link latencies $\hat{\text{lat}}$, the adversary then aims to associate any observed payments $x = (s,t,a,\Delta_{\text{max}})$ with the respective source node $s$ and destination node $t$. For this classification, the adversary may apply different source and destination estimators $M_s$ and $M_t$ that given the input data yield a respective estimation, i.e.,

$$ M_s(x|D, G_{\text{pub}}, \hat{\text{lat}}) = \hat{v}s \quad \text{and} \quad M_t(x|D, G{\text{pub}}, \hat{\text{lat}}) = \hat{v}_t, $$

where $\hat{v}_s, \hat{v}_t \in V$. For the sake of brevity, we in the following refrain from always giving an exhaustive list of arguments and opt to abbreviate notation as $M_s(x|D)$ and $M_t(x|D)$.

3.3 Anonymity Metrics

In order to quantify adversarial success and analyze the privacy properties of the network, we utilize the following privacy metrics.

Well known performance measures for the adversarial success of estimator-based deanonymization attacks are the combination of precision and recall.$^{[17]}$

Assuming $X$ being the set of all payments and $C \subseteq X$ the set of all payments observed and classified by the adversary. Let furthermore $X_u \subseteq X$ denote the set of all payments that originate from (or end at, in case of destination estimation) node $u$ and analogously $C_u$ denote the set of payments classified to originate from (end at) node $u$, i.e.,

$$ C_u = {x \mid M_s(x|D) = u}. $$

Then the precision $D$ of the estimator $V$ is defined as the share of classified payments that were indeed correctly classified, i.e.,

$$ D = \frac{|C_u \cap X_u|}{|C|}. $$

$^2$Notably, the Lightning Network currently does not guarantee the inverse, i.e., the possibility for a receiver to stay anonymous. However, this may feasible in the future, when the currently discussed Rendez-Vous Routing proposal is implemented.$^{[14]}$

Timing Attacks on Privacy in Payment Channel Networks

The estimator’s recall $R$ however is the share of all payments in the network that were correctly classified,

$$ R = \frac{|C_u \cap X_a|}{|X_l|}. $$

A unified measure for the accuracy of an estimator is given by the harmonic mean of precision and recall, also known as the $F_1$-measure:

$$ F_1 = 2 \cdot \frac{D \cdot R}{D + R}. $$

4 TIMING ATTACKS ON PRIVACY

In the following, we describe the steps necessary to conduct timing attacks on privacy in payment channel networks.

4.1 Improving Topological Advantage

The attacker wants to maximize the number of payment paths it is included in by the victim’s routing algorithm. While the client-side routing behavior is not standardized as part of Lightning’s BOLT specifications, most implementations of the Lightning protocol rely on modified versions of Dijkstra’s shortest path algorithm [15] that consider the fees as well as other parameters. Note that, as recent literature has observed [35], more than 90% of today’s Lightning Network nodes run the LND implementation of the Lightning protocol. In the following, we therefore assume LND to be the default implementation and use it as the base of our further analysis. LND’s path finding algorithm selects candidate edges based on a weight function $w_e$ that considers routing fees for the routed amount $a$, as well as a risk factor $r_f$ that aims to capture the worst-case lock time:

$$ w_e = \text{fee}(v|a, e, u) + a \cdot \Delta \text{delay}(e, u, v) \cdot r_f, $$

where $r_f = 1.5 \cdot 10^{-8}$ is the default configuration.

Therefore, by setting time lock parameters and channel fees to the minimal allowed values, the adversary can minimize the routing weight function of the victim’s client software, and thereby maximize the probability that at least one of the malicious nodes is included in the payment path. Tochner et al. [50] studied this kind of route hijacking in the context of denial-of-service attacks. They showed that at the time of writing ten nodes are part of 80% of all payment paths, and 30 nodes of over 95% of payment paths. Furthermore, while the problem of optimal edge additions for maximum betweenness centrality has previously been shown to be NP-hard [2, 5, 16], the authors provide a greedy algorithm with which an adversary improve its topological advantage. To this end, they were able to show that the creation of only fifteen edges would suffice to hijack more than 80% of LND payment paths. Their observations are generally in accordance with our findings regarding adversarial path inclusion (cf. Section 5.3.2) and highlight the relevance of the on-path attacker model.

4.2 Building the Latency Model

As a data basis for the classification of observed payments, the adversary initially has to probe the network to retrieve characteristic timing measurements. These measurements allow her to build a model of latencies $\hat{\text{lat}}$ that are encountered when payments are routed over a specific link, which then in turn are used as a priori knowledge for the estimators.

4.2.1 Retrieving Path Latency Measurements. In order to probe for the characteristic latency measurements, the adversary can exploit the fact that due to Lightning’s use of the Sphinx packet format, invalid or failing payments can only be discovered by the node that they are actually failing at. That is, as all nodes only see the parts of onion-routed data they are able to encrypt and do not know the full path’s properties, they have to optimistically forward all payment requests based on the assumption that it will succeed. Therefore, the adversary is able to craft payments that look valid to all intermediaries, but are bound to fail at a specific hop along the path, e.g., because of insufficient fees or an invalid maximum time-lock value. Utilizing this probing method, the adversary can record the time difference between sending the initial $\text{update_add_htlc}$ message and retrieving the final $\text{update_fulfill_htlc}$ to retrieve a measurement that encompasses all delays that were encountered along the measured payment path.

4.2.2 Estimating Edge Latencies. The adversarial node utilizes the described probing method to retrieve a reliable model for paths covering every link in the network. To this end, she iteratively increases the probing path lengths and calculates link latencies by subtracting the estimated latencies of partial paths. That is, the adversarial node $m_l$ starts by repeatedly probing paths lengths $l = 1$ that cover its immediate neighbors $v_j$, i.e., $p_0 = (e_t), m_1, v_j \in \phi(e_t)$, and calculates the mean $\hat{\mu}_e$ and standard deviation $\hat{\sigma}_e$ values for these links, i.e.,

$$ \hat{\mu}e = \frac{\sum{i=0}^{n} \text{probe}_i(p_1)}{T_n}, $$

$$ \hat{\sigma}e = \sqrt{\frac{\sum{i=0}^{n} (\text{probe}_i(p_1) – \hat{\mu}_e)^2}{T_n}}, $$

where $T$ is a normalizing factor accounting for the number of link traversals incurred during the message exchange over the measured hop. In this case, we assume $T = 4$, i.e., three traversals for $\text{commitment_signed}$ and for the $\text{revoke_and_ack}$ handshake and one for $\text{update_fulfill_htlc}$ (see Figure 1).

The adversary can then increase the path lengths and iteratively build the latency model for these longer paths $p_l = (e_1, \ldots, e_l)$:

$$ \hat{\mu}e = \frac{\sum{i=0}^{n} \text{probe}_i(p_1)}{T_n}, $$

$$ \hat{\sigma}e = \sqrt{\frac{\sum{i=0}^{n} (\text{probe}_i(p_1) – \hat{\mu}_e)^2}{T_n}}. $$

Given these parameters, the adversary can build the normally distributed edge latency model as

$$ \hat{\text{lat}}(e_i) = N(\hat{\mu}_e, \hat{\sigma}_e^2). $$

Note that this model does not just include the network delay, but also incorporates any processing delays arising on the intermediate nodes. As this unified latency model captures various side effects, we can refrain from considering them separately in the attack estimators.

Moreover, modeling timing behavior in such an approximative way is bound to induce a certain margin of error. This uncertainty is expressed by the variances growing with increasing lengths of the measured paths. In the following we therefore propose a method to aggregate the timing models from multiple malicious vantage points to increase overall accuracy.

4.2.3 Model Aggregation. As the adversary may control multiple nodes in the network to increase the probability of inclusion in payment paths, each malicious node may create a timing model from their point of view. As the margin of error increases with each additional hop in the measured paths, the aggregated model should not simply average over all measurements. Instead, it merges the individual model by applying an arithmetic mean weighted with the reciprocal distance from the measured node, i.e.,

[ \forall m_i \in M, v_j \in V : \hat{w}_i = \frac{1}{d(v_j, m_i)}. ]

[ \hat{\mu}{e, \text{tot}} = \frac{\sum{i=0}^{n-|M|} \hat{w}i \mu{i,e}}{\sum_{i=0}^{n-|M|} \hat{w}_i}, ]

[ \hat{\sigma}{e, \text{tot}} = \sqrt{\frac{\sum{i=0}^{n-|M|} \hat{w}i (\hat{\mu}{i,e} – \hat{\mu}{e, \text{tot}})^2}{\sum{i=0}^{n-|M|} \hat{w}_i}}. ]

The adversary therefore retrieves the aggregated latency model ( \hat{\text{lat}}{\text{tot}}(t_1) = N(\hat{\mu}{e, \text{tot}}, \hat{\sigma}_{e, \text{tot}}^2) ).

4.3 Estimator-based deanonymization attack

In order to be able to deanonymize the sender and receiver of a payment, it has to be routed over at least one observation point controlled by the adversary (see Figure 2). In contrast to previous approaches that apply a First-Spy estimator that simply estimates the node adjacent to the point of observation to be the payment’s respective endpoint, our approach builds a maximum likelihood estimator (MLE) over all paths the observed payment could possibly have taken. To this end, the malicious nodes record the time differences of interactive message exchanges and, after reducing the candidate set by considering only valid paths (see Definition 3.2), estimate the source or destination of the payment according to the likelihood that the time differences stem from a message exchange over this particular path.

4.3.1 Recording Time Differences. To utilize the timing of messages in order to estimate the source or destination of a payment, the adversarial nodes ( M ) have to observe end-to-end transmitted messages belonging to the same payment at two different points in time, i.e., ( t_0 ) and ( t_1 ). This allows to calculate the time difference ( \delta_t = t_1 – t_0 ) it took the observed payment to travel from the first point of observation ( m_0 \in M ) to the source or destination, and back to the second point of observation ( m_1 \in M ).

In particular, the malicious intermediate nodes record the point in time ( t_0 ) when they forward a payment via \text{update_add_htlc} and ( t_1 ) upon receipt of the corresponding \text{update_fulfill_htlc}, which yields a time difference ( \delta_t ) corresponding to the distance to the payment’s destination (cf. Figure 1). In this case, the adversary does not have to interfere with the payment processing protocol in order to collect the necessary information to conduct destination estimation. Hence, the adversary acts in a purely honest-but-curious model, and therefore cannot be detected by outside parties.

However, since the message exchange from the source node to the intermediate node is non-interactive, an advanced attack strategy is required in order to retrieve suitable timing measurements in this direction. To this end, the adversary intentionally fails the first observed payment attempt by sending a \text{update_fail_message}. She also records the current time as ( t_0 ). After receiving the failure message, the payment’s sender is forced to retry the failed attempt, which is typically done immediately to avoid further delays. When the second payment attempt is observed at time ( t_1 ), the adversary can calculate the ( \delta_t = t_1 – t_0 ) value which corresponds to its distance from the source node.

In general, the chosen paths and points of observation may be different, in which case the adversary has only a certain chance of observing the second payment attempt. While this would introduce additional uncertainty to this part of the adversarial strategy, as we discuss later in Section 5.2, the adversary may force a sender to send the second payment attempt over the same path as before, which removes this uncertainty. This is possible in practice due to an implementation detail of LND.

We therefore in the following assume the two observations to occur at the same malicious node, i.e., ( m_0 = m_1 ). Moreover, in the case that multiple malicious nodes are part of the payment path and observe the payment, the source or destination estimation is based on the measurements recorded by the malicious node closest to the respective endpoint.

4.3.2 Source and Destination Estimation. The estimation of source and destination of a payment relies on selecting the likeliest paths the payment could have taken before it arrived at the observation points. Therefore, in order to reduce the initial uncertainty, the adversary excludes paths that are capacity-unreachable or time-lock unreachable given the observed amount ( a_{\text{obs}} ) and ( \Delta_{\text{obs}} ), i.e., she only considers nodes in

[ \mathcal{R}{\text{cap}} \cap \mathcal{R}{\Delta} \subseteq \mathcal{G}_{\text{pub}}. ]

The adversary then builds candidate aggregated latency distributions ( \hat{\text{lat}}p = T{\text{obs}} \cdot \hat{\text{lat}}(e_{\text{obs}}) + \ldots + T_l \cdot \hat{\text{lat}}(e_l) ) for each candidate path ( p = (e_{\text{obs}}, \ldots, e_l) ), where ( e_{\text{obs}} ) denotes the edge the measurement was conducted through. Furthermore, the weights ( T_l ) denote the number of messages that would have been exchanged over the edge ( e_l ). Note that the possibility of such an aggregation relies on the fact that the sum of normally distributed variables may be calculated as

[ N(\mu_1, \sigma_1^2) + N(\mu_2, \sigma_2^2) = N(\mu_1 + \mu_2, \sigma_1^2 + \sigma_2^2). ]

5 EVALUATION

In the following, we evaluate the feasibility, accuracy, and reliability of the presented attacks on privacy in payment channel networks.

5.1 Ethical Considerations

Research on the security and privacy of live communication systems is always in danger of infringing on the rights of the participating individuals. In accordance with the Menlo Report [4], we aim to minimize our interference with the live network as well as the data collected from unknowing parties.

That is, in order to evaluate the presented attacks on privacy in payment channel networks, we pursue a two-pronged strategy: First we show the feasibility of the attacks through a proof-of-concept implementation that was installed on an entirely segregated part of the Lightning Network testnet, which ensures that no involuntary parties were affected by our experiments.

Second, to be able to evaluate larger attack scenarios and analyze the effect these attacks have on the network’s privacy overall, we rely on model-based network simulation that is not connected in any way to unknowing individuals and hence does not raise any ethical concerns. In particular, while the simulations utilize latency measurements that were retrieved through external means, i.e., ICMP ping on nodes from the public internet, we explicitly refrain from conducting internal latency measurements as discussed in Section 4.2, since such measurements could interfere with the functionality of the network.

5.2 Proof-of-Concept Implementation

The described attacks on payment privacy in payment channel networks rely on the ability of malicious intermediary nodes to retrieve latency measurements from the source and to the destination of an observed payment. As a proof of concept that obtaining these measurements is indeed practical, we implemented a respective plugin for c-lightning [10].

5.2.1 Retrieving Latencies to Destination. When the plugin is started on the intermediary node, it registers to be notified of forwarded payments. In particular, it utilizes the forward_event notification to record the times $t_0$ HTLC payment hashes $H(r)$ are first observed, as well as the times $t_1$ they are marked as resolved. The plugin furthermore records the node identifier $v_M$ of the measurement node and the identifier $e_{next}$ of the channel the payment was forwarded over. That is, it records the tuple $(H(r), u_M, e_{next}, t_0, t_1)$ that is then ready to be used as input a payment destination estimator.

5.2.2 Retrieving Latencies from Source. Because the communication with the payment source is non-interactive, the adversary has to rely on observing retried payment attempts, as discussed above. To this end, the proof-of-concept implementation makes use of the htlc_accepted hook provided c-lightning’s plugin API in order to intercept incoming update_add_htlc messages. When a payment with a previously unobserved payment hash $H(r)$ is observed, the plugin records a corresponding timestamp $t_0$ and rejects the payment attempt. As the payment is is then retried, the timestamp $t_1$ of the second observation by an adversarial intermediary node is recorded. This hence allows the adversary to estimate the latency from the source and record the tuple $(H(r), u_M, e_{prev}, t_0, t_1)$.

Algorithm 1: Source / Destination Estimator

Function $\delta, \delta_{obs}, \delta_{eobs}, G_{pub}$

  • remove all capacity-invalid paths from $G_{pub}$
  • remove all timelock-invalid paths from $G_{pub}$

forall $v \in V$ do initialize end

$v_{fst} \leftarrow \text{get_neighbors}(e_{obs})$ // First hop is known

$\delta_{obs} \leftarrow T_{obs} \cdot \hat{\delta}(e_{obs})$

path_lats[$v_{fst}$] $\leftarrow {\hat{\delta}(e_{obs})}$

likelihood[$v_{fst}$] $\leftarrow \hat{\delta}_{fst}(\delta)$

while $v_{cur} \leftarrow \text{next_unvisited()}$ do $D_{cur} \leftarrow \text{path_lats}[v_{cur}]$ $\hat{\delta}{cur} \leftarrow \sum{d_i \in D_{cur}} T_i \cdot d_i$ // Aggregate dists. $p_{cur} \leftarrow \hat{\delta}{cur}(\delta)$ forall $v_n$ in neighbors($v{cur}$) do $e_n \leftarrow \text{cheapest_edge}(v_{cur}, v_n)$ $D_n \leftarrow D_{cur} \cup {\hat{\delta}(e_n)}$ $\hat{\delta}{n} \leftarrow \sum{d_i \in D_n} T_i \cdot d_i$ $p_n \leftarrow \hat{\delta}_{n}(\delta)$ skip // Only increasing likelihood end

likelihood[$v_{cur}$] $\leftarrow p_{cur}$ // Update candidate path_lats[$v_{cur}$] $\leftarrow D_n$ queue_candidate($v$) end forall visited $v$ do return candidate with max. likelihood end While it is not guaranteed to observe the second payment, the proof-of-concept implementation is able to force the payment source to reuse the same payment path by exploiting a weakness in the interplay of Lightning’s network protocol and LND-specific application behavior. That is, as channel updates may occur in the middle of a payment attempt, LND elects not to penalize intermediary nodes during route selection, if they report a channel policy failure, i.e., fail the payment with amount_below_minimum, fee_insufficient, incorrect_cltv_expiry, or channel_disabled failure codes [27, 37]. Note that LND only once grants such nodes a “second chance”, independently of whether the returned channel policies entail an actually meaningful update [26]. This allows our plugin to fail the first observed payment attempt with a corresponding update_fail_htlc failure message, which prompts the LND endpoint to immediately retry the payment over the same malicious intermediary node, effectively enabling reliable latency measurements.4

5.2.3 Experimental Testnet Setup. In order to confirm the feasibility of retrieving the required time differences, we deployed an experimental setup on a segregated part of Lightning’s testnet network. As shown in Figure 3, we deployed three nodes A, B, C running LND and one malicious node M running c-lightning with our proof-of-concept plugin. Between these nodes, channels were created so that the source node A would have two possible paths to send payments to destination node C: one over the benign node B, and one over M. While the channels between the benign nodes were configured with default fee settings (base_fee = 1 and fee_rate = 0.00001), the malicious M set its channel fees to 0 to increase its probability of payment path inclusion.

We then sent payments in one minute intervals from node A to node C. For all payments, node A chose the path (A, M, C), which proves M’s strategy to be successful. Moreover, as discussed above, M would in each case reject the first payment attempt and only proceed on the second try, allowing it to retrieve latency measurements for both source node A as well as destination node C. It therefore confirms that we can retrieve the time differences that pose the basis for our timing attacks. As the next step, we can use the measurements to feed our estimators, which would infer source and destination.

5.3 Network Simulations

5.3.1 Simulator & Simulation Model. In order to enable a larger-scale evaluation of the feasibility and impact of timing attacks on privacy, we developed a network simulator that allows to simulate payment routing in the Lightning Network based on real-world data.5

The simulator consists of around 3,000 lines of Rust code that implement the network model introduced in Section 3, as well as the logic to run time-discrete simulations of multi-hop payments. To this end, it recreates the multigraph of network nodes and edges as well as the necessary associated data (such as capacities, balances, time-lock deltas, etc.) from a network snapshot. Each node can queue events in simulation time, i.e., a monotonically increasing clock with a resolution of 1 ns. This allows to simulate message exchange according to times sampled from the underlying latency model, without introducing unnecessary side-effects, even when the events happen concurrently. The messaging logic mimics the Lightning payment protocol, making it possible to simulate and measure time differences in the message exchange, e.g., as depicted in Figure 1. In order to find payment paths, the simulator adopts the weight-based variant of Dijkstra’s algorithm from the LND implementation (see Section 4.1).

The latency model is based on a measurement study conducted in the Lightning network in March 2020. In this study, we retrieved ICMP ping measurements to each reachable IPv4 address in the Lightning Network from various geographically distributed vantage points. For more details, we refer the reader to Appendix A. While initializing the graph model, the simulator assigns a latency distribution to each edge based on the respective geographic regions of the connected nodes. In case a node only advertises a .onion address, i.e., is run behind a Tor hidden service, a random geographic location is assigned.

For the following analysis, the simulator was parametrized with a snapshot of the Lightning Network that was retrieved on May 1, 2020. Initial balance distributions between channel endpoints were assumed to be a 50/50 split of channel capacities. If not stated otherwise, in each simulated scenario 1,000 payments of varying amounts were sent between random network nodes, and each scenario was repeated 30 times with different seed values for the simulator’s random number generator to ensure statistical significance.

In the following, we are considering three main adversarial scenarios: mcentral, mrandom, and lnbig. While in the mcentral case the m highest ranked nodes with respect to their betweenness centrality are under control of the adversary, mrandom acts as a baseline in which she only controls m nodes chosen by uniform random sampling. A special case is the lnbig scenario, in which we study the potential capabilities of the 26 high-capacity nodes controlled by the single entity “LNBig.com”.

5.3.2 Share of Compromised Paths. In order to evaluate the relevance of the on-path adversary model, we analyze how likely it is that payments may be observed by adversaries of different magnitudes. In each network scenario, we simulated payments of different amounts (1, 10, 100, 1,000, 10,000, and 100,000 satoshis) between randomly chosen nodes and counted the times a malicious node was part of the path returned by the routing algorithm.

Figure 4 shows the share of compromised paths for network scenarios in which the adversary controls the m ∈ {1, …, 30} most central or random nodes, as well as for the lnbig scenario. As this corresponds to the definition of betweenness centrality, it comes

4 Note that as of this writing, a small change in the c-lightning source code is necessary to enable a plugin to return failure codes entailing a channel policy update. A corresponding patch can be found in our companion repository.

5 The simulator is available for download

to no surprise that the most central nodes observe a high and increasing number of paths. However, it is noteworthy that the single most central node is included in 37% to around 49% of payment paths, depending on the chosen amount. Additionally, the share of compromised paths follows an initial steep increase, allowing an adversary in control of the four most central nodes to already observe an average of 72%, and one in control of 30 most central nodes to be included in 90% of payment paths.

In contrast, an adversary controlling randomly placed nodes may at best observe an average of 5% of payments. Moreover, an adversary controlling the 26 lnbig nodes can observe between 11% and 25% of payments, averaging at 15%.

Generally, the payments with the highest amount result in the highest shares of compromised paths. This is most likely the case since more central nodes tend to optimize their fee policies and are also well-connected capacity wise, i.e., are more likely part of the few paths that can route higher-amount payments. However, one exception to this rule can be observed in the case of lnbig, where the 1 satoshi case yields the highest chance of path inclusion at 25%. We assume this to be the case because of LNBIG’s positioning in the network and since their nodes feature a high amount of channels with base_fee set to 0, making them more likely to be chosen by the routing algorithm for low-amount payments.

5.3.3 Adversarial Success. In the case of an adversary aiming to deanonymize payments, the performance with which she can correctly guess the source or destination of a message is also a measure of (remaining) user privacy. We therefore analyze how successful adversaries of different magnitudes would be if they would run the proposed timing-based attacks by applying the source estimator ( M_{t,T} ) and destination estimator ( M_{t,T} ). As a baseline for comparison, we also implemented and simulated the First-Spy estimators ( M_{t,FS} ) and ( M_{t,FS} ) that respectively deem the predecessor of the first point of observation and the successor of the last point of observation to be source and destination of the observed payment.

The upper row of Figure 5 shows the success of the different estimators in dependence of the evaluated scenarios and number of malicious nodes. As can be seen in the top left plot, the precision with which the adversary estimates the correct sources or destinations is generally correlated with the number of controlled malicious nodes. In case of the mcentral scenario, the precision of each estimator roughly follows a logarithmic growth function, where the First-Spy destination estimator ( M_{t,T} ) performs the worst ranging from 0.22 for a single controlled node to 0.52 for 30 malicious nodes. In contrast, the timing-based destination estimator ( M_{t,T} ) yields the highest accuracy that ranges from 0.45 to 0.75. Comparably, a potential adversary controlling the 26 lnbig nodes would be able to correctly identify senders or receivers with a precision ranging from 0.69 for ( M_{t,FS} ) to 0.73 for ( M_{t,T} ). These high estimation results can be attributed to the favorable positioning of LNBIG’s nodes in the network topology. In similar vein, it can be observed that randomly placed malicious nodes, as in the mrandom scenario, may actually guess the correct senders and receivers with quite high accuracy, as they cover the network graph more uniformly.

However, as shown in the top-middle plot of Figure 5, lnbig and mrandom nodes clearly do not perform as well in terms of recall. While the share of correctly attributed payments barely reaches 2% in the best case (( M_{t,T}, m = 30 )), lnbig is also only able to estimate the correct endpoints in 10% of all payments at best. Notably, the most central nodes have the highest recall, ranging between 7% (( M_{t,FS}, m = 1 )) and 55% of payments. Of course, the recall is highly correlated with the share of observed payments discussed in the previous subsection.

Therefore, in order to provide a unified measure that allows to analyze and compare the overall accuracy of estimators, the top-right plot of Figure 5 shows the corresponding ( F_1 )-Measure. In all cases, it shows that the First-Spy baseline is outperformed by the timing-based estimators, which reach up to an ( F_1 ) score of 0.62 for mcentral, ( M_{t,T} ), and ( m = 30 ). It is however noteworthy that while the timing-based source estimator always performs better than its First-Spy counterpart, it doesn’t do so by a significant margin in some scenarios. This happens when the malicious nodes are placed close to the source node of the payment paths, which is generally the case for the high number of short payment paths and the more distributed node positioning of the lnbig scenario in particular. Interestingly, we also found that the weight-based routing algorithm (see Section 4.1) puts edges to more central (hence, in the mcentral case, more malicious) nodes at the beginning of payment paths, which increases the success cases of the First-Spy source estimator.

In order to give a overall comparison of timing-based attacks on privacy to the First-Spy approach, we analyzed the number of payments that were fully deanonymized, i.e., the number of payments for which the adversary was able to correctly identify source and destination. To this end, the bottom row of Figure 5 shows the precision, recall, and ( F_1 )-measure with which the adversary could totally deanonymize payments given the estimators ( M_{FS} ) and ( M_{T} ). Of course, as this considers a subset of the correct results of each individual estimator, all measures are lower. However, the results generally follow the same behavior as just discussed. Notably, the timing-based estimator outperforms the end-to-end deanonymization performance of the First-Spy approach in every case of every scenario and in precision, recall, as well as ( F_1 )-measure. It does so in particular in the mcentral scenarios, in which its attack success is reliably higher than the baseline by factor 1.5. Thereby, our simulation results confirm the feasibility and improved adversarial success of timing-based attacks on privacy in payment channel networks.

6 DISCUSSION

In the following, we discuss possible steps towards attack mitigation, the impact of upcoming changes to the Lightning protocol, as well as avenues of future research.

6.1 Possible Countermeasures

The feasibility of timing attacks relies on the possibility to build a reliable model of latencies, and on the adversary’s capability of observing and correlating of suitable interactive multi-hop message exchanges, such as the current update_add_htlc, update_fail_htlc, and update_fulfill_htlc message payloads.

Therefore, in order to impair the retrieval of timing measurements, message replies could be delayed for a random amount of time by the Lightning nodes, along the lines of Bitcoin’s transaction trickling scheme [18] or a timed mix network. However, this would of course significantly delay payment processing and therefore directly conflict with Lightning’s goal of enabling quick payments. It would furthermore counteract recent efforts to reduce end-to-end payment latencies, such as Boomerang proposal [3].

Moreover, the adversary’s capability of correlating payment observations could be impaired, e.g., by introducing a payment scheme that does not leak identifying payment features, such as today’s payment hash, such as anonymous multi-hop locks [30]. Note however, that even given such a scheme, payment observations may still be correlated through metadata analysis, as timing and payment amounts. Furthermore, as an individual node still needs to be able to match incoming and outgoing network messages, such decorrelation would only protect of re-identifying the same payment in the network, i.e., mitigate full deanonymization. Very likely, the individual source or destination estimators could still be applied.

Useful information for enthusiasts:

Contact me via Telegram: @ExploitDarlenePRO