Brandon Lucas

Micropayments and the Lightning Network

Content monetization on the internet is broken. Credit card fees prohibit the ability to make small payments for individual pieces of content. Creators have to choose between invading user privacy by selling their data, annoying them with a barrage of ads, or putting up paywalls and forcing them to sign up for subscriptions to continue. The Lightning Network offers a new, alternative monetization strategy in the form of micropayments.

Check out the Voltage presentation on this topic here.

If you're interested in learning more about the history of micropayments, check out Amber Case's article and the Open Index Protocol's episode

Before Bitcoin

Before the World Wide Web, the internet, or even the personal computer revolution, the concept of making tiny payments in exchange for digital content had already been conceptualized. The term “micropayment” can be traced back to Ted Nelson as early as 1960, when he began brainstorming his ideas for what a globally accessible, computer-based repository of human knowledge could look like, and coined many other terms and ideas that are used on the web today, like “hypertext” and “hypermedia”. While often failing to implement his own vision for the web (and being vocally regretful of how the web took shape), others took many of his ideas and built them into what we know it as today.

In 1992, Tim Berners-Lee, creator of HTTP and HTML, released his second version of HTTP and the first reference to the status codes now in common use. Among them was a code that Berners-Lee and others thought would one day be used to pay for digital content: 402 payment required. Sadly, this status code is officially “reserved for future use”, as the various attempts to make micropayments on the web, from its inception, failed to come to fruition. Over 30 years after the invention of the internet, we’re still waiting for one of its major original visions to be fulfilled.

Berners-Lee founded the World Wide Web Consortium (W3C) in 1994 to guide the development of the web, and micropayments were a major consideration from the start. In 1995, Phillip Hallam-Baker, who wrote a number of RFCs on internet security, drafted the Micro Payment Transfer Protocol (MPTP), which never seems to have been implemented. It offers a number of insights on the nature of micropayments that are as relevant today as they were at the founding of the internet:

There is a large interest in payment systems which support charging relatively small amounts for a unit of information. Here the speed and cost of processing payments are critical factors in assessing a schemes usability. Fast user response is essential if the user is to be encouraged to make a large number of purchases.

A critical limitation of MPTP, however, was that a third party, referred to as a broker, was explicitly required by the protocol.

At the time, there was no way to make a digital payment without a trusted mediator, so any attempt at a protocol for micropayments had to be developed with some sort of custodianship of the money in mind.

The W3C continued to push for micropayments for a while, in 1998 publishing an overview of micropayments and suggesting MPTP as a practical approach and noting:

Micropayments have to be suitable for the sale of non-tangible goods over the Internet […] With the rising importance of intangible (e.g. information) goods in global economies and their instantaneous delivery at negligible cost, "conventional" payment methods tend to be more expensive than the actual product.

This echoes Hallam-Baker’s second major concern of transaction costs imposed by technological or overhead costs of available payment mechanisms. His first concern, the need for a “fast user response”, is often overlooked in discussions about the viability of micropayments. But one astute observer, who would later go on to have a strong influence on the development of Bitcoin, was already thinking in depth about this problem. Nick Szabo, creator of the concept of smart contracts and Bitgold, wrote “Micropayments and Mental Transaction Costs” in 1999. Szabo states that the primary reason for the failure of micropayments to take hold was not due to technological or overhead costs. It was due to the mental transaction cost experienced by the user of having to decide whether a purchase was worth the price for every interaction on the internet.

[…] customer mental transaction costs are significant and ubiquitous, so much so that in real world circumstance cognitive costs usually well outweigh technological costs, and indeed technological resources are best applied towards the objective of reducing cognitive costs. […] Micropayment technology efforts which stress technological savings over cognitive savings will become irrelevant.

A web based on micropayments implies frequent purchases, which implies decision fatigue. It is likely the case that for most micropayments, the mental transaction cost incurred by having to make constant choices about purchases likely outweighs the value of what they’re paying for.

Large companies like Compaq and IBM, and startups like Pay2See, Millicent, iPin, and others, tried their hand at reducing these technological and mental transaction costs for micropayments in the early days, and it was still an assumption that the concept would be a lasting feature from the start.

Perhaps the most notable of these companies, which would go on to have a lasting impact on the Bitcoin community, was DigiCash, spearheaded by David Chaum. Chaum had already formalized many ideas for a blockchain-like data structure and secure digital cash in 1982 before going on to found DigiCash in 1989. DigiCash implemented Chaum’s proposals, allowing users to withdraw money (called “eCash”) from a bank and make untraceable digital micropayments with it. Unfortunately, only one bank ever implemented eCash, and in 1998 the company went bankrupt.

Other micropayment efforts were also dissolving around the same time, and the W3C itself closed their contributions to micropayment activity in 1998.

