Latest Strikes 47 - July 24th-31st 2023

Last week was another vibrant one for Lightning: a new implementation was announced, grants rained down on developers and funding software blossomed. Last week also some interesting discussions around self-custody, privacy and decentralization. Let's dive in!

Ecosystem

It's Raining Grants

The Humans Right Foundations (HRF) launched a new campaign called the Bitcoin Bounty Challenge. Unlike more traditional grants compensating a researcher or a developer's work on a topic (for example, Splicing or StratumV2), this "challenges" are quite specific. Indeed, the 20 BTC (!) amount set for the campaign is split equally between 10 challenges/bounties ranging from privacy to user experience.

Regarding Lightning specifically, 4 BTC are on the table: 2 for a "human-readable bolt 12 offer generator" and 2 for an "easy-to-setup self-custodial mobile Lightning address generator". Both generators would have to be integrated into a popular iOS or Android Bitcoin wallet to be eligible for the bounty.

It's quite awesome to see this kind of money being used to fund open source Bitcoin and Lightning development! However, the campaign also sparked some legitimate criticism, focusing on 2 main aspects: the technical limitations of some of the grants, as well as the influence the HRF is gaining over Bitcoin development through this kind of very targeted bounties.

Regarding the latter, it may serve as a reminder that open source funding is a hard problem. Generally-speaking, I'd say broader grants seem better, both in terms of governance and because they give more room to the grantee to choose a fitting solution. However, I don't think bounties like the HRF Challenge are such a threat: should a backed solution be inherently wrong, all that would be lost would be mostly money and development time. It is always possible to build better solutions, and compete.

However, when it comes to the actual technical feasibility or opportunity of some of the bounties, there is also valid criticism to be had. For example, the idea of an "easy-to-setup self-custodial mobile Lightning Address" seems inherently impossible due to the way Lightning Addresses work. Some tradeoffs could be made to make it as trustless as possible, but in the end a Lightning Address still requires a web server somewhere. If the server is not yours, it can silently siphon incoming payments, and is hence not "self-custodial". We can see clearly here how a broader scope could have made better use of the bounty's money and developers time: instead of focusing on a specific technology (Lightning Addresses), it could have been worthwhile to focus on the actual desired outcome (receiving Lightning payments to a static payment code while using a mobile self-custodial wallet).

On How Custodians Can Facilitate The Journey To Self-Custody

Arvin from Galoy (creator of the Blink wallet) shared some insights as to how (and why) custodians could play a pivotal role in their users journey from using custodial services to self-custody. To put it in a nutshell, custodians are on the best position to do this work, since they are the solution currently being used by users who'd need to transition. By having their UX mimic closely the way a self-custodial wallet works and providing an easy way to switch to self-custody, as well as providing educational material, custodial wallets could help foster self-custody.

When it comes to Lightning, Arvin also highlights how game-changing solutions such as Blockstream's Greenlight and the Breez SDK are. With these, users are fully in control of their keys and the wallet operator is not a custodian any more, but merely an LSP. The only added complexity for the user with respect to a custodial wallet is that they need to backup their seed, but this process could be made easier with good design. The only tradeoff, as Arvin highlights, is that to have the same experience as a custodial wallet (notably being able to just open the app and send a payment instantly), the LSP would need to construct the payment's route themselves, and would hence know the amount and destination of the payment. However, this is already the case with custodial solutions ; and this issue could be mitigated by using Trampoline Routing (as Acinq does in their Phoenix wallet).

Extending on this topic, Tony Giorgio also published an interesting article last week discussing how every app could integrate Lightning in a self-custodial and privacy-preserving way someday. He highlights some of the current limitations, such as the impossibility to receive while offline and the difficulty of running a node in any environment, and which solutions (async payments, lightweight nodes such as Mutiny) are being designed and built right now to address said limitations. The road is still long and will certainly be hard to follow, but there's a desirable destination we can all focus on.

Funding Developers With Lightning

The Alby team officially released a nice new tool last week. PkgZap gives a way for NodeJS developers to easily fund the packages they're relying upon for their project. Indeed, it is a common software development practice to rely on open source packages and libraries that handle a specific set of tasks (say, for example, generating QR codes from text) instead of reinventing the wheel every time. Although it isn't without tradeoffs, some languages such as Javascript usually rely more or less extensively on using third party packages. For example NodeJS (let's say it's a "flavour" of Javascript) has a tool called NPM (Node Package Manager) to easily import and use existing packages into a project.

NPM already has a funding tool allowing package developers to indicate the link to their donation page, and other developers can see the donation links of all the packages their project depends on in just one command. If a package developer puts a Lightning Address as their donation link, then potential funders can see it, but they still have to manually donate to each package. Alby is taking this a step further with this new tool: as a supporter you can now connect your wallet to the the PkgZap once using Nostr Wallet Connect (NWC), set the total amount you wish to donate, and it will automatically be split and sent to all the packages that feature a Lightning Address as their donation method. Neat!

