I tried to read and understand the Lightning Network paper recently. Glad I'm not the only one:
If I’ve gotten anything wrong here, it’s because the Lightning Network is ridiculously complex: the paper is some 57 pages written in blockchainiac gobbledygook terminology. I’m the sort of person who reads academic papers for fun, and can attest that this is not a paper I remotely purport to understand or enjoyed reading. I think there are very few people on Planet Earth who have read this paper and understand it.
If you're one of these Very Few People and you're reading this, a question: do Lightning's channels only reduce on-chain transaction volume in the case of recurring payments (eg subscriptions)? What is the anticipated savings if the Lightning Network is rolled out -- how much of current transaction volume could be handled in channels?
Opening a payment channel requires an on-chain transaction, as does finalizing a sequence of transactions sent over the channel. So for every sequence of off-chain transactions on a Lightning Network, you must put two transactions into the blockchain.
Thus you need to make more than two transactions in a sequence before moving them off-chain can offer any benefit, either at the micro scale (in the parties' cost of transacting) or at the macro scale (to Bitcoin's aggregate transaction throughput, both on- and off-chain). In theory a sequence of transactions done over the Lightning Network can involve multiple recipients and be routed among many parties, however, so a sequence of off-chain transactions need not be a sequence of recurring payments in the usual sense.
Whether a Lightning Network offers any cost or scaling advantage, and how big those advantages might be, will depend in practice on (a) whether good methods can be found to route off-chain transactions between hubs and end-users of the network, and on (b) the statistics of the real-world patterns of transactions that people end up using the network for.
Personally, I think that unless Lightning Networks give rise to major new classes of transactions (e.g., micropayments), then we are unlikely to see any significant scaling win from them any time soon. There is a classic chicken-and-egg problem of gaining a critical mass of users, which will take time to overcome, and people today typically use Bitcoin fairly infrequently, which makes the two-transaction overhead to get in and out of the payment channel significant relative to the likely size of off-chain transaction sequences.
The question is what alternatives exist, and which will gain traction, in the case that on-chain capacity remains severely artificially constrained and on-chain fees continue to rise. Maybe people will switch rapidly to Lightning Networks, or maybe they will switch to altcoins, or maybe they will just stop using cryptocurrencies altogether (or never start). We'll see.
>[D]o Lightning's channels only reduce on-chain transaction volume in the case of recurring payments (eg subscriptions)?
Payment channels and consequently the Lightning Network (LN), assuming a sufficiently connection routing network (the people you want to pay are connected to the LN), reduce the volume of any amount of transactions. LN has the best cost advantage for use cases when the transaction volume is high (paying for wifi by the minute) but will also reduce on-blockchain transaction for anything.
If you're seeking a lucid explanation of what the LN is: Imagine a group of people with buckets of coins, to establish a financial-transaction connection with a person in the group you pay a small fee, after connecting to that person, you can pass some coins into that person's bucket who can then pass those coins onto another person's bucket (ad nauseam) all without requiring (but with option if you wanted) to settle the amounts to the blockchain. The LN paper goes into how this is done in a cryptographically enforceable method via the Bitcoin blockchain.
>What is the anticipated savings if the Lightning Network is rolled out
There are two things to assess the value of the LN. The transactional cost savings but also (and more importantly) the new use cases available to having transaction occur on a roughly 1-2 second timeframe (versus the 10-60 minute window currently). All off-chain databases would have the technological capability to have cryptographically enforced 'instant' payments. Right now, off-chain centralized actors (Coinbase, Bitfinex) just update entries to a database but don't have any blockchain-enforce DB updates. With LN, they could.
>how much of current transaction volume could be handled in channels?
Could: The majority of it.
Would: Depends on LN participant's appetite to dedicate funds to a payment channel (LN coin bucket). It's a trade off of avoided block-transaction fees vs time-value of money of dedicated funds.
I don't know Bitcoin well enough to understand the LN paper, but I've read articles on the basic ideas and think I understand enough to implement LN on Ethereum, where it's much easier.
If channels were not networked together, then they'd only be good for recurring payments.
But there's a trick that lets you network them, so A can have recurring payments to B, and B can have recurring payments to C, D, and E, and now A can pay all the others via his one channel to B. And it's done in a way that prevents B from being able to run away with money intended for C,D,E.
Bitcoin script provides a no elegant way to invalidate old states. There are various solutions to this in lightning network tx but they end up requiring actively watching the network in case an old state is broadcast. If you have a better mechanism for invalidate the previous state, the whole system can be massively simplified.
Since we're only talking about a single utxo in either case, the difference seems moot.
And writing and testing the opcodes took less than a day; that's not the hard part! (Though getting the convenient opcodes into bitcoin was definitely non-trivial!)
Lightning can greatly increase the number of transactions that Bitcoin can support, but there are questions about whether it creates a problematic potential for financial centralization if successful.
As a P2P system LN doesn't really work for decentralized payments other than micropayments, for reasons others have pointed out here.
If you allow some well-capitalized hubs to form, that help solve the routing problems, then LN can easily achieve significant scaling for most kinds of payments (think digital hawala). The issue is that this is likely to require hubs that create and hold lightning channels with lots and lots of users, creating the potential for the distorting effects of centralization.
The greater issue is one we've seen now with Ethereum: if a Layer 1 app (the DAO, or LN) running on a Layer 0 blockchain comes to dominate the blockchain's usage, then there exists the potential that failure of Layer 1 can traumatize Layer 0.
If I’ve gotten anything wrong here, it’s because the Lightning Network is ridiculously complex: the paper is some 57 pages written in blockchainiac gobbledygook terminology. I’m the sort of person who reads academic papers for fun, and can attest that this is not a paper I remotely purport to understand or enjoyed reading. I think there are very few people on Planet Earth who have read this paper and understand it.
If you're one of these Very Few People and you're reading this, a question: do Lightning's channels only reduce on-chain transaction volume in the case of recurring payments (eg subscriptions)? What is the anticipated savings if the Lightning Network is rolled out -- how much of current transaction volume could be handled in channels?