New on Bitcoin’s Lightning Network: LND Adds Accounting Feature, c-lightning Gets an Upgrade

While so-called “DeFi degens” are busy bidding up the price of food-themed tokens, on the other end of crypto’s DeFi spectrum two teams working on the most popular implementations of Bitcoin’s Lightning Network have been busy pushing out new features.

This week, both Lightning Labs, which maintains the Lightning Network Daemon (LND) implementation of the Lightning Network, and Blockstream, which maintains the c-lightning implementation, updated their tech stacks.

Read more: What Is Bitcoin’s Lightning Network?

For Lightning Labs, the update comes to its Faraday suite with the addition of an automated accounting feature to make bookkeeping easier for node operators and Lightning Network service providers (LSPs). For Blockstream, the 0.9.1 release of c-lightning improves channel opening and routing mechanisms to make opening channels (and sending payments) easier than before.

Lightning meets accounting

Lightning Labs updated its Faraday suite this week to bake in accounting tools for both Lightning and on-chain transactions.

As LND’s tech stack has increased to include advanced features like Lightning Loop, the accounting burden for businesses running Lightning services has likewise become more cumbersome.

Seemingly a simplistic update, the new Faraday accounting feature will automate what was formerly a manual process – a welcome tool for LSPs that have to wrestle with hundreds of Lightning channels swimming with several thousand dollars worth of liquidity.

Read more: Lightning Labs Releases ‘Loop’ Feature for Bitcoin Payments Channels

All the data collected by the automated accounting tool can be imported into Google Sheets or Microsoft Excel.

“By adding accounting reports to Faraday’s suite of tools, we hope to free up engineering time that has been spent auditing nodes, and allow businesses and builders to focus on delivering the uniquely Lightning features that we all love to end users. Accounting has been a common pain-point in integrating Lightning, one that we ourselves have felt when dealing with our own accounting internally,” Lightning Labs developer Carla Kirk-Cohen told CoinDesk.

According to Bitcoin service and payment provider OpenNode, the new accounting feature will help them save money by making channel-related data easier to parse in real time.

“Faraday allows us to easily calculate bitcoin-related operational expenditures and monitor channels' activity, allowing us to make data-driven decisions on where to deploy capital on the network in order to maximize its potential earnings” OpenNode CTO João Almeida told CoinDesk

Multi-channel, multi-part

Concurrent with Lightning Lab's Faraday release, Blockstream pushed improvements to its c-lightning implementation’s channel management and routing tools.

Version 0.9.1 of c-lightning ostensibly improves “multi-part payments,” (MPP) a method for splitting larger Lightning Network payments into fractions and routing these pieces through multiple payment channels. This method improves the likelihood that larger transactions will be able to find a route between sender and receiver, and the new version rids c-lightning of bugs to make the process more efficient.

Read more: ‘Multi-Part’ Payments Could Bring Bigger Bitcoin Sums to Lightning Network

Complementing this are improvements to c-lightning’s “route hint” feature, which gives a payer a warning if there isn’t enough liquidity along a given payment route to complete the transaction. The upgrade now provides multiple route hints to the benefit of multi-part payments.

But perhaps the most exciting update comes in the form of c-lightning’s multifundchannel plugin. With this feature, it’s now possible to open multiple channels with a single commitment transaction with c-lightning.

When trialing the feature on testnet, Blockstream’s team was able to open up 106 channels with a single transaction, though theoretically, even more channels could be opened simultaneously with the feature.

“With MPP, we go from a single channel being the bottleneck to being able to aggregate the capacity of multiple channels, and thus enable a much wider range of payments,” Blockstream c-lightning developer Christian Decker told CoinDesk.

“This increases the efficiency of both the Bitcoin network and node operation, ultimately making it easier and less expensive for nodes to open multiple smaller channels and it encourages them to contribute to the structural resilience of the Lightning network by reducing single points of failure.”

Different implementations, complementary parts

In our correspondence, Kirk-Cohen claimed that the new Faraday release, when taken in tandem with other recent LND updates, signals that the Lightning Network is ready for business and enterprise adoption.

"The recent release of Wumbo in lnd v0.11.0 was a sign that we believe the software has matured to the point where businesses and serious node operators can start to move more capital onto the network. The release of accounting reports in Faraday is a continuation of that message, Lightning is ready for the big leagues."

Read more: Ready to Wumbo: LND Enables More, Larger Bitcoin Transactions on Lightning

LND and c-lightning are two distinct implementations, but their respective features provide complementary building blocks to improve the Lightning Network’s overall tech stack. LND’s Wumbo features, for example, allows high-liquidity node operators to open larger channels and thus increase their ability to route incoming payments.

For its part, c-lightning’s multi-part payments and multifundchannelplugin complement Wumbo channels by making it easier for smaller-account holders to open multiple channels, Decker said.

“MPP and multifundchannel are complementary with Wumbo channels, which mostly enable the operation of larger nodes that have the necessary funds available to open large backbone channels. While a stable network backbone of large channels is good to get payments from one end of the network to another, they may also pose a risk, since they increase the reliance on individual channels. It is our belief that maintaining a balance between large node operators (to build a solid backbone) and smaller node operators is paramount for the survival of the network.”