The Fight for Bitcoin: The Lightning Round

By being detail oriented and preserving the critical properties of Bitcoin, Lightning enables rapid expansion of the network’s usage.

The Fight For Bitcoin, Round Three

“Metadata absolutely tells you everything about somebody’s life. If you have enough metadata you don’t really need content.” – Former NSA General Counsel Stewart Baker

The Lightning Network is becoming synonymous with the future of Bitcoin, and not without reason. If Bitcoin is going to become an open monetary network that can service the world’s economy, it simply is going to need a second layer protocol for pertinently scaling the sound monetary properties to a global medium of exchange without modulating or sacrificing many of the beloved properties innately found in the immutable base layer of Nakamoto consensus. While the United States dollar-denominated purchasing power of a single satoshi can not easily be predicted a decade away, within a relative range, the historic “sat per byte” metric key to valuing the block space fee on a single main chain transaction can show us that if the market cap of bitcoin is to even remotely approach its total addressable market, base layer utilizations are going to eventually price out the average user for daily use transactions. This is not a disaster, nor an unsolvable problem, but if and when the network begins to flex its Metcalfe’s potentiality of exponential growth of unique user addresses, the billions of international participants will not be able to make the multiple purchases a day needed to sustain an economy of such scale at a couple megabytes per ten-minute block. Now before this gets turned into some Bcash-sponsored hit piece, it is crucial to understand why the “big block cartel” lost “The Blocksize War” and why the user-activated soft fork, or UASF, was theorized and enacted by the champions of our ticker in the first place; the sound properties of Bitcoin’s blockchain are useless with the centralizing incentives of expanding block size pricing out the ability for everyday users to run their own nodes and keep pace with the expanding broadband and hard drive requirements of such implementation. This was not a frivolous decision, nor an easy battle, but as we continually find out in this space, the truth of the principles of ideal money will continue to win out over marginalized or compromised competitors as long as Bitcoin users equip themselves with decentralizing principles met with healthy skepticism and sound discourse over how best to deploy them.

The mass-adoption-ready second layer scaling solution to the necessary and prudent economic incentives of a small block base layer is looking more and more everyday like the Lightning Network; in fact as this is being written, CashApp has just integrated Lightning interoperability into its platform. One of the main assumptions about Lightning is that it is by default simply more private than a main chain transaction by nature of it being an encrypted transaction between two parties, versus an open ledger transaction anyone with a block explorer can see on the blockchain. While in many ways this is true, the assumed default anonymity and private nature of a Lightning transaction is misleading and should be discussed in an intellectually honest manner in order to encourage good practice and solutions in the network’s infancy. In order for Lightning to onboard the billions of users of the future, batching solutions for funding channels on the main chain are going to have to be utilized. This has become exceptionally more possibly private and structurally capable due to the multi-signature capabilities now available from the successful soft fork known as Taproot, but with poor unspent transaction management and industry-wide ubiquitous know-your-customer legislation, there are plenty of ways to expose your identity as you open channels. Again, if Bitcoin is to become a cash-like technological monetary network in countries with less favorable financial freedom laws, it is important we do not allow adversarial entities to control or centralize the onramps and routing infrastructures of this scaling solution, be it via third party custodial solutions or compromised routing nodes and global network flow analysis. There are many advocates for not using centralized, KYC exchanges, as well as prominent promoters of principles of self-custody in the Bitcoin ecosystem, but there is not a lot of discussion in the Lightning Network space about proper techniques for privacy, nor healthy discourse about potential centralizing issues that could come to fruition if we keep on this path. In a Lightning transaction, there are two potential adversaries one must account for: global network eavesdroppers and intermediary adversary nodes. A global network eavesdropper is any entity that can see and analyze traffic on the internet. This includes telecommunication and internet service providers, internet exchanges, chain analysis companies, autonomous systems, national intelligence agencies, and groups running deep packet inspection boxes for flow analysis. These types of bad actors can “only” see encrypted traffic between all nodes; metadata such as to, from, path length and time. These are found from synching to network flow and are not capable of seeing actual content of transactions or messages. The second type of noteworthy entity is intermediary adversary nodes which are compromised pieces of the routing path. While they can not technically see the original sender or final receiver of the payment due to the onion-esque layering of encrypted packets, they can witness the predecessor node, successor node, payment identifiers, payment amounts (sub fees), and time sent. The main issue of compromised anonymity sets comes from a combination of these two attack vectors by an adversarial entity to create a fairly reasonable assumption of possible originating and final payment nodes, as well as the amount sent and how it was routed. Before one can hypothesize potential solutions, it helps to understand how this is done.

