This is an opinion editorial from Shinobi, a self-taught teacher in the bitcoin space and tech-oriented bitcoin podcast host.
The Lightning Protocol works by updating payments across multiple payment channels atomically in such a way that everything confirms or fails at once – that is, it routes payments across multiple hops. An integral part of any routing-based system is a routing table, which is actually a collection of all the information needed to build 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, where it’s from and where you want it to go. Lightning explicitly requires a routing table that meets the gossip protocol specified in BOLT 7; Promotion and maintenance of records of channels available on the network for routing payments.
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 similar to the spread of transactions on the bitcoin network; Nodes on the network receive a gossip message, then they verify the message according to the rules of validity, and pass it on to all their peers to be propagated throughout the network. It is a simple flood fill protocol that assumes that valid messages will eventually spread across the network.
Because of this, there are concerns about denial-of-service attacks (spam) that will consume 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 the nodes’ bandwidth and computational resources, you actually need bitcoins to create transactions. In the case of the Lightning Gossip Protocol, you need to prove that you control a legitimate UTXO funding for a channel to broadcast gossip messages about the channel. It performs spam protection functions similar to the main bitcoin network; You can’t spam messages across the network without actually controlling bitcoin.
This brings me to the actual structure of the gossip protocol. This would by no means be a comprehensive breakdown of the protocol, but rather a deep enough look at the proposed change and to assess the trade-offs between the proposal and the current protocol. There are currently three main messages in the gossip protocol. channel_announcement message, node_announcement message and channel_update message. There is also an announce_signature message, but it is only used to sign messages announcing channels with direct channel peers, and is not widely broadcast across the network. I’m not going to cover messages for requesting data, as they aren’t really relevant to the point of this article.
The channel_announcement message is the first thing needed to announce a channel to the network and then to announce its node to the public. It is collaboratively produced and requires both channel partners to produce and broadcast. The message contains proof that the funding transaction for the channel paid into the channel’s multisig address, and then includes signatures on the message with the Lightning node identity keys of both participants. It declares which multisig key is owned by which node and includes signatures from each multisig key of an on-chain UTXO used to finance the channel. This proves that both nodes involved in the channel control on-chain multisig, and then proves that their Lightning node identity key is associated with it.
Next is the node_declaration message. If a node tries to relay this message for a valid channel without first sending a channel_announcement message, it is ignored and not relayed. Nodes self relay this message after opening their first public channel allowing other nodes to connect to them. This message has a signature from the node identification key on the message; Some feature bits for future version updates, the network address node to open the channel, can be accessed with an alias (alias) and a few other bits of information.
Finally, the channel_update message. This message is also created and transmitted unilaterally by a node. This includes the minimum and maximum value hashed timelock contracts (HTLC) that 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 the timelock difference it needs between itself and the previous hop, so that it has time to find the on-chain settled transaction and apply the appropriate result to itself if necessary. It is also signed like all other messages.
So the protocol as it now provides all the information you need to find channels through which you can pay, advertise the information needed to know what each channel will charge, and to prevent the Lightning Network. Provides a service-to-service security mechanism. Being spammed all day with rubbish ads from channels that don’t exist by requiring signatures from keys holding funding UTXOs on-chain.
But it has one major problem: a total lack of privacy. In order to route payments to people advertising your channel on the network, you need to fix the exact UTXO used to fund that channel and associate it with the identity key of your Lightning node. So what can we do to fix it?
Blockstream’s Rusty Russell proposed an updated version of the Gossip protocol in February 2022. This will take the original protocol from three messages to two and result in a substantial improvement in privacy properties.
What would effectively happen is remove the channel_announcement message altogether and leave the protocol with the node_announcement_v2 and channel_update_v2 messages. Instead of docking each individual UTXO associated with a channel, and requiring a channel_announcement first, node_announcement_v2 can be performed initially and proving control over a UTXO that is not actually used to fund a channel. is done. The node operator will then be allowed to advertise channels representing certain multiples of that amount (so assuming you have 1 BTC that you have proven control over, you can now advertise 10 BTC of routing capacity) are), without docking the actual channel UTXO.
This would be a massive privacy improvement for the network by not requiring each channel to associate itself to a specific on-chain UTXO; Chain analysis firms will no longer be able to easily follow each public node operator’s funds on-chain between channels. Then the channel_update_v2 message will replace both channel_declaration and channel_update , which serve 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 information dissemination out there, and it is a problem that has to be optimized and moved in the other direction in the long run for payment networks to be truly scalable. which is expected to be global in size. There is no real way around it. But one of the biggest drawbacks of current gossip protocols is the breach of confidentiality of routing node operators. You can’t be a routing node without publicly linking your channel UTXOs to yourself and making it easy to survey them on-chain.
Given that one of the biggest potential utilities that the Lightning Network could add in addition to scalability of payments is payment privacy, do we need to address ways to reduce the massive protocol stack that can deliver on those privacy promises? Shouldn’t you? I think we should start, and a big way to start is by improving the privacy of the node operators that really play the role of facilitating payments across the network in the first place.
This is a guest post by Shinobi. Opinions expressed are solely his own and do not
necessarily reflect those of BTC Inc. or bitcoin magazine,