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.

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.

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

> 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).