Crypto News Updates

What We Can Learn About Lightning From #LNTrustChain2: Part 2

In Part 1 of this two-part series, we focused on an introduction to blockchain analysis of publicly available Lightning Network payment requests or “invoices” that were made during the second Lightning Torch relay event that took place in January 2020. We looked at analyzing the use of both custodial and noncustodial mobile wallets. 

In this installment, I’ll examine possible scenarios where privacy may be compromised and ways to mitigate the risk when running a private node instance. This article will also bring attention to new techniques of transacting on the Lightning Network, including Multi-Path Payment and Key Send, and the reason these are especially important for Lightning Network reliability.

Private Node Setup

Under the “private” wallets I classified every other node that is being run, from eclair through c-lightning, lnd, or even electrum on the backend, and run in any possible scenario of being a plug-and-play solution, VPS-hosted, or a hacky project on one’s laptop or single board computer. In terms of self-custody, using a private node setup is the go-to option recommended by early adopters.
I would argue with the hardcore opinion that everyone should run their own Lightning Network node, at least as long as default solutions lead newer and less-savvy users to deanonymize themselves inadvertently. As long as these newcomers aren’t aware of all the pitfalls and downsides of their actions, they can inflict some harm on themselves. 

Most plug-and-play nodes allow for Tor connections, and many users are taking advantage of this opportunity with open arms. Only a third of the 51 private nodes (online during the sampling) were set up using clearnet, with the majority running over Tor. That’s great news, as posting invoices by these users won’t deanonymize their location.

What We Can Learn About Lightning From #LNTrustChain2: Part 2

The second big problem of in-home solutions is the need to back up channel states. Even on a default noncustodial setup of either LND or c-lightning, one would have to use some custom script in order to export the channel state after every state change. In case of disaster, the backup file with the latest state would have to be exported to another machine and be perfectly into cloud/distributed storage. If the channel state turns out to be different (older) than the one negotiated with a peer, it would result in punishing the user by taking all of one’s funds (via a penalty transaction). 

Actually, LND has an even better solution: A Static Channel Backup (SCB) doesn’t require saving the last state. Instead, it saves the channel information, so after rebooting the node on a different machine, it is still possible to inform peer nodes that they need to close the common channels with their last state. Peers would then use the latest state in order to avoid the risk of losing funds in a penalty transaction. 

A third option involves the use of watchtowers, special nodes that store information about channel history. In case of any downtime during the operation of one’s node, a watchtower would stand guard and (in some cases) prevent cheating during the channel-closing stage.

However, these aforementioned backup scenarios are complicated to implement and none are currently part of a default LND/c-lightning node setup. So, even if a power user crosses the hurdle of channel backups and obfuscates their IP address, they would next have to try finding the holy grail: address obscurity. 

What We Can Learn About Lightning From #LNTrustChain2: Part 2
Jonas Nick, Blockstream engineer, on Twitter

There are voices saying that the Lightning Network is a privacy solution disguised as a payment protocol, but it relates to the activity inside the network. 

One of the biggest problems with Lightning Network users deanonymizing themselves relates to the action of opening outbound channels. Every public Lightning Network channel starts with creating a bitcoin commitment transaction, and when we speak about transactions, there is a place for blockchain analytics. 

Addresses in one’s “keychain” of wallets can be deanonymized by multiple heuristics with common input clustering as the lowest-hanging fruit. One way of breaking these heuristics is to perform a CoinJoin on the funds purposed for opening channels. Opening public channels using mixed coins is a good on-chain solution and requires prior action (using a CoinJoin service), but there is also another solution —opening private channels. 

Just as in the case of noncustodial mobile wallets, one can open a private channel to a reputable peer so the outbound liquidity is always hidden to the rest of the network. As in the case of Breez and Acinq (Phoenix) nodes, the channels are visible to them. The same option applies in dealing with any other peer when opening private channels, so the safest solution is to do CoinJoin mixing followed by opening private outbound channels.

It’s Not All That Terrible! 

While some members of the Lightning community deanonymized their location and bitcoin wallets in connection with their public Twitter profiles, there were others who used CoinJoin and/or private channels setup. That’s why I find it important to, once in a while, gather research and comment on the privacy outcomes of specific actions. 

There were also members who used the new features of the Lightning Network, specifically multipath payments and key send. These users are standing at the forefront of Bitcoin/Lightning adoption, testing new frontiers of this emerging technology. 

Multi-Path Payment (MPP) or Atomic Multi-Path Payment (AMP) is a feature especially interesting from a point of invoice receiver, who may not have one inbound channel with enough liquidity to make a payment. MPP helps by allowing the use of multiple channels and routes to accommodate for the whole payment amount. This is an amazing development and a fact that will silence many Lightning Network critics and their argument of limitations in payment volume related to the smallest channel in the route. 

