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.
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.
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.
Conclusion
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.
Acknowledgements:
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.
