Hacker News new | past | comments | ask | show | jobs | submit login

For those wondering about how much the lightning network is actually used, have a look at the stats [0]. Adoption is growing steadily.

[0]: https://1ml.com/statistics




One of the problems with LN is that, in order to actually receive BTC (on the Bitcoin blockchain) that you can sell, you almost certainly need to go through multiple LN nodes. Due to this, the node in this path with the smallest capacity will determine the maximum amount you can transfer (before needing to touch the blockchain). From the stats we can see that "Average Channel Capacity" is 0.025 BTC/$91.77, and that 50% of channels have a capacity of 0.005 BTC/$18.35, which means the minimum, for any given path, is likely close to $20.

So, in other words, you can expect to transfer, roughly, $20 until you need to touch the blockchain again (in order to fund a channel), which means that sending ~$20 over LN is as expensive as doing it in a normal Bitcoin transaction.

LN doesn't scale because of this. People keep pretending that adding new nodes is a sign of success, when in fact adding new nodes to LN decreases performance -- because the smallest-capacity channel on a path determines how much can be sent through that path until you have to touch the blockchain. If two or more channels in a path need to be refilled, you've spent more on a LN transfer than you would have on a regular Bitcoin transaction (on-blockchain).


The channel capacities in Lightning are currently restricted by an arbitrary limit of 2^24 satoshis which was put there by the developers to prevent people from putting too much into what is effectively a beta test network currently. The limit is already scheduled to be removed in the 1.1 BOLT spec.

There are usually many possible paths for a payment, so the payment limit isn't the minimum of any possible node along the route, but the set of all possible routes from one node to another. However, even this is scheduled to be removed, because LN will get Atomic Multi-Path Payments, which will enable a payment to traverse multiple routes and only succeed if all of the routes are successful.

"Refilling" of Lightning channels does not require new on-chain payments - it can be done directly on the Lightning network by routing payments through paths which require balances moving in one direction or another. You can route payments to yourself to reduce your balance in one path and fill it in another path.

Putting aside large payments for a moment, you're completely ignoring the potential use-cases for small payments. Currently you can make thousands of transactions on the Lightning Network, with fees averaging hundredths of a cent. This was possible on Bitcoin in the early days, but clearly cannot scale because it costs money to store and propagate information on a broadcast network. Lightning doesn't broadcast any transactions, and doesn't need to store old transactions. The use cases are left up to your imagination.

If you wish to learn more I recommend reading the BOLT specifications and subscribing to the lightning-dev mailing list.


> There are usually many possible paths for a payment, so the payment limit isn't the minimum of any possible node along the route, but the set of all possible routes from one node to another.

My main gripe with LN is this: why would I want to route a payment through a bunch of arbitrary nodes (which may or may not process my transaction), rather than just establish a connection with a single node, who I pay to guarantee uptime?

> "Refilling" of Lightning channels does not require new on-chain payments - it can be done directly on the Lightning network by routing payments through paths which require balances moving in one direction or another.

If we assume the products purchased via LN need to be paid for in national currency, then on-chain payment is needed in order to refill a channel, since the merchant (payment receiver) will need to withdraw BTC from LN and convert to a national currency in order to pay a supplier. If BTC is withdrawn from LN, then it needs to be deposited again.

If LN isn't supposed to be used for this, then I agree that on-chain transactions aren't needed, but then LN isn't really a competitor to traditional payment networks (since you can't buy e.g. a cup of coffee with it).

> Putting aside large payments for a moment, you're completely ignoring the potential use-cases for small payments.

I don't think I am. In order for small payments to be of value, it must be possible to receive a lot of them, and LN only supports up to ~20M users per month[1] (while using up the entire capacity of the Bitcoin blockchain).

LN payments have value because they can be redeemed into BTC (on the blockchain). In order for a payment network to be successful, it must be fairly cheap to move value through the economic circle composed of 1) consumer, 2) retailer (merchant), 3) supplier, 4) producer (and then back to the consumer, in the form of wage paid by a producer). The bottleneck of this movement is still the Bitcoin blockchain, and LN doesn't do much to help it, unfortunately.