The general assumption of anonymity principles on Lightning Network is that, due to the use of onion routing to create data packets, the intermediary does not know the full length of the payment route nor its position in the path. The predecessor may or may not be the originating sender, and the successor may or may not be the final recipient. Hence the aforementioned assumption that unlike a main chain bitcoin transaction, which is recorded on a public ledger, the Lightning Network is a private transaction routed anonymously. But this anonymity is weak due to payment route captures and repeating transactional behavior leading to predecessor attacks. How this works, is that in order for all participants to know the length of paths and economic costs of all paths, in order to optimize for the most effective routes, the full graph of the network needs to be always known to all users. These paths are not chosen in an entropic, randomized manner, but again, optimized to find the most effective routes determined by shortest path and cheapest cost. A compromised adversarial routing node that has total viewership of the network graph can see which peers that the node sending information to it is connected to, and thus can deduce by probabilistic reduction of possible paths by elimination, factoring in cost and length of routing paths to find out who is and who is not initially propagating the payment. Payments would be hidden by the encryption of the Sphinx protocol, but a corrupted node can trivially observe they are sending a message without having received one previously, with the faster the propagation leading to more traceable metadata enabling easier end-to-end route tracing. Slower propagation, while worse for transaction speed, actually makes it harder to identify which message corresponds to which route. By eliminating redundant and inefficient propagations and path payments, compromised nodes can determine relatively easily who is or is not a candidate for originating a transaction. The same goes for being the end receiver of a payment; you would not route an inefficient payment through a node unnecessarily, and thus again, you can determine the cheapest, shortest route via analyzing the visible network graph, and find who ends the payment route by eliminating the longer, costlier paths from the small set of potential receiving nodes. If an adversary controls two routing nodes in the path, they can determine the full path of the route and know who is originating and receiving the payment, plus the near exact amount of the payment. Ironically, private channels make this easier, because if the channel is only known by one person, then that has to be the originator because no one else can publicly view it and thus no one else can use it for routing. An adversarial routing node is still able to see nodes having transactional throughput despite a gap in the public graph, ergo demonstrating a private channel and peer exists, and thus can complete and fill in their own analysis of the channel route. The nodes that are “unconnected” are still executing and broadcasting a traffic fingerprint that is consistent with making a payment. Even with better encryption techniques, non-adjacent nodes can still infer they are part of a payment route based on the specific amount sent, and the timing, again, especially if the propagation is fast. At best, this gives plausible deniability, due to the chance of a handful of potential routes if there are more than one shortest and cheapest paths the payment could have taken. Uncertainty over identifying predecessors and successors only works if you have long, random walks for payment routing, and not the general, common use of shortest and cheapest routes.

The likelihood of loads of adversarial nodes being on the network is perhaps trivial, but to ignore an attack vector is naive and dangerous in the grand scheme of Lightning Network’s potentiality. In a lecture given by Claudia Diaz at the Lightning Conference in 2019, a few possible options to combat these vectors were given. The ideal is to construct and use an anonymous transport layer giving true unlinkability between anonymous channels. A network like Tor is unfortunately not resistant to global network adversaries, and end-to-end correlation attacks are still quite possible due to neither delaying the timing of relaying messages, nor packaging messages to hide metadata. Tor has been notably susceptible to packet counting attacks in the past, and the utilization of dummy traffic to eliminate the attack vector of timing correlations is a potential solution to this tangible issue. Using mixed nets that are packet-based instead of circuit-based, with continuous time mixes and delayed propagation can create predictable latency which can lead to much larger anonymity sets. Rather than the circuit-based topology we use now, a layered topology with loops of dummy traffic can lead to un-observability properties and anonymity sets in the hundreds or even thousands; much preferred to the handful of plausible routing nodes with the infrastructure utilized now. This type of infrastructure can support multiple applications beyond the Lightning Network, and by blending packets from user bases of state chains, Chaumian chains, and even VPN or messenger applications in the loops of predictable, homogeneous dummy traffic, an even larger anonymity set can be created which will allow near-impossible routing analysis of payments, including tangible metadata protection when using private channels. In this scenario, a global network adversary could only see there were packets and traffic sent and received by a specific node, but not to who or where they were sent or received.

This structure does have some tradeoffs of course, including needing higher bandwidth due to the volume of packets needed for useful dummy traffic and helpful transactional propagation latency. This solves a lot of the issues brought up by global network adversaries, but unfortunately, the problems with adverse intermediaries are harder to solve for; the inherent lack of entropy in Lightning Network routes optimizing for the economic choices of shorter paths and cheaper routing fees when long, random walks are needed for greater anonymity sets. The current implementation of source routing, described above, has many privacy issues that can be solved with eventual utilization of creative techniques like route blinding, or Rendezvous routing. The clunky block requirements of hash time locked contracts (HTLCs) can be replaced with PTLCs, or point time locked contracts, which use Schnorr signatures to not only save block space but increase practical privacy and thus anonymity sets. The Lightning Network is a brilliant protocol, and has a big story yet to play in the development and success of Bitcoin as a human rights achievement, but only by being critical and skeptical of attack vectors can we successfully preserve the necessary privacy features and not hand our ruling class the complete transactional history of the world’s population on a silver platter.

This is a guest post by Mark Goodwin. Opinions expressed are entirely their own and do not necessarily reflect those of BTC, Inc. or Bitcoin Magazine.