This is an opinion editorial by Shinobi, a self-taught bitcoin educator and tech-savvy bitcoin podcast host.
The Lightning Protocol works by atomically updating payments across multiple payment channels to confirm or fail all together—meaning it routes payments through multiple hops. A key part of any routing-based system is a routing table, a collection of all the information needed to actually construct a path from point A to point B. Without that information, you can’t really route anywhere because you don’t know how to get the information from where it is to where you want it. Lightning obviously needs a routing table, which is what the Gossip protocol specified in BOLT 7 does; the dissemination and maintenance of the records of the channels available on the network to conduct payments.
This gossip log is one of the scaling issues of the whole Lightning log stack. Currently, it is very simple and works in a way that is quite similar to how transactions are proliferated on the actual bitcoin network; Nodes in the network receive a gossip, they then verify the message according to the validation rules and forward it to all their peers for further propagation across the network. It’s a naive floodfill protocol that assumes valid messages will eventually propagate throughout the network.
Because of this, there is a risk of denial-of-service (spam) attacks, which end up consuming a large amount of processing resources and bandwidth to deal with. In the case of the main bitcoin network, the nodes do not forward invalid transactions. So to send something that consumes the bandwidth and computing resources of the nodes, you must actually have bitcoin to create a transaction. In the case of the Lightning Gossip Protocol, you must demonstrate that you control a valid UTXO funding a channel in order to relay a gossip through the channel. This performs the same spam protection function as in 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 log. This will by no means be a comprehensive breakdown of the protocol, but will provide enough in-depth insight to consider a proposed change and assess the trade-offs between the proposal and the current protocol. The gossip log currently contains three main messages. The channel_announcement message, the node_announcement message, and the 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 is not widely broadcast across the network. I won’t cover the data request messages as they aren’t really relevant to the point of this article.
The channel_announcement message is the first thing required to announce a channel to the network and then also announce your node to the public. It is collaboratively created and must be created and broadcast by both channel partners. This message includes proof that the funding transaction to a channel pays into the channel’s multisig address, and then includes signatures from both participants’ Lightning node identity key over the message. It declares which multisig key belongs to which node and contains 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 linked to it.
Next comes the node_announcement message. If a node attempts to forward this message without first sending a channel_announcement message for a valid channel, it will be ignored and not forwarded. Nodes themselves forward this message after opening their first public channel for other nodes to connect to them. This message contains a signature from the message’s node identity key; some feature bits for future version updates, the network address at which the node can be reached to open channels, an alias (nickname) and some other information.
Finally the channel_update message. This message is also created and sent unidirectionally by a single node. It contains the minimum and maximum value Hashed Timelock Contracts (HTLCs) that a channel forwards; the fee charged by the operator for routing over this channel (basic fee and percentage fee); and the length of the timelock difference it needs between itself and the previous hop to give it time to find a transaction playing out on the chain and enforce the correct outcome for itself if necessary. It is also signed like all other messages.
So the protocol as it stands provides all the information needed to find channels to route payments through, announces the information needed 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 nonsensical ads from channels that don’t exist, by requiring signatures from the keys that the funding UTXO keeps on-chain.
But it has one major problem: a total lack of privacy. In order to promote your channel on the network so people can forward payments, you must 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?
Blockstream’s Rusty Russell proposed an updated version of the Gossip protocol in February 2022. It would reduce the core protocol from three messages to two and subsequently drastically improve privacy properties.
What would actually happen would be to remove the channel_announcement message entirely and leave the log with node_announcement_v2 and a channel_update_v2 message. Rather than doxxing every single UTXO associated with a channel and requiring a channel_announcement first, the node_announcement_v2 could be initially and prove control of a UTXO that is not actually used to fund a channel. The node operator would then be entitled to advertise channels reflecting multiples of that amount (so say you have 1 BTC that you have proven control over, you can now advertise 10 BTC of routing capacity) without the having to dox actual channel UTXOs.
This would be a massive privacy improvement for the network, as not every channel needs to bind to a specific on-chain UTXO; Chain analytics firms would no longer be able to track each public node operator’s funds between channels in the chain. The channel_update_v2 message would then replace both channel_announcement and channel_update and serve the same general purpose in the protocol.
In the long term, the idea of a gossip protocol based on flood-fill propagation is unlikely to scale. Flood fill is one of the most inefficient network designs for disseminating information, and this is a problem that needs to be optimized over the long term and shifted in another direction in order to be suitable for what is hoped to be a truly scalable payments network that will be of global scale. There is no real way around it. But one of the major shortcomings of the current Gossip protocol is the gutting of the privacy of routing node operators. You cannot be a routing node without publicly marking your channel UTXOs as bound to you and making it easy to monitor them on the chain.
Given that one of the biggest potential utilities the Lightning Network could add, aside from payment scalability, is payment privacy, shouldn’t we delve into the massive ways in which the protocol stack falls short of those privacy promises? I think we should, and a good place to start is improving the privacy of node operators, which actually play the role of enabling payments across the network in the first place.
This is a guest post by Shinobi. Opinions expressed are entirely their own and should not be
necessarily reflect those of BTC Inc or Bitcoin Magazine.
