Improving The Privacy Of The Lightning Network’s Gossip Protocol

Currently, the gossip protocol introduces privacy leaks and concerns that could be remedied while condensing the amount of messages sent.

This is an opinion editorial by Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.

The Lightning protocol works by atomically updating payments across multiple payment channels in such a way that everything confirms or fails all together — i.e., it routes payments across multiple hops. An integral part of any routing-based system is a routing table, a collection of all the information necessary to actually construct a path from point A to point B. Without this information, you can’t really route anything anywhere because you don’t know how to get the information from where it is to where you want it to go. Lightning obviously requires a routing table, which is what the gossip protocol specified in BOLT 7 accomplishes; the propagation and maintenance of the record of channels available on the network to route payments through.

This gossip protocol is one of the scaling concerns of the entire Lightning protocol stack. Currently, it is very basic and works in a way that is quite similar to the propagation of transactions on the Bitcoin network proper; nodes on the network receive a gossip message, they then verify the message according to the rules of validity, and pass it on to all of their peers to further propagate across the network. It is a naive flood fill protocol that assumes that valid messages will eventually propagate across the entire network.

Because of this, there is a concern of denial-of-service attacks (spam) that will wind up consuming a large amount of processing resources and bandwidth to deal with. In the case of the main Bitcoin network, nodes will not relay invalid transactions, so to broadcast something that consumes nodes’ bandwidth and computational resources requires you to actually have bitcoin to create a transaction with. In the case of the Lightning gossip protocol, you are required to prove you control a valid UTXO funding a channel in order to relay a gossip message about the channel. This performs the same spam protection function as on the main Bitcoin network; you cannot spam messages across the network without actually controlling bitcoin.

This brings me to the actual structure of the gossip protocol. This will by no means be a comprehensive breakdown of the protocol, but a deep enough glance into it to look at a proposed change and assess the trade-offs between the proposal and current protocol. There are three main messages currently in the gossip protocol. The channel_announcement message, node_announcement message and channel_update message. There is also an announcement_signatures message, but this is only used with direct channel peers to sign messages announcing channels, and it is not widely broadcast across the entire network. I’m not going to cover the messages for requesting data, as they are not really relevant to the point of this article.

The channel_announcement message is the first thing required in order to announce a channel to the network and then to announce your node to the public as well. It is collaboratively constructed and requires both channel partners to make and broadcast. This message includes proof that the funding transaction to a channel pays into the channel multisig address, and then it includes signatures from the Lightning node identity key of both participants over the message. It declares which multisig key is owned by which node and includes signatures from each multisig key of the on-chain UTXO funding the channel. This proves that both nodes involved in a channel have control of the on-chain multisig, and then it proves that their Lightning node identity key is associated with it.

Next up is the node_announcement message. If a node attempts to relay this message without having previously sent a channel_announcement message for a valid channel, it is ignored and not relayed. Nodes relay this message by themselves after opening their first public channel to allow other nodes to connect to them. This message contains a signature from the node identity key on the message; some feature bits for future version updates, the network address the node can be reached at to open channels with, an alias (nickname) and a few other bits of info.

Lastly, the channel_update message. This message is also made and broadcast unilaterally by a single node. It contains the minimum and maximum value hashed timelock contracts (HTLCs) a channel will route; the fee that the operator will charge for routing through that channel (base fee and percentage fee rate); and the length of timelock difference it requires between itself and the previous hop, so that it has time to find a transaction settling on-chain and enforce the proper outcome for itself if necessary. It is also signed like all other messages.

So the protocol as it is now provides all the information necessary to find channels you can route payments through, advertise the information necessary to know what fees each channel will charge, and provides a denial-of-service protection mechanism to prevent the Lightning Network from being spammed all day with nonsense advertisements of channels that don’t exist by requiring signatures from the keys holding the funding UTXO on-chain.

But it has one major problem: a total lack of privacy. In order to advertise your channel on the network for people to route payments through, you have to dox the exact UTXO used to fund that channel and associate it with your Lightning node’s identity key. So what can we do to fix this?

Rusty Russell from Blockstream proposed an updated version of the gossip protocol in February 2022. It would take the core protocol from three messages down to two and drastically improve the privacy properties as a consequence.

Effectively what would happen is to completely remove the channel_announcement message and leave the protocol with node_announcement_v2 and a channel_update_v2 message. Instead of doxxing each individual UTXO associated with a channel, and requiring a channel_announcement first, the node_announcement_v2 could be done initially and prove control over a UTXO not actually used to fund a channel. The node operator would then be allowed to advertise channels reflecting some multiple of that amount (so say you have 1 BTC you proved control over, you can now advertise 10 BTC of routing capacity), without having to dox the actual channel UTXOs.

This would be a massive privacy improvement for the network by not requiring each channel to tie itself to a specific on-chain UTXO; chain analysis firms would no longer be able to easily follow every public node operator’s funds on-chain between channels. The channel_update_v2 message would then take the place of both channel_announcement and channel_update, fulfilling the same general purpose in the protocol.

In the long term, the idea of a gossip protocol based on flood fill propagation is probably not scalable. Flood fill is one of the most inefficient network designs for propagating information there is, and this is a problem that, in the long term, is going to have to be optimized and shifted into another direction to really be scalable for a payment network that hopefully will be global in size. There is no real way around that. But one of the biggest shortcomings of the current gossip protocol is the evisceration of the privacy of routing node operators. You can’t be a routing node without publicly tainting your channel UTXOs as tied to you and making it easy to surveil them on-chain.

Given that one of the biggest potential utilities that the Lightning Network could add besides the scalability of payments is the privacy of payments, shouldn’t we be addressing the massive ways in which the protocol stack falls short in fulfilling those promises of privacy? I think we should, and one big way to start is by improving the privacy of node operators who actually play the role of facilitating payments across the network in the first place.

This is a guest post by Shinobi. Opinions expressed are entirely their own and do not

necessarily reflect those of BTC Inc or Bitcoin Magazine.