Lightning This Week #662,816
ZEBEDEE's LN-gaming integration, new Lightning channel backup strategies, v0.12 LND release candidate, multi-node Eclair support, and the Kraken has risen!
Hello and welcome to this week’s LTW. This is the last edition of 2020, so let’s make it a big one! To start off I’d like to invite you all to participate in this weekend’s MintGox Bitcoin-powered ESports Tournament on the 27th of December at 2PM EST. It is free for everyone to participate. All you need is a Lightning wallet like this one and you can win prizes of up to 1 million satoshis by playing online video game tournaments against other LN-gaming enthusiasts from around the globe.
MintGox #010 has a total event prize pool of 10,000,000 satoshis, and in addition to the community favorites Bitcoin Bounty Hunt, Turbo84, and Bitcoin Rally, the ZEBEDEE team will be announcing our latest Lightning Network gaming integration into one of the world’s most popular online games. You don’t want to miss this exciting event, one where it’s virtually impossible not to stack many sats.
The Kraken has risen
Kraken exchange has recently announced they will be supporting deposits and withdrawals through the Lightning Network starting mid-2021. In an interview with CoinDesk, Pierre Rochard from the Kraken team mentions that the recent improvements around Wumbo channels (large LN channels) and Multi-Path Payments (large payments that can be split automatically) were among the many reasons Kraken believes the network has matured, and thus the team is ready to integrate.
While there is still some time before any Lightning features are ready for primetime usage by Kraken users, it is great to see large players in the Bitcoin ecosystem gaining conviction about Lightning’s capabilities as a frictionless, cost-efficient transactional layer for Bitcoin.
“In 2021, we are committed to hiring a team to focus specifically on the Lightning Network, as part of our continuing effort to deliver the best possible experience for traders and investors. We expect to allow clients to withdraw and deposit Bitcoin on Lightning in the first half of 2021, which will allow clients to move their Bitcoin instantly and with the lowest fees.”
Kraken hopes to initially release a set of Lightning Network APIs, with support for LN withdrawals, and then follow that with iterative developments and features.
Official Kraken Press Release: https://blog.kraken.com/post/7225/a-need-for-speed-kraken-to-launch-bitcoin-lightning-%E2%9A%A1%EF%B8%8F-integration-in-2021/
LND v0.12 Release Candidate 2
The Lightning Labs team just posted a new Release Candidate for LND v0.12. The new major version of the software brings a lot of exciting features and improvements, specifically as it relates to committing/merging code that provides support for some LN protocol updates worked on throughout the year. Below I highlight a few of the features that a node operator should look out for in the new version.
PSBT Support
The LND internal onchain wallet can now create and sign PSBTs. In combination with the ListUnspent RPC this allows users to implement full coin control.
The feature also brings us closer to the future of having true watch-only onchain wallets powering LND, where an online node would only have public keys to track the UTXO’s, and can then delegate signing to an offline HSM or other LND node that has the private keys.
Anchor Channels
While Anchor Channels have been available to all LND users from v0.10 onwards, LND will now default to using this new channel type if both peers support it.
Anchor Outputs are special outputs in LN commitment transactions that are designed to allow the transaction to be fee-bumped.
The Anchor Channel type is a new type of channel that is much safer in high onchain fee scenarios, as it allows for bumping the fees after the channel has been force closed, instead of making the peers agree on a future close fee during channel opening. It also allows for a different economic model of fee-handling that puts the burden of paying chain fees on the peer that wants the channel close to happen the quickest.
This is also a nice improvement as less of the channel capacity needs to go towards the commitment fee reserve, and can instead be used for payments. In addition it allows bundling multiple HTLC transactions together into one, potentially saving on chain fees in force close scenarios. The commitment transaction still needs to be signed up front with a fee that ensures its mempool acceptance, and this fee now defaults to 10 sat/vbyte. An operator can configure this further by using the new --max-commit-fee-rate-anchors flag.
If you would like to opt-out of using Anchor Channels altogether, you must use the new --protocol.no-anchors flag to disable it.
Multi-Node Management
Gone are the days where an LND node was required to create on-disk unencrypted admin credential macaroons. With v0.12, hosting nodes on cloud hardware was made much safer by adding a stateless initialization mode that instructs LND to not store any unencrypted macaroons on the file system. Instead, the admin macaroon is returned in the response of the wallet creation request and must be stored by the caller of that request. One can now effectively spin up LND nodes in cloud providers like AWS / Azure and rest assured that the provider does not have access to the admin credential macaroons.
There are many more PRs and commits merged into this new release, for a full set of changelogs, refer to the Release Notes for v0.12.
New Channel Recovery & Backup Strategies
Given that the Lightning Network is an off-chain distributed system, and that channel state is only ever stored by its two connected peers, backups of channel state are of the utmost importance for node operators. In the current setup for Static Channel Backups (SCB), you must create a new backup each time you open / close a new channel. While SCBs are a great way to achieve fast recovery of funds, if for whatever reason you fail to create a backup when a new channel is opened, the only next option is to wait for your peer to close that channel on their own.
Lloyd Fournier recently posted to the Lightning Dev mailing list proposing a different approach to achieve fast recovery of channel state/funds without the need for static channel backups. By leveraging a deterministic key derivation method, your node would be able to search through the list of public Lightning nodes, combine information about the private keys derived from your node’s HD wallet with information about each node’s public key, and determine whether or not it had a channel with you (note: this backup strategy would only work for public channels).
Another proposal by Fournier that was posted to the Lighting Dev mailing list was the Covert Channel Recovery through Oblivious Signatures. In current LN, the existing mechanism to close a channel requires that your peer broadcast their unilateral commitment transaction. It’d be much cleaner and better if the commitment transaction was instead a mutual close transaction — less fees, not easily identifiable as an LN channel transaction onchain, and immediate access to funds. However a mutual close transaction does not support LN’s penalty mechanism, so if you request a channel close and your peer gives you an incorrect mutual close transaction (with less funds towards you for example), you’re unable to penalize them. While this isn’t technically a problem if you have the latest channel state, if you’ve lost your state / were unable to back it up, you’re now out of luck.
Fournier’s suggestion is to rely on oblivious signatures, which use a cryptographic primitive called oblivious transfer, which in short allows your peer to send you their mutual close transaction in an encrypted manner. Once received, you will be able to either use the transaction as is, thus closing the channel, or to prove that the transaction data cannot be decrypted, thus maintaining the channel active. The assumption here is that by using this oblivious transfer procedure every time your node reconnects to your channels, you wouldn’t need to reveal to your peers that you have lost any channel state data until after they’ve provided you all the information you would need to recover it.
Interesting new concepts proposed by Fournier on backing up channel state and fast recovery of channel funds. If you’re interested to read more details on the proposals, check the mailing list posts below:
Covert channel recovery with Oblivious Signatures: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002911.html
Recovery of Lightning channels without backups: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002911.html
Eclair in Enterprise Environments
When running Lightning Network nodes at scale, among many other things, operators need to be concerned about general node availability and redundancy. What happens if the node becomes unreachable or simply crashes? Does your node infrastructure setup have automated failover support? Do you have a disaster plan in place?
A concept familiar to most cloud engineers is high-availability (HA) — a system characteristic that aims to ensure uptime/operational performance under any circumstances. It is very common for essential services/servers to have at least 2 running instances — if something happens to one, the second instance can step in and handle requests/load. Up to this point it hasn’t been clear how to achieve a true high-availability infrastructure setup with Lightning Network nodes, as most of the node software itself has been tightly coupled with the data and networking layers.
PR #1566 changes this story for Eclair nodes. It merges code that provides Eclair operators for a way to run a `front-node` — essentially an Eclair node that abstracts out all of the connection-handling/messaging to and from the network, and allows it to be distributed across many Eclair instances. This provides a solution to achieve high-availability (HA) when running Eclair in production environments. As you can see from the diagram above, if one of your Eclair `front-node` crashes, another `front-node` can handle the load while a new ephemeral instance is spun up to replace it.
Another benefit of this separation is that CPU/bandwidth-intensive messages to handle node and channel discovery can also be handled by these `front-nodes`. Gossip messages, and channel syncing requests can now be taken care of by ephemeral, highly-available and fault-tolerant, distributed Eclair instances inside your production environments.
If you’d like to learn more about running Eclair in enterprise production environments refer to SuredBits latest field report, courtesy of Bitcoin Optech.
Things I Would Share This Week
Bitcoin Optech 2020 Year In Review — Another year has gone by, another amazing Bitcoin Optech YIR newsletter. This is a must read as it covers all sorts of Bitcoin and Lightning protocol developments, including DLCs, Wumbo channels, Bitcoin Vaults, CoinSwap, PayJoin, MuSig2, Taproot, LN Pool and much much more.
Lightning Network node provider Voltage adds ThunderHub support — If you’ve ever wanted to spin up a cloud-based Lightning Network node, look no further than Voltage. The team just released one of their customers’ most-wanted features: native ThunderHub support. ThunderHub is an open-source Lightning Network node manager that provides a great dashboard interface to use and manage your Lightning node. Starting today you can deploy a ThunderHub dashboard for all your Voltage nodes with a single click.
We rendered a million web pages to find out what makes the web slow — This group analyzed the top 1 million pages on the web and tracked just about every conceivable metric, producing the first data-set to connect performance, error tracking and library-use on the web. The article thoroughly analyzes what the data can tell us about creating high performance modern web sites.
That's all for Lightning This Week. Happy Holidays and Merry Xmas from myself and the ZEBEDEE team. I look forward to bringing you weekly Lightning Network updates in 2021. See you in ~1,000 blocks.