Indeed there are clearing protocols on top of Bitcoin, which can reduce fee-paying to only occur upon depositing and redemption. But the Bitcoin blockchain is still limited to ~20 million of such transactions per month[1].
Only if we remove the withdrawal transactions from the equation, and start trading unconfirmed transactions as regular bitcoins (confirmed transactions), can we get around this limitation (such that only the number of new users joining is limited to 20M per month). I’m somewhat skeptical this can work, though, since recipients of funds usually have suppliers to pay, so I assume that we need to settle on the blockchain at least monthly.
A Lightning Network transaction results in one of two things - a proof that a certain amount of bitcoins can be withdrawn at any time (minus some delay), or a proof of cheating. Surely a proof that you can withdraw a certain amount of bitcoins is more-or-less equivalent to that many bitcoins, and therefore any rational actor - including your suppliers - should accept it as such?
This isn't equivalent to unconfirmed transactions - it's tokens of exchange which directly and provably represent bitcoins. Settling on the blockchain shouldn't even have to happen monthly.
One of the other interesting things is that Lightning Network allows for payment in one cryptocurrency while you hold another by channeling it through a very simple, provable currency exchange. This could behave similarly to, for example, paying for something in USD when you hold GBP - practically automatically. So the lack of scalability in Bitcoin's blockchain might not matter so much - if something else turns up that's better for a given person holding money, they can start using it while still continuing to trade with all the people using Bitcoin.
IMHO, cross-chain transactions like this are one of the most important parts of Lightning Network - suddenly, network effects around a specific currency don't matter so much, people can hold whatever they like - Bitcoin people can trade with Litecoin people who can trade with Ethereum scripts, and when something new that solves more problems turns up, people holding that can still buy VPSes with bitcoin.
In Japan, because debit/credit cards have historically not been readily available, a payment system around transit cards has been built up. People put money on to their transit cards and then can use those cards to pay for a variety of things from items in vending machines to MacDonald's, etc. In usage it basically works pretty similar to how the Lightning network will work and it's relatively popular.
However, I think the OP is correct that if it becomes mainstream, 20M transactions a month will not be enough. Lightning requires 2 transactions -- one to reserve the funds and one to settle up at the end of the period. The transactions cancel if you do not settle up, so setting that period of time is vital. If you set it to a month (probably reasonable), then you are basically limiting the service to 10M users (assuming the OP's estimate of 20M transactions a month is correct -- I haven't checked).
So I think it's pretty obvious that you are going to have to do something else
I think it is worth pointing out that it is not exactly equivalent, in the sense that if you pay Steam via a payment channel (for simplicity, a one-directional payment channel, so they don't need to lock up any cryptocurrency themselves), they don't need to settle on-chain, but if they don't do so they cannot use the "money" the received from you to pay someone else (eg their lawyer).
In the very long term, if we get to a point where most people's and organization's income is roughly equal to their expenditure, then this won't be a problem, but until then there is still pressure to settle on-chain because of this.
> if they don't do so they cannot use the "money" the received from you to pay someone else (eg their lawyer).
They certainly can if their lawyer is also on the Lightning Network.
Eventually all Bitcoin wallets should support on-chain and Lightning Network transactions, and seamlessly pick one or the other depending on the transaction amount.
No, they really can't. They have to open a payment channel with their lawyer (or open it with someone who has a path of channels to their lawyer), and that requires them to own cryptocurrency on-chain to use as stake (what LN calls the funding transaction)
No, even if their lawyer is on the LN, Steam cannot pay their lawyer via payment channel, unless Steam owns some cryptocurrency on-chain to use as deposit
> Surely a proof that you can withdraw a certain amount of bitcoins is more-or-less equivalent to that many bitcoins, and therefore any rational actor - including your suppliers - should accept it as such?
The problem is fees. If this rational actor has 10,000 proofs of payment from as many different people, then the settlement transaction might require the redemption of up to 10,000 inputs, which would make payments prohibitively expensive. It may even be impossible to settle in a single block, since the transaction (including dependencies) might exceed the maximum block size.
A proof that 0.001 BTC can be withdrawn at any time isn’t very useful if the cost of withdrawal is 0.001 BTC.
In other words, LN surely has the value transfer part solved. But I don’t see how it solves the clearing part, that is: grouping multiple payments from different clients into a single, low-fee Bitcoin transaction. I understand how fees are saved on multiple payments from the same client (that’s what a payment channel does), but not how it would work with payments from many different clients (which is what merchants need to handle).
I tried a few times to read about the Lightning Network and it seems complicated to understand and implement. I'm not an expert at all but it seems like a flaw in the Bitcoin protocol that you have to build something like this on top.
Are there other cryptocoins that are built on protocols that avoid having to have this extra layer on top to make them scalable? I imagine the more complexity that is added, the more scope there is for security, implementation and scalability issues so you want to keep things simple.
I agree that Payment Channels is a good step forward but there's the hard limit on how many channels can be open. I'm confident that there will be proposals similar to Poon et al. [1] to create a third layer for networks of payment channels where a Blockchain tx can be used only in case of uncooperative channel counterparties.
I’ve read that paper, and I don’t quite understand how it would work when you need multiple clients to cooperate for a single client to make a payment. I.e. if the funds of 100 clients is at some multi-sig address, you’d save blockchain space, but payment from any of these 100 clients would require simultaneous cooperation from the remaining 99 clients. I have a hard time seeing how this would work in practice.
Only if we remove the withdrawal transactions from the equation, and start trading unconfirmed transactions as regular bitcoins (confirmed transactions), can we get around this limitation (such that only the number of new users joining is limited to 20M per month). I’m somewhat skeptical this can work, though, since recipients of funds usually have suppliers to pay, so I assume that we need to settle on the blockchain at least monthly.
[1] https://runeksvendsen.github.io/blog/posts/2017-10-08-no-bit...