Lightning This Week #658,364
Lightning Network static QR codes for livestreaming, new incoming-channel configurations on LND, and in-depth backup strategies for C-Lightning
Hello Lightning enthusiasts. Another ~1,000 blocks gone, another Lightning This Week edition. No dilly dally today, cutting right into it, let's do this!
Lightning Network Static QR Codes
Last week ZEBEDEE released the zbd.gg companion app to the ZEBEDEE Wallet, which provides every wallet holder with a dedicated zbd.gg webpage linked to their unique ZEBEDEE gamertag providing a programmable, multi-use, interoperable QR code to accept payments of any amount with full commenting support.
One use for these new static QR codes that has become a quick favorite is in Livestreaming. Say you’re on a quest with your guild while streaming to Twitch, and you need some money to heal your character before tackling the final boss. Well, now it’s as easy as asking your Twitch viewers to scan the QR code on the screen. They’ll be able to send you emergency funds, along with a message, and participate in the quest that they helped make real.
Above you see MrCrazyJarvis and Christian Moss streaming and displaying their QR codes to receive tips and messages from their audience of viewers, directly to their ZEBEDEE Wallet mobile app. No longer are audience members simply passive participants in online events. Static QR codes help break the 4th-wall by allowing streamers to interact directly with their viewership through instantaneous micropayments and messages.
Value on the internet is no longer bound by a game, platform, or universe. Now internet money is accepted across any reality. All worlds speak Bitcoin.
ZEBEDEE QR codes are fixed QR codes that do not change, even when their underlying properties do. This enables interesting scenarios such as using QR codes for streaming, donations, and even in entirely offline environments.
While vital to the functionality of the network, Lightning Network invoices (BOLT11) have two major limitations: they are single-use and have a defined expiration time. While this lays out a great experience when performing on-demand or in person (IRL) payments, where sender and receiver are only interacting for an expected short period of time, it fails to provide similar flows online and in virtual environments. In these virtual scenarios, there may be many senders for each individual recipient, and payments may not be performed immediately after issuance of a payment request QR code. For example, if a popular game streamer is interacting with thousands of fans and viewers through a multi-hour stream, it would be impossible to create a single-use QR code for each of them.
This is where ZEBEDEE Static QR codes come in, powered by the LNURL Pay protocol. We empower you with a simple QR code that can be used in any setting, for an indefinite amount of time, to receive unlimited payments and messages from just about anyone in the Bitcoin Lightning economy — all tied to your ZEBEDEE Wallet and personal gamertag. Because Static QR codes are so versatile, your zbd.gg webpage can be used by your friends, colleagues, workmates, or guild buddies to pay, tip, gift, and send messages for as little as 1 satoshi.
Download ZEBEDEE Wallet here to get started!
CSV Configuration Options for LND
LND recently merged PR 4735 which adds further configuration control to the CSV (CHECKSEQUENCEVERIFY) delay of channels. Specifically this PR adds a new option MaxLocalCSV which specifies the maximum delay that the node will accept from a remote peer.
CSVs are a way to dynamically lock up the coins in the channel over a predefined time interval, and is enforced by the Bitcoin blockchain rather than the peer nodes themselves. CSVs will check for the current block height (the sequence) from the moment the transaction is included in a block, and will verify that the encumbrance scripts are met.
This change allows users to set a maximum CSV value that suits their specific use case and time preference. For example, given a channel between Alice and Bob, if Bob attempts to broadcast a false commitment transaction to attempt to fraudulently force close and give him all the funds in the channel, it is the CSV timelock that provides Alice a window of time to provide a breach remedy by broadcasting a penalty transaction.
Currently, CSV values are capped at 144 blocks, as an insurance that node operators won't set an unreasonably low CSV, possibly resulting in no channels ever succeeding.
Check the PR and the code diff here: https://github.com/lightningnetwork/lnd/pull/4735.
Backup Strategies for C-Lightning Operators
Managing a Lightning Network node is an active role. Node operators must ensure their nodes are available and online at all times, maintain an appropriate amount of well-balanced channels with well-connected peers, and take all precautions to ensure critical access keys/macaroons aren't improperly exposed. And while your Bitcoin node can re-fetch all of its blockchain data from any of its peers in case of disk failure/corruption, the same cannot be said about your Lightning nodes.
Lightning is an offchain protocol in which connected peers in the network can create channels with each other other, allowing for easy flow of funds. Every channel in Lightning has a state — a representation of the distribution of funds in that channel between the two peers. If Alice has a channel with Bob with 50,000 satoshis deployed, and Alice sends Bob 20,000 satoshis, the channel state must be updated to represent that payment accordingly, but this update is only ever visible by the two connected peers.
In other words, your Bitcoin onchain activity is recorded in all Bitcoin archival full nodes, so if you forget all your onchain activity because your storage got fried, you just go re-download the activity from your nearest peer.
But in Lightning, since you are the only one storing all your financial information, you cannot recover this financial information anywhere else. This means that on Lightning, you have to responsibly back up your financial information yourself, using various processes and automation.
Because of this every node operator should treat backing up their node's channel state with utmost priority. With that in mind the C-Lightning team has begun work on documenting the preferred/suggested ways of performing backups of your node's state, such that if an unfortunate situation occurs, you have defined paths and processes to safely attempt full recovery of funds, both onchain and offchain.
The document details the differences in sufficient criteria for recovering onchain vs offchain funds, and explains in length 4 different strategies for backing up offchain channel state: database file backups, RAID-based file system redundancy, remote NFS mounts, and PostgreSQL database clusters. Each of these have pros and cons, which depend on access to resources and backup/security-level choices.
I'd encourage any C-Lightning node operator to read through it: click here to read the Backup Strategies for C-Lightning (NOTE: PR still to be merged, so there could be changes to the document).
BONUS: C-Lightning has just tagged the v0.9.2 release but no changelog or announcement has been posted yet — probably something to look out for this week.
Channel Acceptors APIs
When managing a Lightning Network node, one mustn't accept just about any channels that are opened towards one’s node. This is why node implementations provide the ability to set minimum and maximum channel sizes, channel fee-rates, CSV timelock durations, etc. These are the criteria that allow a node operator to select which incoming peers they'd wish to have. That said, these are mostly non-interactive processes, and done automatically by node software — e.g. if my channel open request does not meet the necessary criteria, an error is thrown with a message to the peer.
While LND has had APIs to allow for interactively accepting or rejecting incoming channel openings, these didn’t provide much in the way of customization, until recently with the merge of PR 4683. If you rejected a channel with the ChannelAcceptor you were unable to send a message to let the peer know why that channel open was cancelled. Additionally, if you accepted a channel with the ChannelAcceptor API, you couldn't specify things such as close address destination.
This PR adds upfront shutdown, custom error support, and more fields that the ChannelAcceptor API can use, providing operators with more control over their incoming channel parameters.
With these changes, the ChannelAcceptor API becomes more useful as you can not only specify a custom error message, but also choose an upfront closing address for that channel.
Check the PR and the code diff here: https://github.com/lightningnetwork/lnd/pull/4683
Things I Would Share This Week
MintGox #009 on November 29th 2020 — join us in this month's installment of MintGox, the Bitcoin Esports event, this time hosting tournaments for Bitcoin Bounty Hunt, Bitcoin Rally, Turbo84 and Sarutobi (play games and stack sats across mobile and desktop/web)
PostgreSQL Benchmarks: Apple ARM M1 MacBook Pro 2020 — If you've been following the latest releases and announcements from Apple regarding their new M1 ARM chip, you'd enjoy this read. In my opinion Apple just once again made the MacBook Air the lead/role model of tremendous processing power in small laptops.
Booting FreeDOS from a Vynil record — A lot of people have a lot of time in their hands, and when that happens someone is bound to try running an OS from a vinyl record. Because why the hell not?
That's all for Lightning This Week. See you all in ~1,000 blocks.
Note: If I have misrepresented you or your company/project please reach out.