The dot-com crash was in full swing, and micropayments were one of the ideas that crashed the hardest. It was a good time to be a critic. In 2000, writer Clay Shirky wrote “The Case Against Micropayments” in which he boldly declared:

Micropayment systems have not failed because of poor implementation; they have failed because they are a bad idea. Furthermore, since their weakness is systemic, they will continue to fail in the future.

His primary argument for their fundamental flaw was not technological or infrastructural — but instead echoed Nick Szabo one year prior: decision fatigue. He goes on:

In particular, users want predictable and simple pricing. Micropayments, meanwhile, waste the users’ mental effort in order to conserve cheap resources, by creating many tiny, unpredictable transactions. Micropayments thus create in the mind of the user both anxiety and confusion, characteristics that users have not heretofore been known to actively seek out.

Shirky went on to predict three methods of payment that would become dominant on the web which did not suffer from the decision fatigue problem: aggregation (bundling low-value things into a single higher-value transaction), subscription, and subsidy (getting someone other than the user to pay for the content — today this has manifested itself as the ad model).

By the end of the dot-com crash, Shirky’s predictions were looking more salient. Credit cards, with their infrastructure costs prohibiting payments of less than $1, had become the de-facto method of payment, and passion for the micropayments project was losing steam. What was a self-evident and exciting prospect for the web’s future faded against the backdrop of its increasingly centralized, surveilled, and ad-driven successor — Web 2.0.

Bitcoin and the Centralized Web

We have to trust them with our privacy, trust them not to let identity thieves drain our accounts. Their massive overhead costs make micropayments impossible.

— Satoshi Nakamoto

The idea driving 402 was that it’s obvious that support for payments should be a first-class concept on the web and it’s obvious that there should be a lot of direct commerce taking place on the web […] In fact, what emerged is a single dominant business model which is advertising. That leads to a lot of centralisation, because you get the highest cost per clicks and with the largest platforms.

— John Collison, President of Stripe

Satoshi Nakamoto released the Bitcoin whitepaper near the end of 2008, aptly timed in the midst of the U.S. Housing Crisis. He released the original code for it shortly after. Bitcoin was a massive breakthrough, both in the history of computer science and the history of money, and spurred a new wave of interest in the possibilities of the internet. For the first time, there was a permissionless way to transfer value with an internet native currency, without all the inelegant, bloated infrastructure needed to use credit cards.

For awhile, the price of bitcoin was so small that some people did advocate its use for micropayment systems, despite Satoshi admitting that it wasn’t (yet) a great solution to that problem:

Bitcoin isn't currently practical for very small micropayments. Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01.

But the limits imposed by fees didn’t stop people from dreaming about new possibilities enabled by it. Marc Andreessen, creator of the first popular web browser, gave the examples of content monetization and fighting spam:

One reason media businesses such as newspapers struggle to charge for content is because they need to charge either all (pay the entire subscription fee for all the content) or nothing (which then results in all those terrible banner ads everywhere on the web). All of a sudden, with Bitcoin, there is an economically viable way to charge arbitrarily small amounts of money per article, or per section, or per hour, or per video play, or per archive access, or per news alert.

This statement is not true today of course (at least, as far as Layer 1 is concerned), but the fees in 2014 were low enough that it was actually possible to build around the concept of micropayments. One interesting project built around this time was Bitmonet, which allowed users to choose their subscription level by paying 10 cents for just one article, 15 cents for an hour of unlimited access to the website, or 20 cents for a day pass. Unfortunately transaction fees are no longer low enough to be able to allow for arbitrarily small micropayments, and although the issue was clearly on Satoshi’s mind from the earliest days of Bitcoin, it wasn’t designed to specifically address the micropayment problem.

Subscriptions and Ads

Shirky’s predictions for content monetization were pretty accurate, particularly when it came to subscription and ad models.

In the ad model, content was subsidized by an advertiser, typically through a third-party. From 2014 to 2022, Google and Facebook essentially held a duopoly over the online ad market as the third-party mediator between advertisers and content creators. The two companies (and in reality, most of big tech) collected enormous amounts of personal information and simply asked their users to entrust them with the safety of their data, despite numerous breaches. This information is used to show targeted ads for products people are more likely to buy. Companies often refer to this model as “free — with ads”. But in reality, users do pay a price. The ad model forces users to trade two things in exchange for the content:

  1. Their data, forcing them to give it to third parties, which, as Nick Szabo famously stated, are security holes.
  2. Their attention. There is a reason for the phrase “pay attention”, and it’s well illustrated here. More time users spend on a site with ads, the more money advertisers, ad platforms, and the content creator makes. Thus a creator is economically incentivized to show as many ads as they possibly can without annoying the user so much that they leave the platform. The currency of the “free with ads” web is your attention. You are the product.

