In last February 2015, Joseph Poon and Thaddeus Dryja released a draft paper on what they called the “Lightning Network” . While only a draft proposal with no code, this raised a fair bit of excitement in the bitcoin technical community: Little wonder, as it allows near-instantaneous bitcoin payments between arbitrary parties!
This post summarizes the ideas brought together in that paper, and the developments since it fired the starting gun for development of trustless off-chain bitcoin transactions.
It’s possible for two parties to create chains of transactions where none but the final one need to actually enter the bitcoin blockchain. This is the idea behind simple payment channels , which exist today in Bitcoin; you keep sending someone replacement transactions that pay them a little more than the last one did. If something happens, or the channel ends, they simply broadcast the last payment.
It turns out that, with a few fairly non-controversial bitcoin upgrades, you can make more general channels that allow two-way payments and also something called “ conditional payments.” Conditional payments allow you to form a payment network. In effect, your wallet software can promise, “I will pay Bob, if Bob pays Carol,” in a guaranteed and trustless way. If something goes wrong, y our wallet software automatically broadcasts that conditional payment transaction to the Bitcoin network and waits.
The Lightning Network paper proposes a mechanism for generalized channels and networking of payments. While similar ideas have been floating around for a while , the paper brought them together into sharp focus. A different mechanism for doing the same thing was published more recently by Christian Decker and Roger Wattenhofe in Zurich, so this is a hot area of investigation right now.
Blockstream hired me (veteran Linux Kernel and Open Source developer) in May 2015 and immediately put me to work to explore the L ightning Network . I’d already posted a series of technical explanations on the Lightning draft paper, and proceeded to have several exploratory conversations with Joseph Poon on how it might be implemented.
We started a public mailing list and I began uploading prototype code to github in June. The code implements those generalized channels and conditional payments, or Hash Time Locked Contracts in the technical parlance, using a slight variation on the method described in the paper more recently published in draft form . It runs on Blockstream’s Elements Alpha sidechain, which already has the features Bitcoin will need to support the Lightning Network. We are currently bedding down the first draft of the network protocol between nodes, including a complete state machine, and two other independent implementations in various stages of development have been announced on the list. We’re still thrashing out routing, how intermediary nodes will charge, discoverability and other technical issues.
People ask why we’re investing a whole developer into the Lightning Network? Blockstream’s focus is to advance Bitcoin to support more applications and use cases. Given our engineering expertise and protocol background, advanced Bitcoin usage like the Lightning Network is our core interest. As a company dedicated to open source development, it’s also vital that this new area technology be open source and permissionless, just like Bitcoin itself.
Others have asked about Lightning in the context of Bitcoin’s scalability : does it help? It might in the long term, as small payments become the norm on the Lightning Network and only anchor and close transactions enter blocks. But if it’s wildly successful, it will also put massive pressure on the blockchain as users flock to Bitcoin. Perhaps sub-cent micropayments to support artists are the killer app for Bitcoin? Perhaps instant transactions will unleash a second wave of Bitcoin innovation? Nobody can know, yet.
For the immediate future, the Lightning Network is a developer’s playground where the engineering is being done to turn it into a real, usable product. However, it is exciting work and open to others to get involved.
In addition to actually writing the Lightning code and defining the protocol, there are several features that need to be adopted into Bitcoin:
- OP_CHECKLOCKTIMEVERIFY ( BIP 65 )
- OP_CHECKSEQUENCEVERIFY ( BIP 112 , which needs BIP 68 )
- Malleability fixes ( BIP 62 )
One of my most fascinating early conversations with the original Lightning Network paper author, Joseph Poon , had us speculating on what the Lightning Network will look like once it’s up and running. Your phone would initially connect to the Lightning Network by establishing channels with five random nodes, we posited. From there, you could make payments for some variable but small fee to anyone else on the network.
More interestingly, your phone app could also provide network liquidity by moving bitcoins across the network back to itself. Say, for example, that a Lightning sale of Satoshi Nakamoto’s Autobiography causes a large number of transactions in one direction across the network towards the seller. Overloaded channels may offer negative fees for anyone who can move funds in the reverse direction to rebalance, and thus allow them to collect more fees. If your five random channels put you in a position to do so, your app could then send itself some money and make a small profit.
Will this actually happen? I have no idea! But it illustrates just how different the world might be with a working, fast peer-to-peer micropayment network.