Bitcoin engineers face a future where rising transaction fees price users out of using bitcoin for everyday commerce. There are a few solutions for lowering those fees and the latest, most hyped solution is the Lightning Network, a system built on a web of payment channels. I'll explain how payment channels work, how they can be put together to make the Lightning Network and show what this new economy looks like.

The payment channels that the Lightning Network is built on are a construction unique to Bitcoin. They're a way to coalesce a bunch of smaller transactions into a single large transfer and a solution to the prohibitive fees that each individual transaction might have if made independently. To open a payment channel you take cash on hand and spend it in a special kind of deposit transaction which opens the payment channel to the other party. It's useful to think of it as a deposit as it takes this cash and locks it up for a certain period of time where neither the sending party or receiving party can spend it. The payment channel also has an expiration date where the deposit is returned. When you want to pay the other party your software creates an updated version of the payment channel where instead of returning the entire deposit back to you at the end some of the balance is sent on to the other party and the remainder of that is sent back to you. You repeat this as many times as you want and when you get close to the expiration date the very last version of the transaction gets put into the Bitcoin network. You could have made a dozen transactions with that payment channel but at the end of the day you only had to put two transactions into the Bitcoin system and paid only two transaction fees.

I think Netflix is a great example to show how payment channels might be used in practice. With Netflix, you pay your $8 a month and you get full access to the entire Netflix library for the entire month. But if Netflix was built on payment channels instead of paying them $8 you'd take that money and lock it up in the deposit transaction that opens the payment channel. Later, when you want to watch a movie Netflix's software requests your Bitcoin software to create a new, updated payment channel transaction that sends maybe 50 cents on to Netflix for the movie and returns the remaining $7.50 back to you. Once Netflix has a copy of this updated transaction they can show you the movie. As the month goes on you repeat the same process and create a new, updated transaction for Netflix every time you want to watch a movie. At the end of the month the very last transaction is put into the Bitcoin system, the payment channel is closed and Netflix gets their money and you get anything left over from the deposit.

These payment channels reduce the number of Bitcoin transactions made reducing the total number of fees paid but they came at the cost of your liquidity and the time value of money. When you open the channel you have to have all of that money on hand in order to lock it up in the deposit. For an $8/month Netflix subscription this isn't a challenge for many but what if you were paying for groceries or gas with payment channels? You're locking up an entire month's worth of grocery money at the start of the month in order to save on transaction fees. You can't do that at all if you're living paycheck to paycheck and for everyone else you're quickly locking up all of your cash on hand in these payment channels to various vendors in hopes of saving money on fees. You can close a payment channel at any time to reclaim your money but you'll run up extra Bitcoin transaction fees when you do this and kill the efficiency of your payment channels. And finally these payment channels are supposed to enable micropayments, transactions from the furthest reaches of the demand curve. It does not make sense to open a payment channel to a merchant you might do business with once every one or even ten years for a few cents worth of business. Payment channels by themselves aren't an improvement over the status quo.

The Lightning Network works around these limitations. Instead of every participant opening channels to everyone else individuals open payment channels to central hubs. When a payment needs to make it across the graph a route is found and each payment channel along the way is updated. Here's an example network:

Lightning Network

Bob wants to pay $20 to Amazon. There is a $100 payment channel open between himself and hub 1, a $1,000,000 payment channel open between hub 1 and hub 2 and a $100 payment channel open between hub 2 and Amazon. Bob updates his payment channel to send $100 to hub 1, leave $22 with hub 1 at the closing of the channel and returns $78 back to himself. Hub 1 updates its payment channel to send $1,000,000 to hub 2, leave $21 with hub 2 at the closing of the payment channel and $999,979 back to itself. It keeps that $1 of Bob's original transfer as a fee. Hub 2 then updates its payment channel to Amazon to send $100 to Amazon, leave $20 with Amazon and return $80 back to itself, once again keeping $1 as a fee. The payment channels used by the Lightning Network are a bit more sophisticated then what I've explained here, they are actually bi-directional and have protections built into them to guarantee that everyone helps move the money along and can't steal any bitcoins. But this is the high level view of how the Lightning Network works: users only have to open a single payment channel to their hub and the rest of the payments get aggregated in giant payment channels between hubs that handle huge transaction volumes.

That's how the Lightning Network is supposed to work, at least on paper. Nobody's written any of this code yet, so who really knows how it'll play out. The system may look different or not work at all when they come around to building it. Execution is everything and the authors here haven't done it yet. I can't vouch for the security of this system. Auditing for security is something I have no practice with and I am just not qualified to review something as complex as this. And don't expect competent peer review for a while: the prose in the Lightning Network paper is awful (although much improved from the original version) and the only people with the knowledge and stomach to get through it right now are the Kool-Aid drinkers. And finally, even if it does work the community has to start using it: everyone in the Bitcoin economy has to switch to software that uses the Lightning Network which is a big change from how Bitcoin is used today both in user and software interfaces. Rising transaction fees could push people onto this network but it'll be a painful switch.

But should it become widely used what does this network look like? At one point Lightning Network engineers were using the name "hub" in the same way I did above but lately they're promoting a vision of a wider P2P network with more intermediaries and smaller payment channels between them. Unfortunately market pressures work against decentralization here and the model of a few, large hubs holding open massive payment channels is the future. Automated routing that finds the cheapest path across the market will reward large hubs that can create short paths across the network and service huge volumes and leave the smaller, lengthier chains without customers.