What’s clear in the ad model is that the consumer becomes a second-class citizen. Since a layer of abstraction exists between a creator’s revenue and the end user, making a great user experience is not the highest priority. And as more and more consumers use ad-blockers, content creators are forced to get more aggressive with ads, making using the web a more degraded experience for everyone.

Subscriptions also rose in popularity. Customers showed they were much more willing to pay for bulk access to licensed content like movies and music on a regular basis instead of paying to own individual songs. Although a more honest business model, they can also be very problematic when they are the sole option for payment. And in recent years, as these services become increasingly competitive, more and more people find themselves suffering from subscription fatigue. The inability to access just one (or a few) specific news articles, movies, or songs at any given time forces a suboptimal choice of trying to pay in bulk and optimize the most content for a given subscription.

Take streaming services, for example. Today there are so many streaming services, all battling for content licensing, that users end up paying multiple subscriptions to try to capture a greater subset of the movies and TV shows they want. But all they really want is to watch an incredibly small subset of what’s offered by any given service. When they pick a service for a movie or show they want, it often doesn’t stay long, and will be bounced around unpredictably from company to company as licensing expires and gets updated.

News articles are another example. Companies like The New York Times or The Economist entice readers by allowing them to read just a few seconds of an article before blocking the content with a subscription paywall. Even more so with newspapers than with movies, customers are far more likely to want to pay a small amount for a single article of their choice than for a package deal to articles they don’t want.

While subscriptions offer a more straightforward approach than ads, using them in practice often makes for what is an increasingly costly and stressful management game.

When Clay Shirky was writing about the issues of mental transaction costs, he was writing before the mental costs of subscriptions and ads began to weigh down on people as they do today. Bitcoin gave a solution to the problem of an internet-native currency, but slow processing and high fees quickly became a prohibitive problem for a system supporting micropayments. One more major innovation was needed before true implementations of micropayments technology could take off.

The Lightning Network

A decentralized system is proposed whereby transactions are sent over a network of micropayment channels (a.k.a. payment channels or transaction channels) whose transfer of value occurs off-blockchain. — Joseph Poon and Thaddeus Dryja, The Bitcoin Lightning Network

In February 2015, “The Bitcoin Lightning Network” was published, representing perhaps the biggest advancement in Bitcoin since its inception. Through the clever use of Bitcoin properties, a series of payment “channels” could be constructed such that transactions did not have to be announced to the blockchain but could still retain the lack of trust in a third party, using the Bitcoin blockchain itself for dispute resolution. Payments can either be made directly between two channel partners, or they can be routed across a series of partners, so long as there exists a path of connected partners between sender and recipient. Because of this, it was no longer necessary to pay fees to miners for every transaction, and payments could be settled near-instantly. Since the primary reason micropayments weren’t viable on Bitcoin in the first place was due to high fees and slow transaction processing, the Lightning Network (abbreviated LN or called “lightning” for short) opened up a whole new world of possibilities that are just beginning to be explored.

Methods

The smallest unit of bitcoin is a satoshi (often abbreviated to sat). One bitcoin is equal to 100,000,000 sat. At current conversion rates, 1 satoshi is equal to $0.00023, meaning that the smallest payments that can be made (assuming no routing fees) are currently at a granularity of about two ten-thousandths of a penny, a finer granularity than was ever seriously considered by the web’s early founders. Technically, even finer granularity payments of a thousandth of a satoshi (called millisatoshi, abbreviated msat) can be made within the confines of the Lightning Network, but any sub-satoshi amounts will be rounded down if the money is ever moved back to the blockchain. Therefore, all of the methods of payment discussed below can be used to make micropayments, but different mechanisms allow for a variety of novel payment schemes to be set up. I won’t go into the technical details of how the Lightning Network works here. My intention is to provide a high level overview of some ways micropayments can be made with it, and hopefully to spark people’s imaginations to the possibilities.

Invoice

The most basic way to make a payment on the Lightning Network is through the Bolt-11 invoice. This is an encoded string of information containing everything necessary for the payment to be made. The invoice is generated by the recipient and then sent to the payee. Typically, from a user’s perspective, the payment string is encoded as a QR code which the payee can scan.

Benefits:

  • Least abstractions from a technological level
  • Available by default in LN implementations
  • Payments occur directly node to node

Drawbacks:

  • A recipient having to first send an invoice can make for awkward UX
  • Both nodes must be online for a payment to be made
  • Invoices are non-reusable and must be freshly generated every time

Most of the ways to pay on LN today either simply use Bolt-11 invoices or some abstraction of them under the hood.

Keysend

