Like most emerging technologies, bitcoin exists in a gap between what could be possible should the technology mature and its abilities today.
For instance, there may be no older and bigger ‘buried treasure’ use case for bitcoin than its ability to serve as a protocol for micropayments. Compared to credit cards and PayPal, the latter of which defines a micropayment as less than roughly $5, bitcoin is divisible into 100 million smaller units called Satoshis, valued at $0.000002 at today’s price levels.
Proponents have long theorized that this divisibility, coupled with a wider adoption of bitcoin, could create conditions under which all manner of digital media, now largely subsidized by advertising and events, might be paid for through bitcoin micropayments.
Estimates seeking to quantify the size of this untapped market are so far scarce, though Wedbush Securities has forecasted bitcoin micropayments could be a $925bn market by 2025. “Previously impractical, electronic payments of <$1 could broadly change content monetization on the web, possibly supplanting ads,” a July report theorized.
However, despite this promise, the network today can’t send satoshis at an affordable price.
“The first day you read the [Bitcoin white] paper, you’re like ‘Oh amazing micropayments,’ then you realize it doesn’t work at all,” developer Thaddeus Dryja told CoinDesk.
Users who want to send one-tenth of a cent ($0.001 US dollar or 400 Satoshis) through the bitcoin network, for example, can’t do so. Today, the minimum output size is 5,430 Satoshis, or about 1.3 cents, which would incur a mining fee of 2 or 3 cents.
“Your fee is 200%+ of your actual payment,” Dryja noted.
Still, Dryja is one of the developers seeking to bring about a future where bitcoin’s technology can fulfill its promise. As the co-creator of the Bitcoin Lightning Network, first proposed in February, Dryja and Joseph Poon kickstarted a conversation about how bitcoin’s technology could be upgraded with payment channels.
In its simplest form, a payment channel would allow a user to send a certain amount of bitcoin, say $10, to a multisig wallet controlled by two parties. The channel is represented on the blockchain, and an initial funding balance is established. Balances would then adjust between parties as they transact and bitcoin’s nLockTime parameter would ensure that before a specified time, balances could not be entered into a block.
The developers argue that this system replicates many positive benefits of bitcoin – finalizing transactions against the ledger without requiring a trusted third party, while allowing the majority of such exchanges to take place off of the main blockchain, which currently capped at 1MB of data per block.
The Lightning team isn’t the only group of developers working to propose how payments channels would work on the blockchain, however. A similar proposal was put forth by researchers are the Distributed Computing Group of ETH Zurich in a September white paper on Duplex Micropayment Channels (DMC).
Both proposals have come to be viewed as ones that could scale the bitcoin network for if and when user demand increases in line with speculation, keeping the size of bitcoin’s blocks lower and limiting the size of the bitcoin blockchain so nodes can store full versions more efficiently.
Lightning development progresses
As the earliest and most prominent iteration of this idea, Lightning is now supported in part by Blockstream, a startup that raised $21m in funding in late 2014 for its signature sidechains project, which seeks to enable interoperability between blockchains.
Blockstream core tech engineer Rusty Russell, who joined the company in March, is now working full time on the Lightning network. Unaffiliated with the startup or its funding, Dryja and Poon are currently seeking to develop a formal business entity around the project.
In interview, Dryja and Poon suggested that, despite assertions project development could take years, Lightning could take as little as six months to be ready for launch.
Both stressed they are seeking for Lightning to be decentralized, and that this is the primary complicating factor in terms of rollout.
“What is really taking up time and why we have to do it right is you have to make it so that it’s open access in order to participate and that it’s easy to participate across the spectrum of how you want to participate,” Poon said, adding:
“It can’t be a system that centralizes, Lightning needs to exist in such a way that everyone can participate and run a node.”
In practice, that means crafting the rules for how two parties can transact in the system, overcoming adjustments that need to be made to the protocol and establishing how data moves between parties.
First in its order of challenges is create a system of two-hop payments, whereby two users can establish recurring payments within a channel, and these communications can pass through one or more additional intermediary nodes.
“That’s the minimal case where this is starting to be the Lightning,” Poon continued.
The parties then need to be able to prove to each other that a transaction occurred, within a certain period of time. Further, either party will need to settle terms, with penalties coded to ensure that contracts are followed, without such communications being interrupted by intermediaries.
This is a challenge as data needed to process the payments would route through an unknown node operator.
“Let’s say you wanted to pay for an article, you would be connected to some random node on the network. They’d be connected to someone else and then it routes through random computers on the Internet,” Poon explained.
Versions of Lightning are currently being created in C, Java, Go and Python, and according to developers, code is operational.
“Right now people are kicking the tires, in terms of user testing and having spending between each other,” Dryja said, adding that such experimentation is ongoing on Testnet3, an alternative blockchain that replicates network conditions without using real bitcoins.
Larger network improvements
One speed bump to the Lightning vision is that soft forks are required for it to be implemented. Less stringent than a hard fork, such as would be required with an increase to the blocksize, soft forks only require a majority of miners upgrade their software to comply with new rules.
In his April evaluation of the white paper, Russell noted soft forks would be required to protect against transaction malleability issues and allow new signature modes. Additionally, he noted that a rating system would need to be devised for Lightning nodes, wallets would need to be made interoperable with the network and a server implementation would have to be created.
Transaction malleability, the process by which transactions can be altered before entering a block of data on the blockchain, is also an issue, though one the team is confident will be solved by the development community.
“You could build Lightning today, but what happens is that funds could be held up by one of the parties and locking up funds is not sufficient. It creates a hostage scenario. You want to minimize trust in the system,” Poon said.
Additional updates could be made to bitcoin’s scripting language to circumvent a malleability fix. Hashed Timelock Contracts (HTLCs), which would allow payments to be routed across untrusted parties, yet only be executed when the recipient provides a unique hash to the sender, need proposed updates such as CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY.
After the soft forks are updated (a process they said should be “measured in months”), the team suggested wallets providers would need to perform updates necessary for Lightning to be used, a process they acknowledged could take longer.
Both suggested a routing protocol that would govern how nodes process information would also take significant development effort.
DMC emerges
Elsewhere, in Europe, the Duplex payment system is working toward similar goals. ETH Zurich’s Christian Decker and Professor Roger Wattenhofer, best known for research on the now-defunct bitcoin exchange Mt Gox, proposed DMC in September to lesser fanfare than Lightning.
Decker sees Lightning and DMC as the first proposals that would allow “secure off-blockchain routed payments”, though there are differences in each approach. A core variation, Decker said, is that while Lightning requires that private keys be exchanged to change a state of the contract, DMC uses decreasing timelocks.
In essence, DMC proposes that payment channel agreements can be updated by changing the time at which they are scheduled to be committed to the blockchain, rather than exchanging private keys to invalidate transactions.
“Transactions representing a later state simply have smaller timelocks that allow them to be valid before the old state is valid,” he explained.
Decker argues that this would allow DMC to be more easily audited. “This is a core difference to Lightning where the components are tightly coupled and are not usable individually,” he said.
Like Lightning, DMC would also require a malleability fix to be implemented. Decker has also submitted a bitcoin improvement proposal (BIP), currently in draft, that would allow unsigned transactions to be built upon with subsequent updates.
According to the researchers, the implementation is currently moving forward and will be open sourced when a working proof-of-concept has been developed.
Off-blockchain micropayments
Both projects stand in contrast to other methods that micropayments are being made possible today. For example, tipping platform ChangeTip conducts its bitcoin tipping off-chain, while social network ZapChain uses BlockCypher to dynamically insert small transactions.
More top secret and potentially more impactful is a project in the works at bitcoin startup 21 Inc, which has so far raised the most VC funding in the industry.
In November, 21 announced it would release a “Bitcoin Computer” that aims to provide small amounts of bitcoin to users continuously through an embedded mining chip. As expressed in the company’s communications, the miner is not meant to be speculative, but to encourage developers to create apps and inventions that need bitcoin to operate.
“Specifically, we want to make it possible for you to turn your bright idea into passive income by selling bitcoin-payable goods, games and services over the Internet through a 21 Bitcoin Computer,” CEO Balaji Srinivasan wrote at the time of the product’s unveiling.
Key to its functionality is a built-in “21 micropayments server”, a feature whose impact Srinivasan hinted at on Twitter.
.@derosetech @manan19 @StartupLJackson The goal: flick on a new paid internet service like you turn on a new lightbulb. No ads, no signup.
— Balaji S. Srinivasan (@balajis) September 22, 2015
How exactly such microtransactions would interact with the blockchain is unclear, though such transactions may take place off-chain, or within 21 Inc’s ecosystem, only to be applied to the blockchain later. Both Poon and Dryja said they had not been contacted so far by the company.
Regardless of 21’s ambitions, however, both developers suggested they believe improvements to bitcoin’s core technology are needed.
“Most people, not super technical people, think bitcoin already does this stuff. In 2013, there was a lot of press, people were saying zero-fee, free transactions, micropayments. Bitcoin doesn’t really do that,” Dryja said, concluding:
“A lot of people thought you can do a lot of things with bitcoin and we need to deliver on that.”
Server images via Shutterstock