Is lightning network limited by the 'size' of channels?

Question

Imagine we start with multiple channels which eventually link two individuals, Alice and Rob: (the BTC amounts is the total locked in their multisig address for their channels between each other)

Alice --- 100 BTC ---> David --- 50 BTC ---> Rob

Now - suppose Alice wants to send 100 BTC to Rob. Alice is connected to Rob via David but there's only 50 BTC available to be distributed between David and Rob. Therefore Rob cannot trust a payment of 100 BTC from David.

How does Alice deal with this?

Assuming Alice does not have another 100 BTC sitting around outside of lightning - she has to close out her channel with David; wait for confirmation of this; and then send Rob a traditional transaction to make payment (or open a channel with him). Is this correct? Or is there a better way of dealing with this? Some way of passing value between channels?

If not - is this a problem for lightning network? It would seem that routing across channels is only as useful as the smallest connecting channel. And users have every incentive to keep channels as small as possible to minimise 'committed' BTC. If users have to wait for confirmation to close out a channel, their ability to make fast payments over the original bitcoin network is vastly slowed down by having to wait for confirmation of a channel closure before being able to conduct a transaction on the main network.

Answer 1

In fact, it's worse: payment channels can only transfer the balance that belongs to the sender in it. So, if David and Rob each paid 25BTC into the channel, David can at most send 25 BTC to Rob.— However, there could actually be multiple paths from Alice to Rob which could in parallel allocate 100BTC to Rob.

There's an interesting trade-off here: the Bitcoin blockchain scales easily in the amounts to be settled, but is limited in transaction throughput. Lightning Network on the other hand is practically unlimited in the transaction throughput, however limited in the amounts to be sent. This is why transactions on the blockchain are priced by the cost of including them in the block, i.e. the primary bottleneck, and transactions in the Lightning Network will probably be priced mostly relative to the value they transfer. Obviously, this favors larger value transfers on the blockchain and smaller payments to move to the Lightning Network. However, sending smaller payments requires both a smaller locked-in amount, and will make it easier to find routes.

So, it may actually just work out.— We'll see when it goes live on the Bitcoin blockchain.

Answer 2

The problem here is you are treating the LN as though its for single payments. If Alice is going to send Rob all the Bitcoin she has in a payment channel, why would she have opened up the payment channel in the first place. There would be no reason. She would just make the transaction on-chain. Remember that the point of the LN is to be able to make a bunch of payments. So you are never going to fund a payment channel only with enough coin to make a single transaction. The LN will be used for many small transactions. So you'll say put $500 worth of Bitcoin into a payment channel in order to use it to buy everyday things a bunch of times. The throughput of a typical node (amount in the node) is going to be much larger than the typical transaction amount, otherwise there would be no reason to use the LN over on-chain transactions if you were just opening up a channel for one-off or two-off transactions.

Now yes if you put a ton of bitcoin into a payment channel and at some later point in time you wanted to send a significant portion of that in a single transaction you may find it hard to route to the destination. But even in this scenario you could just send it in several smaller transactions, and obviously a well designed LN node would handle this automatically if your payment was too large, so the end user wouldn't even have any idea about this.

Finally, your statement "And users have every incentive to keep channels as small as possible to minimise 'committed' BTC." is just simply not true. In fact it is the opposite. If you keep a channel as small as possible that means you are doing less txs through the LN and more opening and closing channels on-chain, meaning it is costing you more money. So actually, users have every incentive to maximize (within reason) the size of their channels so as to avoid on-chain fees. Remember 'committed' BTC isn't in some place you can't access it, in fact it is much more accessible because its on the LN (once the LN grows to a sufficient size so that the network effects are strong). The LN is for the use case of using Bitcoin as a payment network, and LN will be far superior to on-chain in terms of speed and fees. So it's not like coins in a payment channel are locked away, they are in fact simply stored in a way that makes them much more efficiently used.