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
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
--db.bolt.auto-compact flag, and to swap its cadence use the
--db.bolt.auto-compact-min-age to 0 will force the process to run on every startup.
Check PR#4667 for more information.
Anchor Output Channels
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.
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 LNsync — a 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.
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.
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
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.
Things I Would Share This Week
Taproot Activation Discussion IRC Meeting — Michael Folkson announced a meeting to discuss details around BIP8 with regards to Taproot activation mechanisms and strategies. Join the ##taproot-activation IRC channel on Freenode at 19:00 UTC on February 2nd to take part.
ZEBEDEE announces Bitcoin-Infused CS:GO — In the last MintGox event the team demonstrated the Infuse product on a live CS:GO Esports tourney. To be among the first to use Infuse and win sats playing Counter Strike, sign up here.
WallStreetBetChairman tweets — No comments necessary
That's all for Lightning This Week, see you again in a few blocks time.