Satashi Nakamoto sent a proposal for "a new electronic cash system that's fully peer-to-peer, with no trusted third party," to a cryptography mailing list on Friday, Oct. 31, 2008. The first response – the first time anyone publicly commented on bitcoin – came the following Sunday: "We very, very much need such a system," wrote James A. Donald, "but the way I understand your proposal, it does not seem to scale to the required size."
Going on 10 years later, that criticism still rings true. Even bitcoin's most ardent evangelists admit that it's worthless for making small, everyday purchases. But the Lightning Network, one of the most promising bitcoin scaling projects currently underway, could change that.
The Lightning Network
Speaking at the Blockstack Summit in July 2017, Lightning Labs CEO Elizabeth Stark cited that first critique of Nakamoto's electronic cash, but expressed confidence that bitcoin can in fact scale. "We're basically in 1995 all over again when it comes to blockchains and decentralized technologies," she said, referring to the time before the internet acquired HTTP and the other transport and application layers of TCP/IP.
Among the most talked-about "layer 2" applications for the bitcoin blockchain is the lightning network. First proposed by Joseph Poon and Tadge, aka Thaddeus Dryja in 2015 (the most recent version of their whitepaper is available here), lightning has been worked into a functioning specification called lightning-rfc or "BOLTS" by three companies, each of which has its own implementation: Lightning Labs has lnd, Blockstream has c-lightning, and ACINQ has eclair. There are also non-BOTLS implementations being developed, such as thunder.
The lightning network is already up and running, but it's in its extreme infancy. Real bitcoin has been sent and nearly always received using Lightning Labs', Blockstream's and ACINQ's implementations, and all three are interoperable. The video below shows an ACINQ engineer sending 0.000001 bitcoin (about $0.01) almost instantaneously from an eclair node to an lnd node through a c-lightning node:
To see how much of an improvement this represents, we tried a similar transaction on the bitcoin blockchain using GreenAddress, a mobile wallet app. The app suggested paying miners 0.00001907 BTC ($0.19): a 1,907% fee. While it's not clear how many blocks that fee was intended to confirm within (we've reached out to GreenAddress to find out), the answer is likely six blocks, or around an hour.
We'll never find out how long that particular transaction would actually have taken, though: an error message informed us that "outputs below 546 satoshis [$0.05] are considered uneconomic dust by Bitcoin. Please increase the value."
Lightning Labs has also tested cross-chain atomic swaps using the network; these are transfers of value between different blockchains, in this case bitcoin and litecoin, which potentially mark a first step towards building decentralized exchanges.
Lightning enables micropayments that bitcoin can't on its own, but existing implementations are still buggy. Stark is urging users to learn about lightning using bitcoin's "testnet" (that is, to use fake money), rather than the live-fire "mainnet." Around $50,000 worth of transactions have been performed on the mainnet at the time of writing, however, and some people have lost money to a c-lightning bug. (Christian Decker, core tech engineer at Blockstream, told me via email that funds were ultimately recovered in most cases.)
So how does lightning work?
How Lightning Works
Lightning's solution is based on two-way, off-chain payment channels. Say that Alice and Bob frequently transact with each other in small amounts. On-chain payments are not practical in this case because of the fees and long confirmation times involved, so they decide to open a channel allowing them to send bitcoin back and forth, instantly and fee-free.
Opening a Channel
To open a channel, Alice, Bob, or both contribute a certain amount of bitcoin to a special address through what is called a funding transaction (the green box in the diagram below). Say Alice contributes 1 BTC. She sends the funds to what is called a 2-of-2 multisig address, which requires both Alice and Bob to cryptographically "sign" any sending transaction with their private keys. A normal transaction only requires the signature of the (single) private key corresponding to the sending address' public key.
Importantly, the funding transaction is not yet signed or broadcast to the network.
All images sourced from Poon and Dryja.
Next, Alice and Bob create a "commitment transaction" using the funding transaction as its "parent": they use its unconfirmed output of 1 BTC as the input for a "child" transaction that sends 0.5 BTC to Alice (output 0) and 0.5 BTC to Bob (output 1). If you're protesting that bitcoin's protocol doesn't allow users to sign a spend without knowing the input's signatures, that ability was granted through a soft fork.
Alice then signs the output sending 0.5 BTC to Bob; Bob signs the output sending 0.5 BTC to Alice. Both then sign and broadcast the funding transaction, which is committed to the bitcoin blockchain (and subject to network fees and wait times).
They now have an open payment channel through which they can shuttle bitcoin back and forth instantly and fee-free. Either Alice or Bob can close it at any time and claim their 0.5 BTC each, or whatever the updated balance is.
Opening a Channel … In English
Unless you already know a fair bit about the lightning network's innards, it's probably hard to digest the "sign here, initial here, spend this, broadcast that – no not that."
Here's a more conceptual description. The funding transaction is what it sounds like: it provides the funds for the channel. It also acts as a cap for the channel: neither party can end up with more than the initial funding amount, and both parties' balances must add up to that amount. The reason the funding transaction is created first, but broadcast last, is that if it were simply posted to the blockchain in one step, nothing would have been accomplished aside from a single, plain-vanilla transaction. Lightning doesn't make those any faster or cheaper.
By leaving the funding transaction open, inserting a commitment transaction – which, as described below, functions as a kind of smart contract – and then closing the funding transaction, lightning pries open a kind of wormhole in the network. It allows you to move bitcoin back and forth along a single, defined path. You're using the bitcoin protocol, but bypassing the delays and expense imposed by the miners.
Keeping Lightning Trustless
Say Bob now wants to pay Alice 0.1 BTC using their open channel. The two parties simply update the commitment transaction — no need to appeal to the miners. The balance, previously 0.5 BTC each, is now 0.6 BTC to Alice, 0.4 BTC to Bob.
The only problem is, how to do that securely? Because they've already exchanged signatures for the initial transaction, Bob can sign that one – rather than the most recent one – and walk away with 0.5 BTC instead of the 0.4 BTC he's actually owed. In other words, he can steal around $1,000 from Alice, based on prices at the time of writing. The answer might be to only open channels with people you trust. But then what's the point of using bitcoin?
Finding a cryptographic solution to this dilemma boils down to one goal: making it impossible to sign an old transaction and close the channel in a way that reflects a previous state. As long as doing so is an option, lightning has a double-spend problem.
Remember that Bob signs one half of the commitment transaction (Commitment Tx 1a below), which only Alice can broadcast because hers is the missing signature. Alice signs the other (Commitment Tx 1b), which only Bob can then broadcast. Either one can do so and close the channel, but using bitcoin's (limited) smart contract-writing capabilities, the outputs of the two halves of the commitment transaction can be subject to different restrictions. Specifically, one output can allow the recipient to spend the funds immediately, while the other can be subject to cancellation by either party – via a Revocable Sequence Maturity Contract (RSMC) – for a defined period of time, such as 1000 blocks, or about a week.
Here's why that's useful. If Bob turns out to be devious and unprincipled, he can only sign and broadcast Commitment Tx 1b (above), which pays Alice out immediately (Delivery 1b) and holds his funds in revocable limbo for a week (Revocable Delivery 1b). Alice, seeing that Bob has attempted to shortchange her, can trigger revocation and claim not just the 0.1 BTC Bob tried to steal, but the 0.4 BTC he would otherwise have been entitled to.
In other words, the whole channel goes to Alice if she catches Bob cheating. That's possible because when the parties create a new commitment transaction (C2a and C2b below), promising in effect not to broadcast an old commitment transaction (C1a or C1b), they put their money where their mouths are. Along with the new commitment transaction, they create a breach remedy transaction with two outputs (BR1a and BR1b) applying to the previous commitment. Alice gives Bob her private key for his half of the breach remedy transaction, and vice-versa. Now if either tries to broadcast the old transaction, the counterparty can take advantage of the 1000-block waiting period and swoop in ahead of that transaction, taking the offending party's entire balance.
The problem is that Alice must pay semi-constant attention to her channels, lest Bob catch her off guard for 1000 blocks. Poon and Dryja suggest designating some third party whose job it is to trigger breach remedy transactions – the ones rewarding all the channel's funds to the wronged party – when a counterparty tries to cheat. These could be paid a fee out of the penalty.
Olaoluwa Osuntokun, Lightning Labs' co-founder and CTO, is developing "watchtowers" to serve as these third-party enforcers. While concerns have been raised that these nodes could act as trusted parties and introduce insecurity into the network, Osuntokun tells CoinDesk that only one honest watchtower would be needed for a given channel.
Also, as Christian Decker, core tech engineer at Blockstream, points out in an email, fraud is risky. It's a significant gamble to assume that the party you're trying to rob will not check in at least once a week, and the risk of losing all the money in your channel may be enough of a deterrent.
Connecting the Channels
In the real world, Alice doesn't want to transact exclusively with Bob, nor Bob exclusively with Alice. Both have any number of counterparties they need to pay and get paid by. Opening channels with every one of these parties would be impractical. Even if the user interface were simplified to perfection, few users would have the liquidity necessary to tie up bitcoin in a dozen or more open channels.
Luckily they don't have to. As the video above shows, users can route payments through intermediate users' channels, so that paying anyone with an open channel or two should be possible through the six-degrees-of-separation principle. Unlike transactions within a single channel, these multi-channel transactions will likely involve small fees to incentivize nodes to fund channels and keep them open. Onion routing, the technique used to disguise TOR browser users, prevents intermediate nodes from seeing the full path taken by a transaction, mitigating privacy concerns.
How well this web of channels works in practice remains to be seen, and it's conceivable that if payments have to take too convoluted a route – with too many "hops" through intermediate channels – fees charged by those users could add up.
Can Lightning Stay Decentralized?
These worries are related to one that, to critics, represents an insurmountable flaw in the lightning network. In today's implementations, a channel comes with a cap: the amount of bitcoin in the initial funding transaction limits the total amount of money in the channel.
This situation imposes a tradeoff on users with reasonably limited resources. They can either fund channels with large amounts of bitcoin in order to ensure that they have the funds to make any payment they would need to, or they can fund smaller channels and have bitcoin available for other uses. (Because payments can be routed through linked channels, a given user probably doesn't need to open more than a handful of channels, and perhaps only a couple.)
The choice boils down to having liquidity within lightning channels or liquidity outside of them, on-chain. Choosing to fund liquid payment channels could be risky if watchtowers or some other solution doesn't prevent the loss of funds through inattentiveness. On the other hand, if payment channels are made secure and lightning becomes the main method for using bitcoin day-to-day, there would be little issue with leaving funds in channels. They would serve as "a rechargeable debit card or cash," as Decker puts it, while the main chain acts as a savings account.
Stark makes a similar argument: funding a lightning channel prevents you from using that bitcoin for anything else, except "a network of potentially many nodes that across multihop will accept bitcoin instantly," she wrote via email. "we envision funds on Lightning channels to be more useful than on-chain bitcoin for transacting because of the instant speed and low fees," she added.
Hubs?
But who would you set these channels up with? Choosing the Bob to your Alice is an economic decision, not a cryptographic one, and to critics of the lightning network, the obvious answer would be a sort of "hub," a node with a lot of capital, giving it the ability to maintain well-funded open channels with a number of parties at once.
The idea that what amounts to an off-chain bitcoin banking industry might develop disturbs bitcoin enthusiasts, who see it as centralizing the network.
Stark disputes this line of argument. "Thousands of users run full nodes for bitcoin," she writes, "and we believe those and others will also run nodes on Lightning (it's easier because you don't need a bitcoin full node along with it, and unlike bitcoin full nodes you can make small fees from routing)." She also points out that her team is working on "splicing," which would allow channels to be topped-up using bitcoin from the main chain. That ability could alleviate the trade-off between putting bitcoin in a channel or leaving it on the main chain, which could in turn reduce the tendency for hubs to form.
Decker sees it as likely that a "two-tier network will form, with a large number of nodes that are reliable and act as the backbone of the network." He expects these to be merchants, however, rather than hubs that exist solely to provide liquid channels. Providing these channels to multiple users, he argues, would be expensive, requiring the hubs to charge high fees and making them uncompetitive compared to other nodes.
ACINQ CEO Pierre-Marie Padiou doesn't profess to know how the lightning network might develop. "It is very difficult to predict what the equilibrium will be between centralization and decentralization," he wrote via email. "Of course there will be bigger nodes and smaller nodes, but to what extent it is difficult to tell beforehand."
The Right Way to Scale?
Poon and Dryja assert that "using a network of these micropayment channels, Bitcoin can scale to billions of transactions per day with the computational power available on a modern desktop computer today." Perhaps, but that's certainly not the case today. Fewer than 1,000 mainnet lightning nodes are open at the time of writing.
Nor is lightning the only scaling proposal out there. A major competitor is bitcoin cash, a contentious hard fork of bitcoin that allows for larger blocks. The debate between bitcoin cash supporters, lightning supporters and advocates of various third ways – even the occasional anti-scaler – is lively, if acrimonious. It may be that one or the other will come out on top, that they will continue to coexist, or that all will fail.
In any case, the lightning network is a promising attempt to overcome the scalability dilemma that has haunted bitcoin since bitcoin's first weekend in 2008.
Compete Risk Free with $100,000 in Virtual Cash
Put your trading skills to the test with our FREE Stock Simulator. Compete with thousands of Investopedia traders and trade your way to the top! Submit trades in a virtual environment before you start risking your own money. Practice trading strategies so that when you're ready to enter the real market, you've had the practice you need. Try our Stock Simulator today >>
Comments
Post a Comment