Lightning 2020: A Toolkit for Heretical Web3 Developers

Many developers and investors interested in building Web3 gave up on building on top of Bitcoin years ago, assuming that its limited throughput, high latency, and conservative programmability made such development impossible. Indeed, this is precisely what led to the birth of Ethereum, and a plethora of Web3 platforms (e.g. Arweave, Cosmos, Polkadot, Solana, Near) that developers are leveraging today. These new platforms offer functionality that has been considered to be impossible on top of Bitcoin... until now.

The Lightning Network is viewed by most as a decentralized, permissionless Visa network for Bitcoin, bringing high throughput and low latency payments to the network. This is easy to grasp, but there is more to the story. The Lightning Network also provides more advanced programmability thanks to two recent technical developments:

1. Persistent, self-sovereign identity and authentication, which are made possible by macaroons, Lightning Service Authentication Tokens (LSATs), and generic digital bearer asset tokens
2. Arbitrary data payloads, which are made possible by Type-Length-Values (TLVs), Keysend, and HORNET

In this essay, I'll examine how these two new emerging primitives expand the Lightning Network beyond just payments and into the realm of robust Web3 utilities. The Lightning Network is maturing into a new self-sovereign authentication and data network—with payments embedded as a first-class citizen. But first, let’s review the current state of the Lightning Network.

State of Lightning: Payment Channels & HTLCs

As described in the 2015 paper, the Lightning Network facilitates bidirectional payment channels chained together using HTLCs. If that doesn’t mean anything to you, I recommend Radar’s ION Wiki as a great resource to get up to speed.

In the five years since its proposal, the Lightning Network has grown at a rapid pace. There are three major client implementations: lnd from Lighting Labs, eclair from ACINQ, and c-lightning from Blockstream. The live network has an estimated 6,500 nodes, 60,000 channels, and 1,070 BTC of capacity (~$9M). Lightning Networks startups raised ~$40M in 2019, and mature businesses like Bitrefill and Bitfinex are utilizing the technology in production.

As a point of evidence in how fast this ecosystem is progressing, let’s consider one of the remaining UX hurdles for the ecosystem: user onboarding—i.e., how quickly Alice can:

1. download a wallet
2. purchase BTC
3. open a channel
4. successfully make (or receive) a payment

To solve this problem, Bitrefill pioneered Thor channels, which allow users to purchase a channel of BTC and transact before it has been confirmed on-chain. New solutions like Zap’s Strike, and Escher App have lowered the fiat-to-BTC barrier from 24 hours to 15 seconds, requiring only a one-time KYC check and a couple clicks. Sats-back reward offerings like Fold, Lolli, Blockrize and Pei launched to make this even easier by letting users passively earn BTC. Gaming companies like Zebedee, Satoshis.games and Thndr Games are pushing the envelope even further by letting users earn BTC in-game and then immediately withdraw it to their wallets to be spent elsewhere.

All of these launched in the last year. I highlight them to stress that developer toolsets are already generally available today. Companies are building products with them, onboarding users, and solving real pain points today. Future protocol upgrades (e.g. Taproot, which enables PTLCs, and Eltoo, which enables Channel Factories) will further improve user privacy and lower total system fees, but should not require new tooling for developers to work with. The tooling is ready to go.

Emerging Technologies

With the core toolset described above, the Lightning Network can become Bitcoin’s Visa.

But the Lightning Network can be more than that; it can provide the foundation for Web3 development. These next two emerging technologies allow for that market expansion.

PERSISTENT, SELF-SOVEREIGN IDENTITY & AUTHENTICATION

One of the interesting quirks about the Lightning Network is that, unlike on Bitcoin’s base layer in which address reuse is discouraged, each node in the network must have a persistent identity because each node maintains persistent channels. That identity is a randomly generated public key that can be untethered from the user’s real world identity. Users don’t have to trust a third party to manage these identities; they are self-sovereign.