It's also slightly dishonest to call these hubs instead of banks. In the same way that the individuals using payment channels by themselves needed to lock up cash and manage their liquidity in order to create payment channels these "hubs" need to deal with getting access to huge amounts of cash that they can tie up to open their own massive payment channels. The name for an organization that makes its profit from carefully managing its investments and liquidity is a bank and that's exactly what these hubs are doing. And the only organizations that have the kind of cash (or access to the cash) to invest into a payment channel is a bank. Hopefully these hubs look like investment banks and get their cash from the same customers that investment banks have but there's not a whole lot stopping them from being retail banks capitalized by the deposits of ordinary people. Investing in a Lightning Network hub is low risk and low return. Your losses are limited to the cost of bitcoin transactions but your profit is the little bit of fees you make off of being a hop in the chain. Competitive pressure to keep prices down is high because anyone can spin up a node and nodes with smaller capitalization can still compete on lower fees and better connectivity. If you really need the cash you can close out the payment channel at any time so it's at least a pretty liquid investment. If the Lightning Network finds common use these will be attractive investments for retail banks. Now we've come full circle to something similar to our current system only with Bitcoin and the Lightning Network.

If the Lightning Network catches on the underlying Bitcoin network needs to be able to handle its traffic demands. The biggest debate right now in the Bitcoin world is over the future of the block size, the maximum amount of data that can be used to update the Bitcoin blockchain. On one side of the debate is the sensible, pragmatic engineers who want to keep the block size increasing with an eye towards future growth of the Bitconomy and future increases in computing power. On the other side is a bunch that wants to keep the network running at its current transaction rate for at least a few years. The constant size group (called "small blockists" by the larger Bitcoin community) have a bunch of motivations behind their decision I won't get into here. This is relevant to the Lightning Network as that same small blockist group heavily pushes Lightning Network as a workaround for small block sizes. Because the Lightning Network coalesces the transactions that need to be put on to the blockchain it lets you get more use out of that small block size.

Even though the small blockists are some of the biggest proponents of the Lightning Network because at its face it makes small blocks look like they can handle the network's traffic demands the Lightning Network itself requires large blocks! I didn't go into too much technical detail in this blog post but the Lightning Network has several systems that keep everyone participating honest. One of them is a special Breach Remedy transaction that keeps either party in a payment channel from reverting to older channel balances. If you try and revert back to the older version of the channel the opposite party can spend this Breach Remedy transaction which closes out the channel and gives all of the money in the channel to the party that didn't cheat. This is meant to be a deterrent to keep both parties honest but it only works if you can reliably use the Breach Remedy transaction. Blockchain congestion is a failure mode for the Lightning Network because they assume you can always get a transaction included should you need to do so. There are a few hacky workarounds in the Lightning Network paper for this but for successful implementation of the Lightning Network you'll need large blocks or possibly even unlimited blocks. Miners can still be profitable in a large block world - they can price discriminate against those 'million dollar' inter-hub payment channels and charge them larger fees. So even though the current LN boosters might be pushing small blocks they will eventually need to be large or even unlimited.

If this network works it's also a pretty good realization of the dream of Austrian economists. Bitcoin is a hard currency and with the Lightning Network it really beats out the incumbent hard currencies on ease of use and features. It may even be possible to capitalize Lightning Network payment channels with smart contracts that guarantee the funds from closed channels are returned to their investors. So not only do you have a hard currency that can be spent easily, securely and quickly but you've created 100% reserve banks in the Lightning Network hubs that can still earn a tiny bit of profit and can't be plundered by management. Austrians will love it! But what happens when the business cycle contracts? Austrians solve this problem by pretending that never happens. For the rest of us, though, it's an inevitable part of business and we need to know how the system works when that happens. The revenue from payment channels is proportional to the volume of transactions they handle. If that goes down the payment channel's yield goes down and they lose their attractiveness as an investment. If capital starts fleeing elsewhere and the number and size of the payment channels goes down the entire economy's velocity is brought down by higher Lightning Network fees competing over fewer payment channel space. And if it gets really bad it turns into another Great Depression as there is no central bank to add liquidity to the payment channel market. Everyone has to sit on their hands until everything else in the world tanks to the point where investing in payment channels becomes attractive again. You may not be able to spend your money on anything because the Lightning Network is non-functional or too pricey but you'll still have full access to your bitcoins whether they are in your 100% reserve bank or your personal bitcoin wallet. Is that a better system than what we've got now? It's interesting to think about and it rounds out a bunch of hard corners in the usual Austrian proposals.

http://dev.stephendiehl.com/numpile/ Transform Python AST into LLVM IR for JIT execution.

http://localsustainability.streamshare.com/posts/13103 The history of cornbread in the South.

http://mainframesproject.tumblr.com/ Mainframe terminals available on the public internet.

http://jasmcole.com/2014/08/25/helmhurts/ Modeling the propagation of WiFi signals in an apartment to find the perfect router location.

http://njgeo.org/2014/01/30/mitch-hedberg-and-gis/ Finding all the La Quintas that are close to a Denny's.

http://jiahao.github.io/julia-blog/2014/06/09/the-colors-of-chemistry.html A step-by-step tour on how to derive the visible spectra from absorption and emission spectra.

http://lists.w3.org/Archives/Public/www-style/2014Mar/0272.html The complete history of the X Windows color list.

http://militera.lib.ru/research/suvorov12/index.html Written by a Soviet defector this book gives a great insight into the Soviet leadership's mindset.

http://www.tedunangst.com/flak/post/signal-safe-strcpy POSIX forbids using strcpy in signal handlers. Here's how to get around that.

Syndicate content