[1] https://runeksvendsen.github.io/blog/posts/2017-10-08-no-bit...


> why would I want to route a payment through a bunch of arbitrary nodes, rather than just establish a connection with a single node, who I pay to guarantee uptime?

There are already countless systems to do the latter. You can use PayPal, MasterCard, Stripe, etc, etc. The point of Bitcoin is to eliminate trusted third-parties. Nobody can guarantee uptime, only give you an empty promise. Bitcoin can guarantee uptime isn't tied to any one or few parties.

Bitcoin requires anonymous third-parties to propagate your payments to miners. You aren't an island. The anonymous trustless third-parties who route payments in LN are just regular users, have no access to information about the payment they're routing, and are negatively incentivized to be dishonest, because they have to pay bitcoin transaction fees themselves for any of their own channels they unilaterally close.

> If we assume the products purchased via LN need to be paid for in national currency, then on-chain payment is needed in order to refill a channel, since the merchant (payment receiver) will need to withdraw BTC from LN and convert to a national currency in order to pay a supplier. If BTC is withdrawn from LN, then it needs to be deposited again.

Again, this is nonsense. Exchanges between fiat and bitcoin can operate directly on the Lightning Network. There's no need to constantly open and close channels. You would send a direct lightning payment to your exchange to deposit money, or you would issue a lightning invoice to your exchange to withdraw money.

> LN payments have value because they can be redeemed into BTC (on the blockchain). In order for a payment network to be successful, it must be fairly cheap to move value through the economic circle composed of 1) consumer, 2) retailer (merchant), 3) supplier, 4) producer (and then back to the consumer, in the form of wage paid by a producer). The bottleneck of this movement is still the Bitcoin blockchain, and LN doesn't do much to help it, unfortunately.

As above, the bottleneck is removed by the consumer, retailer, supplier and producer all being on the Lightning Network.

In situations where a supplier offers a merchant credit, this is an ideal case for plain old payment channels. Instead of offering individual Bitcoin transactions, they can open a payment channel and issue RSMCs when a business invoice is created or paid. Using a plain payment channel is a missed opportunity though - because it can only be used by the supplier and merchant. By connecting that very same payment channel to the LN, opportunities are opened up for both the merchant and supplier. The merchant can make use of the suppliers payment channel network to transact with a wider audience, and vice-versa. They can all save on transaction costs for channel opening and closing by pooling resources which would otherwise be underutilized.

The Lightning Network is fundamentally an abstract protocol for creating and connecting different kinds of payment channels, providing encrypted and authenticated transport, and an onion routed transport for payments. Currently, theres only one type of payment channel it supports, but this is simply down to there being few developers with different priorities.


> Again, this is nonsense. Exchanges between fiat and bitcoin can operate directly on the Lightning Network. There's no need to constantly open and close channels. You would send a direct lightning payment to your exchange to deposit money, or you would issue a lightning invoice to your exchange to withdraw money.

In this world where no LN-transaction touches the Bitcoin blockchain, what's the reason for having a blockchain in the first place?


The blockchain provides the security, ensuring that nobody can take funds unilaterally out of a channel. At all times, each party has bitcoin transactions for the correct channel state, partially signed by the channel's counter party, which either party can sign at any time to settle the channel balance on the chain (the settlement can be made to pay automatically into new lightning channels, although this is not implemented yet.)

It is like a credit line that can be closed by either party at any time, with the balance settled automatically by an impartial judge - the blockchain. Without the chain, we'd just have the existing system where you need human arbitration to settle balances if any party disagrees about their balance.

Bitcoin takes individual humans out of decision making about who owns what money. That's its fundamental purpose. We can build potentially any number of transaction systems on top of it, but it is not worth sacrificing the impartiality of the chain just to get a marginal increase in capacity of on-chain transactions. The chain's impartiality depends on the network being so finely distributed that no group can orchestrate control over it. This also requires that participants can be anonymous.


Realistically, LN paths will look like Alice -> hub1 -> hub2 -> Bob or maybe even Alice -> hub -> Bob so the capacity of random channels won't matter.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: