This is an opinion editorial by Shinobi, a self-taught educator within the Bitcoin area and tech-oriented Bitcoin podcast host.
The Lightning protocol works by atomically updating funds throughout a number of fee channels in such a means that every part confirms or fails all collectively — i.e., it routes funds throughout a number of hops. An integral a part of any routing-based system is a routing desk, a group of all the knowledge obligatory to really assemble a path from level A to level B. Without this info, you may’t actually route something anyplace since you don’t understand how to get the knowledge from the place it is to the place you need it to go. Lightning clearly requires a routing desk, which is what the gossip protocol laid out in BOLT 7 accomplishes; the propagation and upkeep of the file of channels accessible on the community to route funds by means of.
This gossip protocol is one of many scaling issues of your complete Lightning protocol stack. Currently, it is very primary and works in a means that is fairly comparable to the propagation of transactions on the Bitcoin community correct; nodes on the community obtain a gossip message, they then confirm the message in accordance to the principles of validity, and cross it on to all of their friends to additional propagate throughout the community. It is a naive flood fill protocol that assumes that legitimate messages will finally propagate throughout your complete community.
Because of this, there is a priority of denial-of-service assaults (spam) that can wind up consuming a considerable amount of processing assets and bandwidth to cope with. In the case of the primary Bitcoin community, nodes won’t relay invalid transactions, so to broadcast one thing that consumes nodes’ bandwidth and computational assets requires you to even have bitcoin to create a transaction with. In the case of the Lightning gossip protocol, you are required to show you management a sound UTXO funding a channel so as to relay a gossip message concerning the channel. This performs the identical spam safety perform as on the primary Bitcoin community; you can’t spam messages throughout the community with out really controlling bitcoin.
This brings me to the precise construction of the gossip protocol. This will not at all be a complete breakdown of the protocol, however a deep sufficient look into it to have a look at a proposed change and assess the trade-offs between the proposal and present protocol. There are three major messages at the moment within the gossip protocol. The channel_announcement message, node_announcement message and channel_update message. There is additionally an announcement_signatures message, however this is solely used with direct channel friends to signal messages saying channels, and it is not extensively broadcast throughout your complete community. I’m not going to cowl the messages for requesting knowledge, as they are probably not related to the purpose of this text.
The channel_announcement message is the very first thing required so as to announce a channel to the community after which to announce your node to the general public as effectively. It is collaboratively constructed and requires each channel companions to make and broadcast. This message contains proof that the funding transaction to a channel pays into the channel multisig tackle, after which it contains signatures from the Lightning node identification key of each individuals over the message. It declares which multisig key is owned by which node and contains signatures from every multisig key of the on-chain UTXO funding the channel. This proves that each nodes concerned in a channel have management of the on-chain multisig, after which it proves that their Lightning node identification key is related to it.
Next up is the node_announcement message. If a node makes an attempt to relay this message with out having beforehand despatched a channel_announcement message for a sound channel, it is ignored and never relayed. Nodes relay this message by themselves after opening their first public channel to enable different nodes to join to them. This message comprises a signature from the node identification key on the message; some characteristic bits for future model updates, the community tackle the node may be reached at to open channels with, an alias (nickname) and some different bits of information.
Lastly, the channel_update message. This message is additionally made and broadcast unilaterally by a single node. It comprises the minimal and most worth hashed timelock contracts (HTLCs) a channel will route; the payment that the operator will cost for routing by means of that channel (base payment and share payment charge); and the size of timelock distinction it requires between itself and the earlier hop, in order that it has time to discover a transaction settling on-chain and implement the right end result for itself if obligatory. It is additionally signed like all different messages.
So the protocol because it is now offers all the knowledge obligatory to discover channels you may route funds by means of, promote the knowledge obligatory to know what charges every channel will cost, and offers a denial-of-service safety mechanism to stop the Lightning Network from being spammed all day with nonsense commercials of channels that don’t exist by requiring signatures from the keys holding the funding UTXO on-chain.
But it has one main drawback: a complete lack of privateness. In order to promote your channel on the community for folks to route funds by means of, you will have to dox the precise UTXO used to fund that channel and affiliate it along with your Lightning node’s identification key. So what can we do to repair 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 enhance the privateness properties as a consequence.
Effectively what would occur is to fully take away the channel_announcement message and go away the protocol with node_announcement_v2 and a channel_update_v2 message. Instead of doxxing every particular person UTXO related to a channel, and requiring a channel_announcement first, the node_announcement_v2 might be accomplished initially and show management over a UTXO not really used to fund a channel. The node operator would then be allowed to promote channels reflecting some a number of of that quantity (so say you will have 1 BTC you proved management over, now you can promote 10 BTC of routing capability), with out having to dox the precise channel UTXOs.
This could be a large privateness enchancment for the community by not requiring every channel to tie itself to a selected on-chain UTXO; chain evaluation corporations would now not give you the option to simply comply with each public node operator’s funds on-chain between channels. The channel_update_v2 message would then take the place of each channel_announcement and channel_update, fulfilling the identical normal goal within the protocol.
In the long run, the concept of a gossip protocol primarily based on flood fill propagation is in all probability not scalable. Flood fill is probably the most inefficient community designs for propagating info there is, and this is an issue that, in the long run, is going to have to be optimized and shifted into one other course to actually be scalable for a fee community that hopefully might be international in dimension. There is no possible way round that. But one of many greatest shortcomings of the present gossip protocol is the evisceration of the privateness of routing node operators. You can’t be a routing node with out publicly tainting your channel UTXOs as tied to you and making it straightforward to surveil them on-chain.
Given that one of many greatest potential utilities that the Lightning Network might add in addition to the scalability of funds is the privateness of funds, shouldn’t we be addressing the large methods through which the protocol stack falls quick in fulfilling these guarantees of privateness? I believe we must always, and one large means to begin is by bettering the privateness of node operators who really play the position of facilitating funds throughout the community within the first place.
This is a visitor publish by Shinobi. Opinions expressed are totally their personal and don’t
essentially replicate these of BTC Inc or Bitcoin Magazine.
