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

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.

Joe

Posted 2017-06-04T23:16:00.207

Reputation: 143

Answers

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.

Murch

Posted 2017-06-04T23:16:00.207

Reputation: 41 609

Very interesting. Although in your David and Rob example it would depend on the state of the channel at the moment I wish to push my payment through? Thinking this through, though - assuming David and Rob establish their channel because they actively transact between themselves, I suppose there could be cases where David and Rob don't want a third party transaction to be routed through their channel to skew the current balance one particular way, either. – Joe – 2017-06-05T07:50:51.220

Building on the original point - it would seem that there's a massive issue of committing BTC into channels. Generalising this it would seem to be the case that if everyone is on average n channels away from each other and the network is to handle x BTC per day in transaction volume, there must be at a minimum xn BTC committed to channels in the network. But likely much more to cope with what you are saying. Even if everyone centralises around one node that node would have a massive capital requirements (even for micropayments) for a minimal return with fees. – Joe – 2017-06-05T07:57:56.630

1@Joe: I've updated my answer to include a couple mor ethoughts. – Murch – 2017-06-06T06:34:50.453

Couldn't Alice just send 10 payments of 10btc (or 5 payments of 20btc) in this scenario? These are off chain transactions right? So I imagine the total cost of doing this would be smaller than one on chain txn. – dimsumcode – 2018-01-22T00:02:02.643

@dimsumcode: Alice can only send as much as the sum of her balances across all of her channels. She could send that much if she has that much. – Murch – 2018-01-22T05:36:01.433

@Murch thanks. I think in reality there would be many routes from Alice to Bob. And like you said they should cumulatively be able to handle her 100 btc payment. We'll surely find out soon. – dimsumcode – 2018-01-22T18:07:34.933

@Murch does that mean the answer is "yes" to dimsumcode's question? – Casey Harrils – 2018-04-24T14:45:05.337

@CaseyHarrils: Yes, you could split up the payments into smaller chunks, but I don't think that payments of more than a few millibitcoins will be practical for the near future. – Murch – 2018-04-24T14:58:36.583

@Murch "a few millibitcoins" - can you convert to dollar value? For example, are you saying payments like $6 or 6 cents would not be practical? – Casey Harrils – 2018-04-24T15:06:32.533

1 mBTC = 0.001 BTC ~ $9.4 USD today. I think that currently most payment channels have very thin capacities and payments of more than ~$100 might have an issue finding routes. – Murch – 2018-04-24T15:17:16.317

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.

theCodeBear

Posted 2017-06-04T23:16:00.207

Reputation: 11