Web3 developers should already understand how a self-sovereign identity schema will dramatically alter the balance of power on the Web over the next 10 years. Multicoin’s Web3 Mega Thesis is “the unbundling of data and application logic.” Self-sovereign identity and payments allow for the first step in this paradigm shift: a strong decoupling of authentication and payment logic from application logic. Developers can use these tools to finally build and monetize applications that do not require each user to set up a profile first.

Image 1: I don’t know exactly what new UXs this will enable, but I know they’ll be important.

The Lightning Network is leveraging persistent node identities already in three separate ways:

1. Calculating a routing node’s reputation score based on publicly available variables such as uptime, fee rates, and channel age, number, and sizes. This score promises to inform nodes where their scarce liquidity can be most profitably allocated.
2. Creating macaroons (analogous to cookies, with more fine-grained permissioning) inside a node’s macaroon bakery, which give applications the authority to access specific functionality of the node like “Chat app X is allowed up to 100 sats/day of requests without requiring approval.” Nodes can then revoke an application’s authority at their discretion. (This is similar to advanced smart contract wallet features from teams like Torus, Argent, Gnosis, and Authereum.)
3. Generating Lightning Service Authentication Tokens (LSATs), a more advanced macaroon that Alice can purchase from a server and use in the future as an access credential e.g. “Alice is allowed to browse this webpage without logging in, but must pay 1 sat/second while browsing”.

Of these tools, LSATs are the most critical for Web3 developers. LSATs can be utilized to build a self-sovereign user login flow that’s identical to Oauth2 schemas, but without the trusted third party.

For those unfamiliar with Oauth2, here’s a brief primer. There are subtle but very important differences between this paradigm and the status quo (usernames and passwords). Web standards bodies have come to agree that requiring unique passwords across each site is not user-friendly and prone to password re-use, and are encouraging developers to move to an authentication-token standard.

Image 2: Google’s OAuth button, and resultant process

When users click “Sign-In with Google” to log-in to a website, users initiate the OAuth process shown above, in which authentication tokens replace usernames and passwords. This is much more user-friendly than requiring usernames and unique passwords across every website. However, the cost of this user-friendliness is that Google owns users’ online identity. They track which websites users log-in to, and have the power to refuse to authorize users’ access request.

Using LSATs on the Lightning Network, users can self-authenticate to web services and peers using sovereign secret keys with a UX that’s comparable to signing in with Google. This will have enormous implications for user privacy, and is a critical enabling piece of infrastructure for the unbundling of data ownership and application logic.

The Sphinx.Chat team and the Tierion team are both leveraging persistent, self-sovereign identity using the Lightning Network today:

1. Sphinx.Chat is leveraging users’ persistent identity to create proofs of payment with another type of bearer asset token called JSON Web Tokens (JWTs), which have been a traditional Web standard for a number of years. Here, after a user purchases a digital good such as an article over Lightning, their node will receive a JWT signed by the server that acts as a cryptographic receipt. With a receipt in hand, the user can return to the server in the future and retrieve the same article without having to store it locally or pay for it a second time. Critically, the server will know if the receipt has been transferred to a node that was not the original purchaser thanks to the node’s persistent identity.
2. Tierion is experimenting with macaroons and split payments to create new experiences. For example, Alice can sell an LSAT authorizing 30 seconds of free server access to Bob as long as Alice pays the server 10% of the sales price in a HODL invoice (basically a payment that is only settled once some external condition, like a related payment, is completed). In a way, this is a smart contract, as Alice is not able to redeem her proceeds from the secondary sale until after the server receives its cut.

ARBITRARY DATA PAYLOADS

Another interesting quirk about the Lightning Network is its similarity in construction to Tor, the anonymity network.

1. Both networks use onion routing to protect their senders and their receivers from surveilling third parties along the route’s path.
2. Both networks construct circuits through which data/payments are routed.
3. Type-Length-Values (TLVs) allow users to attach arbitrary data payloads to a payment, and Keysend allows users to send the preimage of a payment to a receiver without needing an invoice.

Using TLVs combined with Keysend, the Lightning Network becomes an incentivized, onion-routed data network. This means that any Lightning Network node can attach arbitrary data to a payment and send it over the network, ensuring it pays its way to its destination using a private path.

