Privacy In Lightning Network
The Lightning Network makes Bitcoin transactions as fast and cheap as possible, using off-chain transactions powered currently by HTLCs (Hash Time Lock Contracts).
Lightning also offers more privacy compared to Bitcoin where every transaction is broadcast on-chain before it can be confirmed.
Lightning transactions are sent locally across payment channels.
How Lightning Offers More Privacy Than Bitcoin
Lightning provides better privacy than Bitcoin because Lightning payments are not broadcast to the whole network; only nodes involved in the payment will be aware of it. Unlike using Bitcoin where you have to broadcast every transaction to the network and the transaction has to get confirmed before the recipient can receive their payments.
Bitcoin transactions include the address of the receiver and the UTXOs of the sender for all to see. Although the Bitcoin network does not associate real-world identities with Bitcoin addresses, multiple companies have been established to de-anonymize users of Bitcoin by monitoring addresses on-chain.
While the concept of not broadcasting Lightning payments helps improve Lightning baseline privacy, there are other privacy concerns in the Lightning Network which I will write about in this article.
Privacy Concerns In Lightning Network
I very much enjoyed reading Anthony Ronning’s write-up on privacy in the Lightning Network (link), so I decided to summarize the points I found most important and add my thoughts to them
These are some privacy concerns on the Lightning Network :
- Tracing heuristic
- Balance probing
- Node alias
- Private channels
- Receivers privacy
- Closing of payment channels
Tracing Heuristic
Lightning users can be traced and de-anonymized both with their IP addresses and UTXOs of their public channels.
Tracing a node user with IP address: When a user wants to connect to another node on the Lightning Network, the node accepting the connection has to reveal its IP address. The IP address can easily reveal the node owner’s identity. An easy way to fix this is to set up the Lightning node to be Tor only but this also comes with a caveat: nodes set up to be Tor only cannot accept incoming connections from non-Tor nodes, but they can connect to all types of other nodes. Users can also use static IP VPNs to protect their server IP.
Tracing a public node user with their UTXOs: To open a payment channel a 2-of-2 multisig transaction is created which locks one or more UTXOs. Then the transaction will be broadcasted on-chain, and the payment channel will open when the funding transaction is confirmed. The information about the channel will be distributed to the network if it’s a public channel. This information includes the channel point which is a combination of the transaction ID and output index with this info using chain analysis the source of funds for the payment channel can be revealed which may lead to the de-anonymization of the channel creator.
Balance Probing
Although the balance of two nodes with a payment channel is not gossiped on the Lightning network, with knowledge of the gossiped channel capacity an attacker can route multiple failed payments to gain an idea of the balance of each node in the channel.
Node Alias
A node alias can be set up for a Lightning node which is a nice feature for readability, but it can also be a privacy leak. If the node owner makes use of an alias that is related to their real-life identity it can be used to reveal their identity. Node users can easily avoid this by using pseudonyms as their node aliases but it’s advisable to use a descriptive alias if the user is running a service or business off the node.
Private Channels
Private channels in the Lightning network are really unannounced channels. Private payment channels are simply channels that are not announced to the network after creation and therefore after channel creation, only the private channel partners will include the channel in their network graph, used for pathfinding. When receiving payments the channel’s privacy can be blown away because the channel ID is part of the information passed in payment invoices and the channel ID can be linked to the UTXO used in creating the channel. If such info gets into the hands of a malicious sender it can be used to help de-anonymize the user.
If a user wants to remain private on the Lighting Network it’s advised they only send payments, and not share payment invoices.
Receivers Privacy
Receivers do not have the same privacy as senders on the Lightning Network. They need to give out certain information to the sender for receiving payment, and the information given can de-anonymize the receiver.
Closing Of Payment Channels
When closing a Lightning payment channel, the closing transaction will be sent on-chain which spends the opening/funding transaction. Chain analytics could be used on these two transactions to gain information on both channel peers. It becomes easier to identify a Lightning closing transaction on-chain when the channel is forced closed because force closed channels may reveal unresolved outputs on-chain that are specific to Lightning. If the transaction is analyzed the receivers of the change output will be figured out from there the channel users could be traced.
A solution for this is mixing the change UTXO after a channel is closed.
Improvement Proposals for Privacy
- Taproot: When a 2–of-2 multisig transaction is seen on-chain one can almost conclude it is a Lightning transaction because 90% of the 2–of-2 multisig transactions on the Bitcoin network are Lightning transactions. But with Taproot it will be difficult to predict because Taproot’s single and multi-signature spends appear identical when using the key path spend.
- PTLC: The arrival of Taproot also made it possible to make an improvement for HTLC which is PTLC. Unlike HTLCs which are locked using a hash digest and unlocked by providing the corresponding preimage, PTLCs are locked using a public key (a point on Bitcoin’s elliptic curve) and unlocked by providing a corresponding signature. Each point lock can use different keys and signatures. PTLC offers more security compared to HTLCs which use a static payment hash. The payment hash is sent from the recipient to the sender, and it’s this hash that is across nodes on the payment route to represent the payment. After successful payment to the recipient, if payment is made to the invoice again any of the nodes on the route can easily claim the funds because they have the payment hash and preimage, but PTLC comes with a handy feature of being able to randomize its identifier with each hop thereby making it impossible to carry out this attack.
- Rendezvous Routing: Rendezvous routing improves receivers’ privacy. Receivers will conceal their public key and private channels by creating an invoice with encrypted onion information already filled in by them then they will specify a random node that the sender should create a path to, and the rest of the payment is routed from there. The sender (and other nodes along the route) won’t know the final destination node which is a key component missing in today’s lightning network
- Public Key Routing: Public key routing is a simple way to conceal the UTXO making up a channel. While it would still be possible to detect a private channel between two peers that do not have a public channel between each other, it would hide the UTXO behind it.
Conclusion
While the use of encryption, onion routing, and invoices in oppose to Bitcoin’s static addresses makes Lightning's privacy offer better there are still some loopholes that can be exploited, while many researchers and developers are looking into network-wide improvements, participants on the network need to understand what they can do to protect their privacy and that of their nodes.
If you are an African developer and you are interested in transitioning into Bitcoin development, the Qala program is perfect for you register for the Qala Africa Bitcoin program
Thank you.
