3 ms·

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

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.

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.