Additionally, the Lightning Network’s design actually fixes three of Tor’s major flaws:

1. The Lightning Network offers better privacy: the Tor Network does not incorporate mixing at the packet level, which leaves it vulnerable to correlation attacks. Lightning messages improve upon Tor’s by using the Sphinx format, which protects the network from correlation attacks by hiding circuit information (i.e. how long is a given circuit, and which hop in the circuit is a given node) from relay nodes.
2. The Lightning Network offers better decentralization: each Tor node relies on nine centralized Directory Authority (DA) servers for an updated look at which nodes were available for routing. Lightning nodes improve upon Tor’s by broadcasting gossip updates from the rest of the peers in the decentralized network (both at the base layer and at layer 2).
3. The Lightning Network offers better incentivization: Tor nodes cannot charge users for relaying data nor can they sell user data to third parties since all traffic is anonymized. Lightning nodes charge fees for relaying data by default.

Because of the third point, surveillers can run >50% of the Tor relayers for a relatively low cost. This has always been Tor’s Achilles Heel. There are about 6,000 Tor relays online today, all run by self-funded hobbyists or enthusiasts funded by various foundations.

There are already more Lightning nodes online than Tor relayers, some of whom are starting to become profitable solely by relaying payments. As traffic and network fees grow, node count will grow, and so the cost of owning >50% of the network will grow as well. This is a big deal.

Today, in its infancy, the Lightning Network provides a worse data layer than the Tor network. But as it matures it has the potential to provide a more private, more decentralized, and more sustainable data layer than the current state of the art. Like persistent, self-sovereign identity, a private data layer should be a crucial tool for Web3 developers looking to unbundle data ownership and application logic.

Putting It All Together

While the Web3 community has long had a vision for what end-user applications look like, they have never had the tools to build this future. The Lightning Network provides Web3 developers with three core new tools:

1. Instantaneous, permissionless micropayments
2. Persistent identity with self-sovereign programmable bearer assets
3. A private, incentivized data layer

With these new primitives, developers can finally start building applications that strongly decouple authentication and payment logic from application logic. Brand new online experiences will come of this, with micropayments for one-time paywall busting (no login or subscription required) as the lowest hanging fruit.

Image 3: Driving down costs increases demand (Jevon’s Paradox) and variance.

Paypal made it 10x easier to sell physical goods online, enabling eBay to become the world's bazaar. Stripe made it 10x easier to embed payments in any software service, enabling the explosion of online commerce over the last decade. The Lightning Network will make it 10x easier to send micropayments and arbitrary data directly to anonymous individuals or web services, enabling “new behavior and innovation that was never before possible” as Coinbase CEO Brian Armstrong noted.

Messaging applications on the Lightning Network like Whatsat, Sphinx.Chat, Shockwallet, and Juggernaut are a very interesting first attempt. Telegram, Signal, Kik, Line, Klaytn, and Whatsapp have raised billions of dollars to embed native cryptocurrency payments, validating the market for messaging-enabled micropayments. However, these incumbents are employing a top-down strategy to build a monetary network effect with their existing distribution. Lightning messaging apps will take a bottom-up approach that inherits Bitcoin’s global liquidity and cryptocurrency payments for free.

It will be very interesting to see which approach wins. In his seminal essay Why Decentralization Matters, Chris Dixon argues that centralized platforms inherently transition from providing value to extracting value from their respective ecosystems. These centralized messaging apps (Telegram in particular) have been friendly to third-party developers so far, but why should they trust that this time is different? Web3 developers should seek to build on an open, interoperable, permissionless standard, instead.

If you’re a Web3 developer interested in utilizing these new tools, please reach out via email (lightning at multicoin.capital) or via Twitter DMs.

Thanks to Kyle Samani, Ben Sparango, John Robert Reed, Elizabeth Stark, Jim Patterson, Paul Itoi, Joost Jager, and Buck Perley for reviewing previous drafts.