Lightning This Week | 602,888
E2E Chat, Lightning Offers and Better Channel Management
Hello Lightning enthusiasts — after 954 blocks we meet again for another session of Lightning This Week. A slightly longer one this week, so let’s get to it!
WhatSat — E2E Encrypted Authenticated Chat on LN
With the recent changes to the Lightning Network protocol, specifically the new TLV onion routing payloads, Joost was able to put together a forked version of LND that demonstrates how it could be used to create a censorship-resistant, peer-to-peer, end-to-end encrypted messaging protocol. The new changes make it trivial to attach arbitrary data, such as chat messages, to an ordinary Lightning payment.
A Lightning payment delivers the message, but no actual money is paid. Because the sender uses a random payment hash, the receiver is not able to settle the payment. The failure message that is returned to the sender serves as a delivery confirmation.
For this proof of concept chatting is entirely free due to the use of random payment hashes. That said, there is a future where these so-called free failure payments are also charged by nodes through a relay fee of some sort. Nodes could also begin rate-limiting other nodes that continuously produce failed payments like these.
Eventually the chat protocol could stop relying on these failed payments and move to settling millisatoshis at every hop. And if you add the upcoming Atomic Multi-path Payments (AMP) features to the mix, one could envision sending censorship-resistant messages of indefinite length at extreme low costs. There’s even a Twitter discussion around the monthly price that users would be willing to pay for a true E2E-encrypted onion-routed private messaging service.
Source Code: https://github.com/joostjager/whatsat
BOLT 12 Spec — Offers
The discussion around the specification for an Offers protocol on the Lightning Network has begun. BOLT 12 (or 13?) is a new mechanism to support offers and invoice requests. It consists of primarily two user flows:
- A user gets an
offer(looks like a normal Lightning invoice, but has thelnoprefix) and requests an invoice over the Lightning Network, obtaining one in return. - A user gets an
invoice request(lniprefix) and sends the invoice over the Lightning Network, retrieving an empty reply.
To understand more about Lightning Offers please refer to Rusty’s talk on The Lightning Conference, where he goes into detail about the many scenarios BOLT 12 can help address.
Mailing list discussion and specification rough draft: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002276.html
Advertised Unbalanced/Offline Channels in LND
LND recently merged a PR to improve the probabilistic estimation for untried payment connections. In a nutshell, from now on any advertised channels that are unbalanced and/or offline will begin to negatively impact the traffic that you see on your well-balanced channels. The aim here is to incentivize node operators to stay watchful of the health of their channels so as to invigorate the network and lead to less payment failures for users, especially against the infamous stuck-payment loops that happen in certain areas of the network.
LND PR: https://github.com/lightningnetwork/lnd/pull/3462
The new --routerrpc.aprioriweight configuration parameter takes a value in the range [0, 1] to define the node’s behavior with regards to historical payment routing results. A value of 1 will completely ignore the historical results, while a value of 0 will ignore the a priori probability completely and only rely on historical payment results (unless none are available). This allows operators to define how aggressive their peers should be penalized for their unhealthy channels. A low a priori value will force the node to quickly switch to using a different peer if a tried node doesn’t perform well. In hindsight, this puts more pressure on node operators —routing nodes need to meet expectations in order to keep forwarding transactions and generating revenue.
The Node Operator’s Guide to the Lightning Galaxy
Bryan Vu continues on his excellent series of detailed posts geared towards operators of routing Lightning Network nodes. In part 2 Bryan discusses the concept of node scoring and how that can help an operator identify the best nodes/peers to open (and maintain) channels with. Additionally it provides more in-depth details for operators on how to best configure their node settings in order to become more attractive to the Lightning Network core routing algorithms.
Blog post: https://blog.lightning.engineering/posts/2019/11/07/routing-guide-2.html
LND upcoming support for Bitcoin Core 0.19
As many of you are aware, the latest master branch of Bitcoin Core, as well as its release candidates for 0.19, do not work with latest 0.8.0 LND. This has been a longstanding issue and one that many users have run into. Thankfully there are now two pending PRs that address this incompatibility concern.
The incompatibility was due to the a modification to the sendrawtransaction API in Bitcoin Core, which now expects a numeric maxfeerate field, instead of a boolean value. This change forces a node to reject a transaction whose feerate is above the given fee rate — a safeguard for users who were accidentally overpaying transaction fees.
Bitcoin Core PR: https://github.com/bitcoin/bitcoin/pull/13541
LND PRs (pending): https://github.com/lightningnetwork/lnd/issues/3625 and https://github.com/lightningnetwork/lnd/pull/3649
BOLT 11 — Optional Vendor Field
There’s discussion around a new optional vendor field being added to the BOLT 11 (payment requests / invoices) specification. The idea behind the new field is to address certain real-world requirements with regards to payment receipts. Companies have primarily leveraged the general description field for these purposes but dividing the fields can drastically improve UX. Discussions are ongoing both on the PR and in the mailing list.
Specification PR: https://github.com/lightningnetwork/lightning-rfc/pull/694
Mailing list discussion: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002277.html
Java RPC Wrapper for C-Lightning
There is a new wrapper available for interfacing with C-Lightning’s RPC API, this time written in Java. What began as a simple PR is now a full-fledged library for engineers to use in their application development efforts.
The wrapper aims to be versatile, the final version should allow the user to execute commands even of custom plugins, allowing them to write the code for the command.
If you use C-Lightning in a Java application stack please help test and triage the new library.
Library Source Code: https://github.com/vincenzopalazzo/JRPClightning
Documentation: https://vincenzopalazzo.github.io/JRPClightning/
Potential Minor Sphinx Privacy Leak (and Patch)
A new paper analyzing the security of the Sphinx scheme (onion routing scheme used in the Lightning Network) has been released. In Roasbeef’s own words:
- The Sphinx paper proved various aspects of its security using a model for onion routing originally put forth by Camenisch and Lysyanskaya.
- This new paper discovered that certain security notions put forth in that paper weren't actually practically achievable by real-world onion routing implementations (in this case Onion-Correctness), or weren't entirely correct or additive.
- New stronger security notions are put forth in response, along with extensions to the original Sphinx mix-net packet format that achieve these notions.
Mailing list discussion: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-November/002288.html
BOLT Spec PRs: https://github.com/lightningnetwork/lightning-onion/pull/40 and https://github.com/lightningnetwork/lightning-rfc/pull/697
C-Lightning PR: https://github.com/ElementsProject/lightning/pull/3246
That is all for Lightning This Week. As usual, if I’ve missed any major happenings in the Lightning stratosphere please let me know through the comments or on Twitter.
ZEBEDEE’s mission is to develop software and infrastructure to introduce first-class Bitcoin and Lightning support into digital experiences and gaming environments. This allows players, developers, streamers, and watchers to interact and instantly exchange value in a frictionless manner.
