Lightning This Week #668,060

Releases for LND v0.12 Beta & C-Lightning v0.9.3, LNsync for mobile Lightning nodes, and MintGox #011 with Bitcoin-Infused CS:GO tournament.

Hello and welcome to LTW! This week we have the outstanding MintGox Bitcoin Esports tournament happening on Sunday the 31st at 2pm EST. Along with the community favorites Bitcoin Bounty Hunt and SaruTobi, ZEBEDEE will be hosting the second Bitcoin-Infused CS:GO deathmatch tournament.

Something tells me this is the last tourney before public beta release…

Alright, onto the technical things:

LND v0.12 Beta

After a few release candidates, the release for LND version 0.12 beta has been officially posted, and while we’ve covered some of the new features/changes in the releases of LTW #666,209 and LTW #662,816 I figured it couldn’t hurt to highlight a few others.

Automatic Database Compaction

If you’ve been running LND at scale for a while, you’ll notice that its database can get quite large after months of use and lots of onchain/offchain transactions have been performed. This is because bbolt database library used by LND does not give back free space to the system after data is deleted (intentional). However, large database files will usually lead to rather slow startup times.

Thankfully there is a way to compact your bbolt database. Effectively this compaction feature will create a new copy of the bbolt database only containing actual data and excluding any reserved space from previous data deletion operations. As you’d expect, it also helps with validating the integrity of the data in your bbolt database.

While one could always perform database compaction processes manually, an automated procedure has been added to LND that performs the compacting function on every startup (given some arbitrary cadence — e.g. every X days). To enable automatic compaction of your channel.db file use the flag, and to swap its cadence use the Setting to 0 will force the process to run on every startup.

Check PR#4667 for more information.

Anchor Output Channels

We’ve already discussed Anchor Channels on LTW #666,209 but I did want to mention there was PR#4917 which modified some behavior.

This commit reverts the anchors-by-default change, and instead makes anchor commitments an opt-in option. The plan is to enable anchors by default further down the line.

Instead of anchor channels being the default for LND v0.12, the team decided node operators would likely need more time to make strategic decisions about anchor upgrade plans.

  • How do the fee update sweeps actually execute?

  • Can you Sybil-detect peers or analyze reliability to reduce your desired reserved UTXO size?

  • Could you swap available off-chain funds for on-chain fee increases?

Olaoluwa Osuntokun from Lightning Labs does mention in the CHANGELOGS that “it's worth noting this is not going to be opt-in forever: anchors are a major step on a path to fundamental improvements in channel security.”

Nevertheless, one can already opt-in to anchor channels by setting the --protocol.anchors flag at startup. Other nodes that have this flag set will automatically open new anchor channels with your node.

Graph Optimizations

Another performance improvement that is packaged into the LND v0.12 beta release is a refactor to enable batching of all insertion operations that relate to the channel graph. This update should greatly speed up initial graph downloads when the LND node is starting up (recent benchmarks have shown a 3x speed increase).

Check PR#3367 for more information.

Check CHANGELOGS for more information on LND v0.12 beta version.

LNsync’s your network graph

One of the current pitfalls of running Lightning nodes on mobile devices is the always-online requirement. A Lightning node must be online primarily for two reasons:

  • sending, receiving, and forwarding payments

  • ensuring no channel-connected peer node is cheating your channel state

While not heavily used in the industry at the moment, Watchtowers are seen as a potential solution for the latter. The former however is a different concern. Nodes need to know the network graph in order to be able to calculate paths that route HTLCs, and without connectivity it is impossible to know the latest state of the network. While there have been improvements to initial graph downloads across implementations, it is common to have to wait long seconds/minutes for your mobile node to catch up with the latest network state — totally hindering the Lightning fast user experience.

This week Blockstream announced LNsynca server-assisted gossip synchronization mechanism for Lightning nodes. Think of LNsync as a helper web-server that your mobile Lightning node can reach into and query for the latest state of the network. LNsync is powered by its own C-Lightning nodes that are constantly ingesting network graph data into a separate indexed database.

Using the historian plugin, we collect, deduplicate, and store all the gossip messages received by our C-Lightning nodes. The information is stored in a database and indexed for fast retrieval.

Because LNsync is consuming all of the changes in the network, it knows the changes pertinent to your node since it was last online. By making that information readily-available to the mobile node in a compact format, your node is able to re-sync with the latest state of the network in record time, allowing for payment route calculation to happen faster.

For example, catching up two hours results in about 500KB of uncompressed data, delivered in just over a second, while catching up on 24 hours results in about 6MB of data and requires approximately 2.5 seconds. This is significantly faster than a full sync using the gossip protocol.

This is a powerful tool because mobile wallet applications can now query changes from a specific point in time through an API powered by LNsync that delivers a minimal set of gossip messages required to catch up with the rest of the network.

Read more on the press releases: Announcement, In-Depth Engineering Blog

C-Lightning v0.9.3 Release

The C-Lightning team have just posted the release for version 0.9.3 of the node software, codenamed Federal Qualitative Strengthening. While this is a minor release there are a few goodies that are worth highlighting, both for users and node operators alike.

Lightning Offers

Rusty Russel has been working on an experimental implementation for Offers in C-Lightning. Offers are special Lightning invoices that allow for multi-use, refunds, and even different currency denominations. Although it is still a work in progress, in C-Lightning v0.9.3 there is experimental support for Offers.

“If you ever wanted to have an inline communication step with the other endpoint of a payment then take a look at this.”

Check out the RFC for technical details on how Offers work.

Custom Node <> Node Messaging

v0.9.3 also adds experimental support for sending and receiving arbitrary onion messages between nodes in the network. Node operators can use  sendonionmessage to send an onion encrypted/routed message, which node recipients can receive and parse using a plugin that register for the onion_message or onion_message_blinded hook.

Check PR#4328 for more information.

No More Reckless

From v0.9.3 onwards the C-Lightning software will default to using mainnet Bitcoin as the network of choice. Those using testnet Bitcoin C-Lightning nodes beware, after an update to v0.9.3 ensure that you are explicitly choosing testnet as the network.

Check the RELEASE NOTES and CHANGELOGS for more information.

Things I Would Share This Week

That's all for Lightning This Week, see you again in a few blocks time.