The scaling attempts for the bitcoin network have seen several proposed off-chain or side-chain solutions, but none as popular or as widely used among retail participants as the Lightning Network. The Lightning Network takes a novel approach to bitcoin by ditching the need for a blockchain; that’s right, the Lightning Network does not have a blockchain. It’s not there to reinvent the wheel but instead adds a better class of tire for when transactions hit the road.
The Lightning Network also works as a network of peers, but instead of broadcasting your transaction to the world of bitcoin, asking miners to add it to a block and getting the entire network to check that the block is valid, Lightning says let’s keep our transaction data in a smaller circle of peers.
Lightning is a peer-to-peer network, and when you generate a payment, you’re either paying another peer directly or you’re routing payments through several peers known as hopes. These intermediary hops pass on your payment to its final destination, meaning you don’t need a direct channel with every user, but leverage existing connections instead.
Lightning is used to route money in the form of satoshis, but in bitcoin, the money is entirely digital, so you’re basically sending information, little data packets that could be money, or it could be messages, it could even be both.
What is onion routing?
Onion routing didn’t fall from the sky; like many parts of bitcoin, it’s a concept used in some other parts of internet infrastructure and brought into bitcoin over time. Onion routing was developed in the mid-1990s at the U.S. Naval Research Laboratory by employees Paul Syverson, Michael G. Reed, and David Goldschlag and later refined and patented by the Navy. Years later, it became a core part of the Tor network, a means of private browsing over the internet, and plays a part in accessing and hosting what many would consider the “dark web”.
Onion routing has nothing to do with onions or routing but is simply a cool name for a technique for anonymous communication over a computer network. In an onion network, messages are encapsulated in layers of encryption, analogous to the layers of an onion.
The encrypted data is transmitted through a series of network nodes called “onion routers,” each of which “peels” away a single layer, revealing the data’s next destination. When the final layer is decrypted, the message arrives at its destination. The sender remains anonymous because each intermediary knows only the location of the immediately preceding and following nodes.
While onion routing provides a high level of security and anonymity, there are methods to break the anonymity of this technique, such as timing analysis.
Lightning loves onions
To pass messages and payments across the network, the Lightning protocol uses a method for anonymous communications called onion messaging. If you’re communicating indirectly with a user on the Lightning network, you would not want every person/peer along the path to see your message, would you?
Consider the idea of writing a love letter to your high school crush with a treat inside, but instead of giving it directly to her, you pass it via several classmates, who then open and read the letter and, if they wanted to, could eat the treat, that is not going to be an effective form of communication now is it?
You would need something that obscures the message so the messenger would pass it on without knowing its contents. Onion routing achieves this in digital form by hiding the names of the parties communicating and the data by encrypting the payload in layers, with a different layer for each hop in the route.
Using onion messaging, when you pass on the message to your crush, this time, each person gets a message that they can open, and the message would be to pass on this letter to the next person. The final letter/message cannot be opened by anyone other than the final destination because, this time, there’s a secret key to open the final message.
Onion messages are lightweight, flexible messages that can be sent to anyone on the Lightning Network peers using onion routing. The Lightning Network has supported messages from day one, but changes to the protocol have made it easier to attach additional data to payments and pass it on to other applications using type-length-value (TLV) payloads.
Unpeel the onion
As the message moves through the network, each Lightning node decrypts its own layer and learns the address of the next hop. The node then passes on to the next node to either be hopped again or to be accepted as the final destination.
During each stop in the journey, the payment or message is said to be “unpeeled” at each layer, which is where the onion analogy comes from, not that it would make you cry by reading the messages.
Cutting through the onion
If you’d like practical examples of how onion routing and onion messaging work with the Lightning network, check out the following tutorial by Rene Pickhardt. Rene does a great job of breaking down onion routing and messaging step by step with fewer tears involved in trying to understand the technology.
Why would you need onion messaging?
When you create a channel on the Lightning Network, you need to connect with a peer; the two of you are now tethered together to route payments between one another or route thrid party payments via your connection. If you’re only establishing channels with people you know and communicate with directly, it shouldn’t be an issue to reach out to them to help rebalance a channel, close a channel or open a new channel.
It does get tricky when you’re connecting with strangers from all over the world. By being able to message nodes on the Lightning Network, you can coordinate the better flow of liquidity and maintain relationships with your channel peers, who all have economic incentives to keep the network’s connections running smoothly.
Direct channels could provide absolutely free messaging, however — something that some users might find a negligible benefit compared to potential privacy trade-offs. Messages on Lightning can be paid messaging since you need to attach the message to a payment to send it, but the recipient can reject this payment after opening the message costing you nothing.
Private communication
Chatting over Lightning also makes it much harder to find out who communicates with whom. It is not required to have a direct (observable) TCP/IP connection between users, and there is no central server either that could reconstruct the communication pathways,
Asynchronous payments
The Lightning Network can use onion messaging to perform async payments with the help of LSPs (Lightning Service Providers) on both ends, sender and receiver. The sender’s LSP will hold onto a payment until it receives an onion message from the recipient’s LSP indicating the recipient is online and ready to receive funds.
This means that you don’t always have to be connected to the internet to have a Lightning payment sent to your wallet. You could be offline with your Lightning wallet, and when you’re back online, you will signal to your LSP that you’re up and running and if they have any messages/payments for you.
The LSP will then query to see if they hold any onion messages that have you as the next hop and will pass on those messages or payments to you now that you’re open to communication with the network again.
Lightning and messaging
Lightning-powered messages (or transactions, for that matter) are onion routed, just like information passing through the Tor network. The messages are shunted from node to node and can be used as a communications layer to transfer private messages between users. Â
There are a few applications that leverage Lightning to route messaging along with payments. If you would like to give some of these applications a test run, you can find them below.
| Application | Website |
|---|---|
| Juggernaut | getjuggernaut.com |
| Sphinx Chat | sphinx.chat |
| Whatsat | github.com/joostjager/whatsat |
Combining messaging and payments
The concept of onion messages on the Lightning Network might bring you to the question, but what if people use this to communicate nonsense instead of coordinating with each other to improve lightning? What if there’s a ton of spam, or people stream things more significant than text, like images or videos, over Lightning?
Fortunately, there are many ways to rate limit onion messages. For example, limiting peers to a few kilobytes worth of onion messages per second would not be enough bandwidth to allow for streaming.
You can also restrict forwarded onion messages to channel peers only, meaning that even if someone attempted a full-on DoS attack, they would be forced to open many channels.
Another way to limit spam is through pricing users out; when one user sends another user a message, they have to attach it to a payment, and by adding a cost, it discourages the practice.
Do your own research.
If you want to learn more about onion messaging on bitcoin, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research other sources, and you can start by checking out the resources below.
- Onion Messages Demystified
- Onion Routing on the Lightning Network | René Pickhardt
- Send a payment with a custom onion packet
Are you a bitcoin and lightning fan?
Have you been using Lightning to make micro-payments? Stream sats or engage with apps? Which app is your favourite? Do you run a Lightning node? How do you handle channel rebalancing? Have you tried all the forms of Lightning payments? Which one do you prefer?
Let us know in the comments down below.
