We’ve come a long way since the early #craeful days of the Lightning Network. When building, tinkering, and experimenting, we’ve always encouraged the community to use caution when using the network. To keep your funds safu, Lightning channel sizes were limited to a maximum of 0.1677 BTC. After two years of hard work and extensive testing from the community, we have reached a point where we feel comfortable removing these constraints for those who want larger channels. With this release of lnd v0.11-beta, we now support Wumbo, channels over the 0.1677 BTC limit! We view shipping Wumbo in lnd v0.11-beta as a sign that the software has progressed to a point where advanced users, companies, and node operators can opt in to larger channels.

But it doesn’t stop with Wumbo. The lnd v0.11-beta release includes experimental support for database replication (backups that can resume channel operations in case of hardware, network, or power failures), a number of developer-focused improvements that provide more fine-grained control and reporting from lnd, and numerous safety and reliability improvements. Alongside other recent releases, such as Multi-Path Payments and Multi-Loop, we hope the new version of lnd with Wumbo makes it easier to use Lightning and opens up new possibilities on bitcoin!

Keep reading for more on Wumbo and the rest of the lnd v0.11-beta release features. For additional details check out the lnd v0.11-beta release notes.

Wumbo

The most readily apparent change in lnd v0.11-beta is support for the removal of channel size limits. In 2018, when lnd v0.3-beta was initially released for Mainnet, channel sizes were limited to a maximum of 0.1677 BTC. This was done as a safety precaution to discourage node operators from holding large amounts of BTC in a single channel or on a single node. In the early days, before the Lightning Network had gone live with real funds at stake, the scope of possible attacks was unknown, and how well Lightning node implementations like lnd would hold up under real-world conditions was uncertain.

Two years later, as the network has grown, matured, and been tested much more extensively, these limits have become less relevant for advanced users. A number of larger routing nodes, merchants, and service providers having already removed them from lnd by forking the code. For those who’ve been following LN development for a while, channels larger than the 0.1677 BTC limit were dubbed “wumbo” channels, and Wumbology has become a favorite pastime in the dev community. Along with the recently released MPP, larger, wumbo-sized channels make it possible for nodes to service larger transactions and higher transaction volumes while reducing on-chain fees and overhead required to open and manage a larger number of smaller channels.

In lnd v0.11-beta, it’s now possible to start lnd with the --protocol.wumbo-channels option, which removes enforcement of channel size limits. Note that while lnd and the Lightning Network have come a long way over the last two years, users should still be aware that Lightning wallets are “hot” wallets and are exposed to a variety of risks inherent in storing funds on internet-connected devices. As such, care should be taken to mitigate these risks when possible. For network participants who are doing larger transaction volumes with larger channels, we recommend reviewing the operational security guide in the lnd documentation.

Another security precaution we recommend for publicly advertised nodes is to use the Channel Acceptor feature in lnd to implement configurable channel size limits that fit the node operator’s use case and risk profile.

Reliability

Related to securing nodes that control larger amounts of bitcoin, one of our longstanding goals has been to improve backups in lnd so that in case of a hardware or network failure, a node with a properly backed up database could continue operating seamlessly. With the existing Static Channel Backup (SCB) data loss protection system, recovering data corruption or loss requires closing existing channels. While this protects funds from being lost, it’s inconvenient, particularly for high-volume nodes operating many channels.

In lnd v0.11, we’ve added initial support for database replication via etcd. This is still an early experimental release of this feature and isn’t recommended for production deployments. However, we would encourage those who are interested to try it out and report any issues or feature requests. In future lnd versions, we plan to explore other database options such as SQL backends as well.

Another significant reliability improvement in lnd v0.11 fixes a series of bugs that were causing unintended force closes when channels were restarted. For some larger services and node operators, these erroneous force closes were particularly troublesome and a significant amount of development effort in lnd v0.11 was spent understanding and resolving these somewhat subtle reliability issues.

Node operators

lnd v0.11-beta adds support for node operators to advertise their nodes by domain name rather than by IP address only as was the case previously. This is much more convenient for node operators operating with dynamic IP addresses.

Another lnd v0.11-beta feature targeted at more sophisticated node operators is the addition of payment path constraints. This allows a payment sender to specify a set of channels that should be included when determining a payment’s route. This is particularly useful for channel rebalancing.

A final improvement for node operators is support for the latest versions of bitcoind (v0.20) and btcd.

Developer improvements

In lnd v0.11-beta, developers will now have more fine-grained control over transaction creation with the addition of concurrent-safe external support for coin selection. This allows developers to specify UTXOs for use in channel creation or on-chain transactions. Along with the previously added support for transactions that draw funds from multiple sources (Partially Signed Bitcoin Transactions), lnd will be able to support more complex multi-party protocols in the future.

Developers exploring new Lightning use cases have asked for more granular control over how transactions are processed. This allows them to apply additional custom logic when deciding how and when to handle a particular transaction, rather than simply processing all transactions as immediately as possible. In lnd v0.11, the HTLC Interception API can support use cases like “notify to pay” which can send notifications to mobile users and wait to forward payments until the user reconnects to the network. lnd v0.11-beta also adds support for Hodl Keysend Payments which allows payment receivers to add checks (like ensuring a payment amount is correct) before accepting the funds.

In addition to more granular controls, developers have made a number of requests for more detailed information about the state of transactions processed by lnd. This additional information can be helpful when trying to help customers whose payments haven’t been completed or to help understand why a node or channel may not be behaving as expected. Some of the more detailed APIs include a more comprehensive CloseChannelSummary that provides additional detail about closed channels and a ListSweeps API that provides details about the set of transactions that have moved funds from Lightning channels and transactions back to on-chain addresses. Some smaller informational improvements were made as well.

For developers who use lnd’s REST API, there was a significant improvement, primarily enabling REST of all experimental APIs (subservers), including MPP payments. WebSockets support was also added to provide a better experience for REST developers using lnd’s streaming RPC calls.

Safety

lnd v0.11-beta contains several significant safety improvements. Static Channel Backups (SCB) have been made more robust. The API for PSBT channel funding was improved to make it harder to broadcast an unrecoverable transaction, and channel breach data is now properly cleaned up.

Under the hood

In lnd v0.11-beta, there were a number of underlying changes made that will be less visible to users. Indexing by payment_addr is a necessary change for the development of Atomic Multipath Payments (AMP). The build process was also improved for lnd’s code contributors, making it easier to test additional operating systems. The modularization and isolation of lnd packages were also improved.

Conclusion

Shipping Wumbo and lnd v0.11-beta is a significant milestone for lnd, signaling a major step towards a more mature network. We are committed to building products that make it easier for others to build on Lightning, and we hope lifting payment limits will make the network more flexible and efficent for users, node operators, and businesses.

We’re inspired by the work done by those in the Lightning community, and we featured many of their latest developments in our most recent newsletter. We greatly appreciate those of you who have worked with us on lnd in any capacity (coding, testing, suggesting, bug reporting, questioning) and also Spongebob Squarepants for his contribution of endless Wumbo memes. If you haven’t already, please join the lnd Slack, reach out on Twitter, email us, join the lnd mailing list, or subscribe to our newsletter!