Improving The Privacy Of The Lightning Network’s Gossip Protocol

Improving The Privacy Of The Lightning Network’s Gossip Protocol thumbnail

This is Shinobi’s opinion editorial. Shinobi is a self-taught educator and tech-oriented Bitcoin podcast host.

The Lightning protocol works in atomically updating payments across multiple channels in such a manner that everything confirms or fails together — i.e. it routes payments across multiple hops. A routing table is an integral part of any routing-based systems. It contains all the information needed to construct a path from point A and point B. You can’t route anything if you don’t have this information. Lightning requires a routing table. This is what BOLT 7 describes. It allows for the propagation and maintenance a record of channels on the network that can be used to route payments.

This gossip protocol represents one of the scaling issues of the entire Lightning protocol stack. It is currently very basic and works in a manner that is very similar to the propagation transactions on the Bitcoin network. Nodes on the network receive a gossip messages, verify it according to the rules and then pass it on to their peers to spread the news across the network. It assumes that valid messages will eventually spread across the entire network.

This is because spam can cause denial-of service attacks (spam), which can lead to large amounts of bandwidth and processing resources being consumed. Nodes won’t relay invalid transactions on the main Bitcoin network. To broadcast something that uses bandwidth and computational resources, you must have bitcoin to create a transaction. To relay gossip messages about a channel, you must prove that you have a valid UTXO funding it. This serves the same spam protection function on the main Bitcoin network. You cannot spam messages across the network unless you actually control bitcoin.

This is the structure of the gossip protocol. Although this will not be a complete breakdown of the protocol it will provide enough insight to allow you to examine a proposed change and evaluate the trade-offs between current protocol and the proposed change. The gossip protocol currently contains three main messages. The channel_announcement, node_announcement and channel_update messages are the three main messages in the gossip protocol. 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 won’t cover messages for requesting data as they aren’t relevant to this article.

To announce a channel to a network and to then announce your node to public, you need to send the channel_announcement message. It is a collaboratively created message that requires both channel partners to create and broadcast. This message contains proof that a channel has funded its multisig address. It also includes signatures from both Lightning node identity keys of the participants. It declares which multisig keys are owned by which node, and also includes signatures from each multisig of the UTXO that funds the channel. This proves that both channels have control over the on-chain multisig and that their Lightning node identity keys are associated with it.

Next is the node_announcement messages. This message is not sent to a node if it attempts to relay it without having sent a channel_announcement message. Nodes relay this message themselves after opening their first channel for other nodes. This message contains the signature of the node identity key, some feature bits for future versions, the network address that the node can reach at to open channels with, and an alias (nickname).

The channel_update message is also included. This message can also be made unilaterally by a single Node. It includes the minimum and maximum hashed timelock agreements (HTLCs), the fees that an operator will charge to route through that channel (base and percentage fees rate); and the time it needs between itself and the previous hop to create a timelock difference so that it has enough time to find a transaction settling onto-chain and enforce the correct outcome if necessary. It is signed as all other messages.

The protocol as it stands now allows you to search for channels to route payments through, inform about the fees that each channel charges, and provide a denial of service protection mechanism to stop the Lightning Network being bombarded with nonsense advertisements from channels that don’t exist. This is done by requesting signatures from the keys UTXO on the blockchain.

However, it suffers from a lack of privacy. To advertise your channel on the network, people must be able to route payments through it. You will need to dox the exact UTXO that funded the channel and associate it to your Lightning node’s identification key. What can we do about this?

Rusty Russell of Blockstream proposed an updated version 2022. of the gossip protocol. It would reduce the number of core protocol messages from three to two and greatly improve privacy properties.

This would effectively mean that the channel_announcement message would be removed and the protocol would still have node_announcement_v2 as well as a channel_update_v2 notification message. Instead of doxxing each UTXO associated to a channel and requiring a channels_announcement, the node_announcement_v2 could be used to remove the channel_announcement message and leave the protocol with node_announcement_v2 and a channel_update_v2 message. The node operator would then have the right to advertise channels that reflect a multiple of that amount. For example, if you have 1 BTC and you prove control over it, you can now advertise 10 routing capacity without having to dox any channel UTXOs.

This would provide a significant privacy improvement to the network, as each channel would not have to be tied to a specific UTXO on-chain. Chain analysis firms would not be able to follow every public node operator’s funds on-chain. Channel_update_v2 would replace channel_announcement as well as channel_update and serve the same purpose.

Long-term, the idea of a gossip protocol that relies on flood fill propagation to spread information is unlikely to be scalable. Flood fill is one the most inefficient network designs to propagate information. This is a problem that will need to be optimized and shifted in another direction in order to make it scalable for a global payment network. There is no way around it. One of the greatest flaws of the current gossip protocol’s privacy protections is the evisceration the privacy of routing network operators. You can’t be a routing network without making your channel UTXOs publically tied to you. This makes it easy to monitor them on-chain.

Given the potential utility that the Lightning Network could bring to the table, aside from the scalability and privacy of payments, shouldn’t we also address the many ways that the protocol stack fails to live up to those promises? I believe we should. One way to begin is to improve the privacy of node operators, who in fact facilitate payments across the network.

This is Shinobi’s guest post. Opinions expressed are entirely their own and do not

necessarily reflect those of BTC Inc or Bitcoin Magazine.

Read More