On Zaps

You can now donate to Geyser projects directly from your favorite Nostr clients, thanks to the power of Zaps! The project creator just needs to have their geyser.fund Lightning address on their Nostr profiles, and all zaps sent will be displayed in the project's Geyser page as donations. And, as always, Geyser can't touch the money and only acts as a trustless proxy between a project and their supporters.

That's a very cool feature and is a perfect illustration of how one's Nostr profile could act as their online identity between different platforms - but only if they so desire.

Come Meet Us At Surfin'Bitcoin

LN Markets will be at Surfin'Bitcoin in France on August 23rd to 25th, represented by our very own Théo Pantamis. Théo will give a talk on Friday morning on how to use DLCs (Discreet Log Contracts) for self-custodial trading! In the meantime, you can take a look at the articles he already published on the matter, starting here.

Wallets & Tools

New BTCPay Release

We got a new major BTCPay release last week. This new version of the iconic payment processing software brings enhancements to the store creation flow, refreshes the Point of Sale cart view, adds sounds for physical PoS, as well as new reporting features to easily access exploitable data for store managers.

Spec & Implems

A New Implementation

A new Lightning implementation was spotted last week! "Orage" (French for thunder) is a server Lightning implementation which goal is to simplify the onboarding experience to Lightning, thus making it easier to develop Lightning-aware applications - or plug existing applications to the Lightning Network. It puts an emphasis on high-availability, security and modularity, with the goal to feature dual-funding, splicing, trampoline routing, asynchronous payments, as well as the whole LSP toolchain.

Orage hence resonates with the "Lightning Everywhere" piece we covered above. The goal is the same: facilitate the integration of Lightning into applications, as well as the onboarding process, both for individuals and businesses. The project is still in an experimental state, but we'll definitely keep an eye on it.

Blinded Paths Doom Scenario

There was an interesting discussion on the Lighting-Dev mailing list last week around the potential impact of Blinded Paths on both network decentralization and privacy. As a reminder, Blinded Paths (also known as Route Blinding) are a coming update to the Lightning Network stack that aim at improving receiver privacy when transacting on Lightning. Indeed, as of today, the privacy for the receiver of a payment is quite bad, because the whole route of a payment (e.g. the set of Lightning channels that will be used to forward this payment from the sender to the receiver) is established solely by the sender. The sender hence needs to know the receiver's public key in order to locate them on the network, which in turn exposes some information about the receiver, such as the UTXOs (and hence coin history) associated with any announced ("public") channel they've established.

On the other hand, with Blinded Paths, the receiver also partakes in the creation of the route. They compute a route from another node (let's call them Isabel) on the network to them, encrypt this route so that only Isabel can read it, and send the encrypted route and Isabel's public key to the sender of the payment, inside the invoice. Now all the sender has to do is compute the first part of the route between them and Isabel, and send the payment this way with the encrypted, second part of the route attached. When the payment reaches Isabel, they can decrypt the route but, as it's still using Onion routing, all they see is the next node to forward the payment to, and so on.

TL;DR: Blinded Paths split the task of route selection between sender and receiver, each being responsible for their "half" of the route. This enhances receiver privacy by concealing their "identity" among an anonymity set comprised of all the nodes located at a certain distance from the node at the merging of both route fragments.

However Ben Carman, seconded by Tony Giorgio, highlighted a scenario in which Blinded Paths could significantly reduce the sender's privacy, as well as damage the network's decentralization.

Indeed, with Blinded Path, the recipient can force the sender's payment to go through a specific set of nodes (the ones they are selecting in their part of the route).These nodes can for example be surveillance nodes that together cover a large area of the network, meaning any payment sender selecting a route has a high probability of selecting at least one of them in their own part of the route. Additionally, using some basic heuristics (which all have their limitations) such as the smallest-route heuristic and amount/timing correlations, and directing the flow of payments via fees, the surveillance system could potentially de-anonymize the sender with a certain level of confidence.

Of course this attack scenario may seem a bit far-fetched, but the magnitude of what is at stake here commands conservatism. We already know that companies such as Chainalysis are looking closely into the Lightning Network, and compliance requirements (especially in the US) are already pushing some companies to only establish channels with other trusted entities. Such a surveillance mechanism, where the receiving entity must include surveillance nodes in their blinded path, would only be an additional step in the same direction.

However, this does not mean we should refrain from implementing Blinded Paths. Setting aside regulated entities, this new mechanism would still enhance receiver's privacy by a great order of magnitude. If anything, this "doom scenario" once again highlights the importance of non-deterministic route selection for privacy-concerned senders. To compose a payment's route, channels should not be selected solely based on "merit" (low fees, high speed, high availability) but at least partly at random. This is already the case in many implementations, but becomes of even higher importance with Blinded Paths in place, as it solves both decentralization and sender privacy concerns.

Closing Bit

C'est un curieux vallon :
Tapi dans l'ombre
Il semble écouter
La mer rougir.