The c-lightning team is excited to announce the v0.9.3 release of c-lightning. This is a minor release, but we’ve added several exciting features in addition to the usual performance, usability, and stability improvements.

Since 0.9.2, we’ve had 339 commits from 13 different authors, not counting all the hours of work going into plugins and apps using c-lightning.

Onion Messages

Have you ever developed an application or plugin on top of Lightning and wished to send someone on the network a message? Well, now you can: onion messages are messages that are routed in the Lightning Network. If this sounds familiar, it was also the goal of WhatSat and our very own noise plugin. However, the protocol abused payments, requiring active channels to route the message and locking funds while delivering them.

Onion messages address this by recreating the onion routing used to deliver payments, providing the same security and privacy but not requiring a payment to deliver the message. This means that onion messages can be routed more efficiently, without locking up liquidity and without even requiring active channels to route over.

Onion messages take what used to be a hack of the lightning protocol and makes it an official feature. And this isn’t limited to chat messages; it allows nodes to run entire subprotocols through the existing network.

Support for onion messages can be enabled at startup with the --experimental-onion-messages flag. However, note that in order to relay messages, every node between sender and destination needs to support this feature. We are releasing this feature now to bootstrap support in the network and enable developers to start building onion messages into their apps in advance of broader network support.

To send a message, you can simply use the sendonionmessage RPC method, and to receive a message, you can register for either the onion_message or the onion_message_blinded hooks in a plugin. For more information about the protocol, please refer to the proposal, the docs for sendonionmessage and the hooks.

Onion messages complement the existing custom message facility that allows injecting arbitrary messages into the communication with a peer. Now, messages can be delivered to any node in the network.

Offers

Continuing with the topic of nodes exchanging messages, we are also releasing experimental support for Offers. Offers implement several automated negotiations between the sender and recipient that may result in a payment. While this sounds abstract, it has some important real-world use-cases:

• Static invoices: An offer can be published on a website and be used to receive any number of payments. This is done by the sender contacting the recipient and retrieving a real, one-time invoice when scanning the offer. Static invoices are particularly interesting if you’d like to receive donations or sell items from a webpage or store that can’t contact your node every time a user places an order.
• Fiat-denominated invoices: Being able to negotiate the conditions of a payment just before sending it means that the offer can be denominated in other currencies, and the exchange rate is applied to the real invoice when the sender retrieves it from the recipient. This can be useful in physical shops where you want to print the price on items in fiat to avoid having to track bitcoin exchange rate fluctuations.
• Provable donations: While we already have keysend for donations, it doesn’t allow you to prove that you donated to someone because the sender generates the preimage used as a proof of payment. By negotiating in the background and retrieving a real invoice from the recipient, we remove this downside, and donations become regular invoice payments, with proof of payment.
• Recurring payments and subscriptions: Offers puts you in control of your subscriptions and other recurring payments. Your wallet will automatically retrieve an invoice when the next payment is due, and you can then proceed to pay it. You have an overview of what is due all in one place, and you can cancel any subscription directly from your wallet. These push-based payments are in stark contrast with credit cards, which pull funds from your account.

These are just some of the use-cases for the first version, but we’re sure there will be many more payment scenarios that can take advantage of these new features. So stay tuned 😀

Get Started with Offers

To start using offers, you can initialize your c-lightning node with --experimental-offers, and several new methods will become available. For more information, please refer to the proposal, the new RPC methods createoffer, and listoffer, and the offer support in the pay method.

Join Our Development Efforts

So there you have it, loads of new functionality to tinker with. We’d love to hear from you about what could be improved or your ideas on what could be built on top of the new features.

If you’re as excited about the new possibilities as we are, feel free to join us on IRC #c-lightning on Freenode or our biweekly developer meeting on Jitsi. If you’re curious about what we’re currently working on, we’re keeping a shortlist of priorities on the wiki.

Note: This blog was originally posted at https://medium.com/blockstream/c-lightning-v0-9-3-federal-qualitative-strengthening-8d431e63b148