An alternative to invoices are keysend payments, which allow for payments directly between two nodes without an invoice. Senders only need a node’s public key. One crucial downside to keysend is the lack of a proof of payment, making it unsuitable for merchants or other systems that rely on proof of purchase. For content monetization, however, keysend pairs nicely with the concept of value4value: a model which gives content away freely and asks the user to give back the value they felt they received in turn (and requires no proof of payment).

Benefits:

  • No invoices required, payment can be sent instantly
  • Available by default in LND, Eclair, and Core-Lightning (but must be manually turned on)
  • Direct node to node payments

Drawbacks:

  • No proof of payment limits scope of use

Possible micropayment use cases:

  • Streaming sats (Boosting) while listening/watching/reading content
  • Micro tipping
  • Boostagrams

Examples:

LNURL

LNURL is a set of standards designed to expand the capabilities of LN by providing a specification for “out-of-band” or third party communication between nodes. LNURL standardizes a whole set of LN-based interactions for developers. For example, the LNURL-Pay spec defines how services can create static QR codes that can be paid multiple times. Under the hood, the service is generating a new invoice every time a payment attempt is made.

Benefits:

  • Static pay/withdrawal links
  • LN based authentication schemes
  • Many more

Drawbacks:

  • LNURL operates “out-of-band” meaning that there is a service between LN nodes creating invoices on a node’s behalf. This can mean that the service must be trusted to stay online in addition to the nodes involved in the payment.

Possible micropayment use cases:

  • Private, printable, reusable QR code for donations on content
  • Reusability allows for payments to be made even when embedded in images and videos
  • Withdrawals for content creators who’ve accumulated sats on a given platform
  • Donations to protestors: Anyone can hold up a sign a protest movement captured on video, and sympathizers can easily donate. To quote Marc Andreessen from “Why Bitcoin Matters” in 2014:

    Think about the implications for protest movements. Today protesters want to get on TV so people learn about their cause. Tomorrow they’ll want to get on TV because that’s how they’ll raise money, by literally holding up signs that let people anywhere in the world who sympathize with them send them money on the spot. Bitcoin is a financial technology dream come true for even the most hardened anticapitalist political organizer.

Examples:

LSAT

Many speculate that [the 402 status code] was intended to be used by some sort of digital cash or micropayment scheme, which didn't yet exist at the time of the initial HTTP specification drafting.

However, several decades later, we do have a widely used digital cash system: Bitcoin! On top of that, a new network oriented around micropayments has also arisen: the Lightning Network.

— Olaoluwa Osuntokun, LSAT: Authentication and Payments for the Lightning-Native Web

Lightning Service Authentication Tokens (LSATs) are a protocol created for authentication and paid APIs that leverage the forgotten HTTP error code 402 discussed earlier in conjunction with the lightning network. LSATs can be thought of like reusable tickets that need to be paid for to gain access to a particular resource. But the powerful thing here is that rules can be applied to modify access to resources on a given site, and the tickets can be reused on subsequent visits to the site.

Benefits:

  • Extremely flexible
  • Reusable
  • Allows for highly granular and fine-grained access to digital resources
  • Finally makes use of 402 error code!

Drawbacks:

  • Difficult version control
  • No current methods for efficient management (Could be solved by browser extension such as Alby)
  • Underutilized/underdeveloped despite being around for awhile

Possible micropayment use cases:

  • Pay for single video/podcast/song/article and remember it on subsequent visits
  • Metered subscriptions of your choice
  • Custom expiration dates on content

Examples:

WebLN

WebLN is a standard for abstracting away LN interactions by relying on a client (such as a browser extension) to communicate with a WebLN enabled site. The client must have the ability to interact with the user’s lightning node. For example, a site might use WebLN to request a payment from the user when a button is clicked. When clicked, the user’s client extension will popup, providing whatever payment details the WebLN enabled site sent to the client in a simple to use interface. WebLN greatly simplifies the payment flow for browser based interactions, where user’s no longer have to pull out their phones to make QR code based payments.

Benefits:

  • Better UX
  • Simple implementation
  • No third party required
  • Compatible with LNURL

Drawbacks:

  • Browser client required
  • Few clients in use
  • If user doesn’t have a client installed, fallback options (such as LNURL or invoices) must be provided

Possible micropayment use cases:

  • Anything an invoice, LNURL, or Keysend can do!

Projects Using Micropayments

Finally, here is a short list of projects using micropayments that I found interesting:

See bolt.fun, the Lightning App Directory, or Lightning Landscape for a larger list of projects being built on Lightning.

Conclusion

Micropayments have arrived on the web, and this article just scratches the surface of what’s possible. While there are significant technological and mental barriers remaining, I hope the above examples show how far we’ve already come -- and how much further we can go -- for a cleaner, freer, and more expressive internet.