As this change rolled out for c-lightning, Acinq and LND just before the second iteration of the LN Torch, there was the possibility of it being used by members of the relay. AMP is a part of the routing process, so just from the invoice reading, there is no way to guess, but remembering last year’s struggle with invoices being too big for payments and the need to split them into smaller chunks manually, this year’s process was much smoother. This improvement is likely due to better LN infrastructure with balanced channels; the use of the AMP feature being used; and the fact that many of the torch bearer nodes (at least one-third) had the “MPP” feature open. 

Key send is a type of spontaneous payment where there is no need for an invoice. Instead, the payee has to share the node’s public key to the sender; then the sending party can initiate the payments without the constraints of a standard invoice. It has many pros, like the ability to send recurring payments without the need to ask for an invoice, thereby mitigating expiration time of an invoice, or being able to specify the amount on the sender side. As of LND version 0.9.0-beta, it’s still an experimental feature, but it was used by two members of the #LNTrustchain2 to receive the torch.


Creating experiments like #LNTrustchain2 is an excellent way to obtain representative samples of Lightning Network activity, giving us a window into its future. It allows us to quantify the data, test features (key send/MPP) and also allows for Lightning Network fans to connect. 

The part of these research results that struck me the most was related to the high-percentage use of custodial services. As the Lightning Network grows both technically and in terms of awareness and education, custodial wallets will have a hard time competing with the new waves of native Lightning wallets which don’t sacrifice usability for self-custody, like Phoenix or Breez. 

I was positively surprised by the result of two-thirds of private node instances being interconnected not through clearnet, but by Tor. This is a very uplifting result when it comes to privacy and some aspects of censorship resistance (related to possible MiTM attacks). After all, we can’t forget that many blockchain analytic companies are also closely looking at the state of the Lightning Network and they will hone in on any privacy-leaking possibilities to add to their profit models. 

Looking back from today’s perspective at the first time Hodlonaut launched the relay in 2019, the Lightning Network’s progress in terms of both privacy and UI is tremendous — and it appears ready to move beyond its reputation of being available only to technical users. 


The author would like to thank Jarret Dyrbye for his helpful comments on the article and dataset gathered. All the data and results gathered are a part of blockchain analysis where the end result is probabilistic and relates to a type of analysis performed on the source.

The post What We Can Learn About Lightning From #LNTrustChain2: Part 2 appeared first on Bitcoin Magazine.

Source: Bitcoin magazine

Crypto News Updates

What We Can Learn About Lightning From #LNTrustChain2: Part 1

The first Lightning Network “torch relay” debuted on January 19, 2019, to spread adoption of second-layer Bitcoin payment protocol. When it concluded in April 2019, it boasted 278 participants and 56 countries visited. One year later, Hodlonaut, the person behind the torch inception started the relay again, on January 19, 2020. After a few days, however, it was obvious that the new iteration of the torch was different, starting with a high rate of torches being stolen and ending with the chain being “cancelled” by sending the amount through to an oblivious Jack Dorsey, CEO of Twitter, who had willingly taken the torch in its 2019 edition. 

