Author: AdamISZ
Source: https://reyify.com/blog/lightning-unchained/
The original article was published in February 2025.
There's a problem with the Lightning Network that's common knowledge among engineers, but users and wallet developers probably haven't considered (maybe they have, and I hope I'm wrong!): Lightning Network users are forced to publicly disclose the UTXOs they use to open channels. Imagine how much better your privacy would be as a user if you didn't have to do that.
The on-chain weaknesses of the Lightning Network
To explain this clearly, I need to digress and introduce an important aspect of how the Lightning Network works. Let's start with something called a short-channel-id .
The " channel short ID " is an 8-byte string that encodes a UTXO. Within the Bitcoin protocol, a UTXO can be represented by a tuple (outpoint, index) , where the "outpoint" is the identifier (txid) of the transaction that created the UTXO, and the "index" is the position of the UTXO within the output of that transaction. While this method avoids ambiguity, it uses 36 bytes (32 + 4; although using 4 bytes to represent an index is somewhat overkill, it's the established practice). We'll see later that the designers of the Lightning Network protocol specifically created a more efficient encoding method (using only 8 bytes, not 36 bytes). If you're wondering why only 8 bytes are needed, consider what you only need to specify to identify a UTXO: a block number (from which it was created), a transaction number (because a block contains an ordered list of transactions), and finally, one of the transaction's outputs. Each of these three integers has a maximum value, so you can use appropriate encoding for each integer (using 3, 3, and 2 bytes respectively).
What's the point of doing this? Let's recall. The "Lightning Network," as I often say, has two parts. The first part is the "Lightning (channel)," meaning a Poon-Dryja-style payment channel between two parties; the second part is the "network," meaning the Hash Time Locked Contracts (HTLCs) enforced across multiple interconnected channels (money channels). This second part—the "network"—is crucial. To construct channels, you need to know these channels exist (and even more difficultly, you must know or guess how much balance is available within these channels, in the direction you need!). For this , you must get someone to tell you they exist. This is why we have the " Lightning Network gossip protocol ," where the vast majority of these messages tell peer nodes: certain channels exist.
So here's the problem: in an environment of mutual distrust, people might lie—I can totally make things up. I've found 10,000 channels, each with a capacity of 1 BTC, here's a complete list, go find them yourself… This could easily waste your time and make your CPU do useless work; and in the end, you might end up with a completely useless map of channels, where every time you try to transfer money in the "network" according to this map, it always fails.
Therefore, we used channel short IDs; as mentioned earlier, it is a compact representation of UTXOs. UTXOs are not free to create. Although creating one is very cheap (when transaction fees within the blockchain are extremely low, it only costs 1 to 2 satoshis/vB to send a transaction and create a UTXO, which is about 10 to 30 cents at today's exchange rate), the cost increases linearly with the number created; moreover, if you want to create 100,000 UTXOs quickly , the cost may even be infinite.
I believe this is a rarely discussed but very important point: Bitcoin's extremely high hash rate naturally slows down the creation rate of UTXOs (the number of UTXO outputs that can be created per second), making the cost of creating UTXOs not only non-linear but also almost singularity-limited – which is exactly the kind of robust DoS protection you need when building public services.
Now we can answer the question: UTXOs need to be encoded compactly because these encodings need to be broadcast. If there are 10,000 or even 100,000 channels, there will be a huge amount of UTXO data that needs to be propagated, and if each one requires 36 bytes, the situation will be much worse than it is now (using short channel IDs).
Details of the problem
The problem can be summed up in one word: privacy. Announcing your UTXO holdings to the entire network is tantamount to announcing it to the whole world—especially when you're sending the announcement via a public, plaintext IPv4/6 network address (many "serious" nodes do this, after all); it's practically inviting spies to analyze your activities within the blockchain. This might not be a business risk, but it's definitely a security risk. This information can be cross-referenced with other information, such as connecting to your IP address, starting to find out who you are, where you live, how much Bitcoin you hold, and so on.
Essentially, this is yet another manifestation of a typical conflict in P2P networks. What is a "typical conflict"? It's quite simple:
In open peer-to-peer networks, protecting resources requires defending against sybil attacks, which conflicts with users' desire for anonymity.
(Translator's note: "Sybil attacks" refers to attackers easily creating multiple identities to deplete the victim's resources; the old translation was a literal "witch attack".)
If there's a "typical solution" to this kind of "typical conflict," from my perspective, it's requiring users to use a scarce resource to participate in peer-to-peer networks. (Another "solution" is to enforce non-anonymity, but this is a fragile method and will eventually fail. — This is my personal opinion, but precisely because it's purely personal, feel free to share it.)
This conflict and resolution also played out in the recent Tor network service outage—the clones consumed a lot of resources, and the solution was proof-of-work. Whether proof-of-work based on computational loops can really solve this problem is something I'll discuss another day, because I want to get back to the Lightning Network gossip issue!
Okay, the short channel ID will directly reveal the UTXO. We already know this is bad. So what can we do? At least we can try this:
I have a channel. I'm prepared to prove that the value of the UTXO I use to open the channel is X Satoshis (or at least X Satoshis), but I have no intention of telling you which channel with that many Satoshis is mine.
This idea is, first of all, very appealing, but it also sounds a bit crazy—if you're not a fan of Zero-Knowledge Proofs (ZKP). Before delving into ZKP, let's solve a rather clever logical problem:
Is it public knowledge whether a UTXO is actually used to open a channel? In the current scenario where P2WSH output is used to open channels, technically, this fact won't be revealed even when closing, despite obvious signs (Lightning Network engineers, please feel free to correct me). As for taproot channels, at least with the development of MuSig2, we can expect or anticipate that channels will never reveal that they are 2-2 multi-signatured, let alone that they are a channel. As a reminder, this discussion is about imposing costs to prevent DoS attacks, so I assert that trying to prove "this is a channel" is a misdirection. Proving UTXO ownership is sufficient.
(Disagree? No problem, let's think about it more carefully. I claim the existence of a channel, and I publish it (or gossip it). To support my claim, I provide a short channel ID; this short channel ID points to a real UTXO within the blockchain, but how do you know that this UTXO actually points to a channel? If I were to lie, I only needed to make this UTXO "look like a channel." As we mentioned earlier, in some cases, all UTXOs can look like channels (using taproot output, the widespread adoption of MuSig2). Even, as an attacker, I could actually create a real channel and then make it completely inoperable without violating protocol requirements. The ultimate meaning of using a short channel ID in a gossip message to "prove a channel" is simply "proving I created a UTXO.")
But we can discuss this in more detail. Who do you want to bear the cost, and what kind of behavior do you want to bear the cost? In this older article, Rusty Russel proposed imposing costs at the node level, rather than at the channel level. Regardless of the technical difficulties involved (which I can say I know almost nothing about), the main reason I agree with this perspective is that decoupling the cost from the resources that benefit you can further improve the actual privacy of each channel (for example, suppose you create a channel with a very large capacity and then immediately publish a zero-knowledge proof to prove its existence, which means "I prove I own a channel with a capacity of at least 2 BTC," but just then a UTXO worth 2.2 BTC appears on-chain; this is just an example, and you should understand what I mean).
But that's not the end of the story: "Is it a UTXO channel or not?" You can find out more in the comments section of this blog.
Okay, I admit it's useful, but is it even possible? With something like ZKP?
So, is it actually possible? In summary, what we need to prove is:
Of the existing UTXOs with denominations within a certain range, one is mine; we can assume it's a taproot channel, but that doesn't restrict the "channel type" (ideally you wouldn't even know its type); however, I won't tell you exactly which one it is.
However, within a reasonable range, there could be hundreds of thousands to tens of millions of UTXOs. Is this even possible? Obviously, it's not that simple.
I've been researching this problem for three years, going back and forth (although, to clarify, I'm not just focusing on the Lightning Network; I'm focusing on generalized privacy-preserving anti-spoofing solutions). Initially, I focused on "ring signatures," realizing that such constructions exist, but the (evidence's) volume is likely O(log N) (in bytes). The problem is that both the verification and computation time of the evidence are O(N). Bulletproofs also have this problem. The only problem is Merkle trees—an insight Andrew Poelstra gave me—where the verification time for Merkle evidence is O(log N); around the same time (2022), "curve trees " emerged, combining the two: you can use bulletproofs to generate compact evidence and then use an algebraic version of a Merkle tree (using a very special secp-secq curve loop) to achieve logarithmic scaling for verification. The practical result is that for a set of 1 million UTXOs, you can verify evidence in 50 to 100 milliseconds (this can be done with my code , and should be even better!), and generate evidence in 1 to 2 seconds, with a size of 2 to 3 kB. Again, this evidence proves " I hold one of these 1 million UTXOs, but I won't tell you exactly which one ." For a more complete version of the same idea, see the FCMP++ project, although that's on the Monero blockchain.
Recently, JT Halseth released output-zero , which is a completely different approach to solving the same problem. It uses a different ZKP, specifically zkSTARKs, instead of Bulletproofs (see risc0 for implementation details), and then uses a Groth16 wrapper to create compact proofs.
If you're interested, I highly recommend checking out the discussions about his projects/ideas on the Delving Bitcoin forum .
My current summary is as follows (not sure if it's accurate): The main advantage of output-zero is that it produces evidence in O(1) order (i.e., constant) (thanks to Groth16), which I recall is around 260 bytes. This is obviously much better than my method (evidence size around 3kB). However, on the other hand, based on my own testing results ( here ) and the author's overview, I don't believe its evidence generation time is acceptable. The author's argument is this: routing nodes are typically equipped with high-performance devices, and, more importantly, proof is not a real-time operation, so even taking a few minutes is acceptable (it seems that GPU acceleration would be much faster, but perhaps I'm too old-fashioned; I don't think this advantage should be taken into account (why?)); as for verification, both ZKP methods take 50 to 200 milliseconds. I suspect that in practice, an evidence generation time exceeding 10 seconds is already somewhat "outdated." Perhaps I'm wrong.
But finally, I want to say that what I find most compelling here is the differing opinions on whether these zero-knowledge proofs should be tied to specific channel UTXOs. If you've read the discussion on the Delving Bitcoin forum above, you'll see that I'm also wavering on this point. I believe that avoiding channel UTXOs would be much better for privacy; however, from another perspective, why would you want to use a UTXO that isn't a channel (you've already injected liquidity into the channel, why not use it)? Furthermore, if you want to use a channel UTXO in ZKP, then you should/must support the idea that the proof is generated from a MuSig2 UTXO. This not only needs to be considered in the design of ZKP (obviously, it's more complicated if the UTXO doesn't have a single owner), but also raises the question: who can/should use this ZKP as a resource credential? Regarding how ZKP would be affected here, consider, for example, the current design of output-zero, which uses...
hash(bitcoin-pubkey-1||bitcoin-pubkey-2)As its "key mirror" (something used to prevent you from reusing the same UTXO over and over again, quite different from the common design: "a key mirror is an irreversible hash of the private key"), I know this is too demanding for most readers, but it's just to demonstrate the uncertainty involved.
(over)
