Here’s a risky myth pervading the Bitcoin community: The Lightning Network model will inherently improve Bitcoin privacy.

Off-chain transaction techniques move some transaction data from the indefinitely public blockchain record to other places. By this virtue, advocates conclude this will make sensitive data harder for privacy attackers to gather.

Unfortunately, we do not have the information we need to support these claims:

Lightning networks have never been deployed in production. As someone who has studied Bitcoin and security and privacy for a few years, I can attest many initial assumptions about what will be good for users turns out to be wrong once software is deployed and matures. Specifications for Lightning are still in draft form, and will continue to evolve rapidly over the next several years. This presents a moving target for analysis, though this will undoubtedly ossify over time. As the privacy of Lightning will likely initially revolve around routing algorithms and network topology (See #4 below), the Tor project might be a reasonable analogue. Tor took years of academic analysis, security engineering, and adjustments for experts to understand its threat model and to pluck the low-hanging privacy fruit it has to offer. In order to evaluate positive claims about a technology’s privacy, you need a threat model. A threat model reveals our assumptions about users’ privacy concerns and allows us to compare apples to apples rather than bananas to space dolphins. No such formal model exists yet, though I hope future work will build off of the OBPP’s Bitcoin privacy threat modeling work. By moving transaction data from a public blockchain to a new network of Lightning nodes, much of the privacy properties will depend on the topology of these networks. If the networks end up routing much traffic through a small number of hubs or spokes, privacy protection will be more difficult. Unfortunately, we can’t know this topology in advance, as there are many different kinds of incentives (security, economic, efficiency, etc.) in play that will determine these topologies in the future. There are a variety of predictions today. While dozens of academic papers have studied the privacy of transactions on blockchains, the privacy of Lightning networks is comparatively under-studied. The privacy of evolving systems will be relative to consumer demand. Suppose Lightning helps us onboard 10x the current number of Bitcoin users who care more about low transaction fees and high transaction speeds, and not so much about privacy. Will the companies developing Lightning networks continue to allocate R&D funds into privacy improvements? Maybe not. I hope this isn’t the case as it will likely lead to consumer regret in the future once the data toxicity of now-ossified protocols becomes evident, but it would be consistent with our observations of weak demand for privacy in Bitcoin to date and digital privacy as a whole.

Although we don’t know exactly when we’ll achieve parity of understanding between Bitcoin privacy and Lightning network privacy, we can speculate about the best- and worst-case scenarios.

Best-case scenario for Lightning networks: Nodes become widely used, cheap to operate, and evenly distributed. Early attempts to protect routing privacy prove robust, and the cost of information attacks which are currently cheap for blockchain-based attackers soars. Privacy attackers and financial censors struggle to catch up to this new development.

Worst-case scenario for Lightning networks: Lightning networks become widely used due to the high cost and slowness of on-chain transactions resulting from today’s Bitcoin protocol decisions. Routing nodes are expensive to operate. The topology of the network devolves into simple hub-based networks. Protocol-level attempts to protect routing privacy prove inexpensive to overcome by attackers due to the small number of hubs that can correlate transactions. Users have poor access to information on how much of their privacy is lost, since it is no longer made transparent due to common access to blockchain data. Privacy attackers thrive on the model of operating hubs or vampirically feeding off of hubs’ data, and financial censors win a crucial battle against Bitcoin users.

References:

Lightning Spec RFC, various authors (6be58570…) https://github.com/lightningnetwork/lightning-rfc/tree/6be5857021446ac9550feed3dc83a7ad2f71bda2

Security improvements in Tor, Wikipedia https://en.wikipedia.org/wiki/Tor_%28anonymity_network%29#Improved_security

Weaknesses in Tor, Wikipedia https://en.wikipedia.org/wiki/Tor_%28anonymity_network%29#Weaknesses

OBPP Wallet Ratings project, various authors https://github.com/OpenBitcoinPrivacyProject/wallet-ratings

Peak Indifference, Cory Doctorow http://www.locusmag.com/Perspectives/2016/07/cory-doctorow-peak-indifference/

The #Bitcoin #Lightning Spec Part 5/8: Onion Routing Protocol, Rusty Russell https://medium.com/@rusty_lightning/the-bitcoin-lightning-spec-part-5-8-onion-routing-protocol-86c91e455909

This article incorporates early review feedback from Daniel Cousens and others. Errors herein are the sole fault of the author.