Because of the way the chain was propagated through Twitter posts, the path of the Lightning Network “Trust Chain” (#LNTrustchain2) is somewhat easy to follow, and the data about specific payment requests (invoices) is available publicly. It can, therefore, provide us with a lot of insight into consumer-related aspects of Lightning Network adoption. Which client agents are being used the most often? Which mobile wallet services? Are custodial wallets prevailing? 

Following #LNTrustchain2 provides a perfect opportunity to measure the adoption of the Lightning Network. What other event on this global scale has users from all around the world, from mixed professions, from bitcoin plebs to CEOs, with all of their payment requests openly posted on Twitter? 

As a blockchain analyst, I was motivated by professional curiosity and an internal urge to spread knowledge about the anonymity aspects of Bitcoin and the Lightning Network. Several examples provided in this article have been selected specifically to expand public knowledge about the privacy deficiencies of particular solutions.

In Part 1 of this series, I’ll cover an overview of the data I gathered and will explain the methodology of acquiring the dataset. I will then focus on mobile wallets, mostly examining custodial services, but also showing the potential of a new evolution of wallets, including Phoenix and Breez. 

Some Notes on Methodology

I started my research by gathering all the participants and their respective payment requests or “invoices.” Out of 159 participants, there were 19 who either transacted on DMs or have since deleted the payment request, so those payment requests weren’t visible for them. That’s good for their privacy, as researchers (like myself) aren’t able to dissect their data.

Every Lightning Network payment request has the field “node_id” which points to the owner’s node. Why is this important? For now, let’s consider private node setups, either on some sort of virtual private server (VPS) or through a home environment, mostly in the form of plug-and-play nodes (CASA, Nodl), Raspberry Pi nodes or desktop nodes (Zap). 

If the user’s setup isn’t running through Tor (The Onion Router), just the act of publishing the invoice publicly can provide a means for an adversarial entity to know the IP address of a node. No matter if TOR is active or not, an attacker can also use the node ID to collect all the public channels opened by the node owner and, obviously, corresponding bitcoin addresses. With the blockchain analytic tools like common input clustering, even a single public invoice can make one’s full wallet balance visible to an adversary. 


By taking all 140 publicly visible invoices of the TrustChain2, I was able to draw a doughnut chart of all wallet providers. At least 56 percent of all wallets were used on mobile phones; 48.2 percent of total wallets were custodial, related to the use of either Bluewallet, Wallet of Satoshi or Dropbit. Private nodes accounted for 44 percent of total wallets used through different providers, like eclair mobile, or through some personal Lightning Network nodes (lnd or c-lightning on the backend). 

Custodial Services: There Is a Method to This Madness! 

Andreas Antonopoulos famously says, “Not your keys, not your bitcoin.” Similarly, for the Lightning Network, the adage would be “Not your node, not your sats.” When it comes to bitcoin, in 2020, even the worst bitcoin wallets give users the opportunity to back up their wallet seeds. It’s important in terms of the ownership of the coins. For example, if a centralized wallet provider goes down, one’s keys and bitcoin would follow. 

The same goes for the Lightning Network. The vast majority of the wallets used in the 2020 torch relay were either related to Wallet of Satoshi, Bluewallet or Dropbit — all custodial services. By decoding the invoices, we would get the receiver’s node ID as owned by one of these three software providers. 

Custodial Lightning Network wallets are using their own node infrastructure to allow their users to interact on the Lightning Network layer (and usually are noncustodial on bitcoin on-chain side). The whole wallet user interface (UI) is just a layer on top of their centralized SQL database processing Lightning Network payments. I would compare using these wallets to writing I Owe You (IOU) statements in the balance book, kept by the wallet provider. Every custodial wallet fully manages its own node infrastructure (usually single node), so all the LN-related actions: opening/closing channels, requesting payments, sending payments are done on behalf of the users. Knowing the ID of the node (seen in the payment request) can point us to the wallet provider (Wallet of Satoshi, Bluewallet or Dropbit). 

What would happen if their nodes were compromised or if their service stopped working? The outcome is easy to predict — the loss of the funds for their customers. (Dropbit app has already fallen on hard times at the time of writing.)

Using custodial services does have some perks, although they some of them can be also achieved in a noncustodial setup (through private channels). These perks are related to unidentifiable channels and location data. Because custodial wallets use their own nodes for all the users, these users don’t have to worry about protecting their IP addresses or be scared of mistakenly deanonymizing their bitcoin holdings. 

Luckily, custodial services don’t have to be the answer to these concerns. With the new features constantly added to Lightning Network protocol (BOLTs), the new breed of Lightning Network wallets emerged.

Noncustodial Mobile Wallets: Anonymous and Secure

The perfect scenario for running a personal Lightning Network mobile wallet would include having a built-in node with private channels opened to the wallet provider’s node. The first part, having your own node on a device, is a crucial component of being self-custodial. Even if any of the neighborhood nodes (with emphasis on the wallet provider’s node) should go down, the node owner could return the funds locked in the payment channel through the force closing this channel. That’s the suggested solution for closing channels where parties either disagree on their states or where one of the parties goes offline. 

What about deanonymizing the bitcoin addresses of a node owner? Both Breez wallet and Phoenix provide a “tricky” feature of allowing their users to create channels only to nodes. And these aren’t just “normal” Lightning Network payment channels — these are “private” channels. They aren’t being “gossiped” by the Lightning Network protocols; in layman’s terms, their existence isn’t announced to the rest of the network. Even the activity on the bitcoin layer related to publishing commitment transactions isn’t conclusive, leaving potential adversaries in doubt as to what commitment transactions have taken place. 

The core of this feature can be better explained by imagining Alice, the user of Breez or Phoenix. Alice wants to receive the torch payment, so she posts her payment request (invoice) under a previous tweet. Bob sees her invoice and decides to send her the torch. Decoding the request, he sees Alice’s node ID and additional payload, called “routing hints,” with the wallet provider’s respective node ID. The action of sending the payment would route the funds through the wallet provider’s node, which is a one-hop neighbor of Alice’s node and knows the private path. 

What would happen if we were to search Alice’s node by ID in any Lightning Network explorer? The result wouldn’t exist, as her node isn’t visible to the rest of the network.

So far, we’ve explored the data gathered from #LNTrustchain2 movement and we’ve described the motivation behind the research. There was a line drawn between custodial and noncustodial Lightning wallets, with a reasoning why specific ways of accessing Lightning Network infrastructure may be dangerous. 

In Part 2, we’ll look at the privacy of private node instances and conclude the series with advice on how to take steps in preserving anonymity when using the Lightning Network.


The author would like to thank Jarret Dyrbye for his helpful comments on the article and dataset gathered. All the data and results gathered are a part of blockchain analysis where the end result is probabilistic and relates to a type of analysis performed on the source.

This is an op ed contribution by Tony Sanak. Views expressed are his own and do not necessarily reflect those of Bitcoin Magazine or BTC Inc.

The post What We Can Learn About Lightning From #LNTrustChain2: Part 1 appeared first on Bitcoin Magazine.

Source: Bitcoin magazine