5 ms·

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/sta

by sygma 8y ago

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 https://1ml.com/statistics

runeks 8y ago
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).
- sparkie 8y ago
  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.
  - runeks 8y ago
    > 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-bitcoin-based-protocol-can-handle-more-than-20m-users-per-month.html https://runeksvendsen.github.io/blog/posts/2017-10-08-no-bit...
    - sparkie 8y ago
      > 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.
- wmf 8y ago
  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.

by sygma 8y ago

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 https://1ml.com/statistics

runeks 8y ago

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

sparkie 8y ago
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.
- runeks 8y ago
  > 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-bitcoin-based-protocol-can-handle-more-than-20m-users-per-month.html https://runeksvendsen.github.io/blog/posts/2017-10-08-no-bit...
  - sparkie 8y ago
    > 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.
wmf 8y ago
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.