9 ms·

Why is no one pointing out that, in order to receive bitcoins on the Lightning Network (LN), you need to lock bitcoins in a payment channel? So, if a consumer

by runeks 5y ago

Why is no one pointing out that, in order to receive bitcoins on the Lightning Network (LN), you need to lock bitcoins in a payment channel? So, if a consumer wants to send bitcoins to a merchant, either the consumer needs to lock up bitcoins in a payment channel which can only send bitcoins to that given merchant, or the consumer needs to lock up bitcoins in a payment channel to an intermediate gateway, and the merchant needs to lock up the amount of bitcoins it wants to receive in a payment channel between it and the gateway. So if 1000 consumers want to send 0.001 BTC to merchant A, via a gateway, then 1 BTC needs to be locked in a payment channel between the gateway and merchant before this can happen. This means that LN needs 2 BTC to send 1 BTC when using a single gateway. So, first of all, the gateway needs to know how many bitcoins the merchant will receive in the future, and secondly the gateway needs to borrow this amount of bitcoins in the market and lock it up in a payment channel between it and the merchant. In the end I think the capital cost of this will be too high. I think it makes more sense to use a decentralized, credit-based system such as GNU Taler (think “decentralized BTC debit card”). Merchants are then free to choose which gateways (“exchanges” in GNU Taler speak) to trust, and a payment app can work with any Taler gateway, making the system decentralized in the same way as email.

dylkil 5y ago
lightning network is a broken mess. It baffles me that so many people still pump resources into after all these years.
- itsdsmurrell 5y ago
  Correct, that's why many left and support Bitcoin Cash now.
  - vivab0rg 5y ago
    WTF? Source?
pastech 5y ago
Is it really "locking" when putting bitcoins on LN actually make them easily spendable with very little fees? Imo, all of those are outdated claims. For consumers, it's easy to open outbound channels (e.g. to well connected nodes). For merchants, it's becoming easier as well. Remember that it's a network, merchants can have outbound channels and "pay themselves" to get back inbound liquidity (can also be automated). You're not limited to one "gateway" either. If liquidity is a problem on LN right now, you're already dealing with bigger amounts that can happen on-chain. I'm not saying it's perfect, but I find LN to be elegant as a payment system for Bitcoin.
- runeks 5y ago
  > Is it really "locking" when putting bitcoins on LN actually make them easily spendable with very little fees? Merchants don’t want to spend, they want to receive. Why should a merchant have to lock e.g. $100k worth of bitcoins at the beginning of the month (in a payment channel connected to a gateway) just in order to receive that amount from consumers during that month? No other payment system in the world requires this.
  - pastech 5y ago
    Well if a merchant doesn't want to spend or lock anything, it doesn't have to. Consumers and gateways can open channels to the merchant and that's enough for them to pay the merchant. In the case of a merchant that doesn't want to participate much in the network, gateways have interest in opening to him to allow consumers to pay the merchant for a fee.
    - runeks 5y ago
      > Well if a merchant doesn't want to spend or lock anything, it doesn't have to. If the merchant wants to receive funds via the gateway then funds need to be locked in a payment channel between the gateway and the merchant. This is in addition to the funds locked in multiple payment channels between consumers and the gateway. Consider a super simple LN setup, consisting of (a) one thousand consumers, each with 0.001 BTC to spend, (b) a single gateway and (c) a single merchant. The consumers are connected to the gateway, the gateway is connected to the merchant. In order for the one thousand consumers to each send 0.001 BTC to the merchant there needs to exist a payment channel between the gateway and merchant with 1 BTC in it (assigned to the gateway), and every time 0.001 BTC is sent from the consumer to the merchant, 0.001 BTC moves from a consumer to the gateway (in one payment channel) and from gateway to merchant (in a separate payment channel). My concern here is that this is (1) expensive, and (2) inflexible. Expensive because the gateway needs to borrow 1 BTC to sit in a payment channel between it and the merchant, and inflexible because if another consumer connects to the gateway then the merchant cannot receive additional funds because it would require increasing the capacity of the channel between the gateway and merchant.
gregwebs 5y ago
From a quick reading (just spent a minute after seeing this article) lightning claims support for secure forwarding. So there might be an economic way for a payment app to operate the channel.
- runeks 5y ago
  Yes, the very basis of LN is secure forwarding between payment channels. Alice wants to send 1 BTC to Bob. Alice is connected — via a payment channel — to Mallory, and Mallory is connected to Bob. To do this Alice can send 1 BTC to Mallory, and then Mallory can send 1 BTC to Bob. This requires 1 BTC to be locked in both payment channels. The only thing LN guarantees is that the transfer is atomic, such that Mallory cannot refuse to forward the 1 BTC (received from Alice) to Bob.
madacol 5y ago
> Why is no one pointing out that, in order to receive bitcoins on the Lightning Network (LN), you need to lock bitcoins in a payment channel? I think lightning needs economy of scales in order to minimize the bitcoins "locked" perception, because once you can pay lots of your needs with lightning then those bitcoins are not "locked" anymore. Though that's assuming consumers run lightning nodes too, which need to be online 24/7, and have routing connections, which is unrealistic for average users. My guess is that average consumers will use some kind of (semi-)custodial lightning wallet
- runeks 5y ago
  > I think lightning needs economy of scales in order to minimize the bitcoins "locked" perception, because once you can pay lots of your needs with lightning then those bitcoins are not "locked" anymore. What do you base this assumption on? Once there’s a gateway between a consumer and a merchant, then sending e.g. 0.001 BTC from the consumer to the merchant happens by the consumer sending it to the gateway in one payment channel, and the gateway sending the same amount to the merchant in a separate payment channel. It’s atomic, so the funds are guaranteed to arrive, but it requires locking the amount that the merchant expects to receive in a payment channel between it and the gateway. This is how the LN protocol works.
  - madacol 5y ago
    +1, AFAICT what you said is accurate (^.^) But LN is more productive in an interconnected economy Let me take your own example to the extreme case and let's assume every entity in the world has a channel opened to only one gateway. e e e \ | / gateway / | \ e e e With this topology, only this gateway has its bitcoin "locked" but earn fees routing, everybody else is free to move their bitcoin to whoever they want, as long as the gateway has enough bitcoins "locked" with the receiver. But keep in mind that the gateway can move x100 the volume of bitcoins they have locked, because money moves back and forth I think a more decentralized topology, where most entities are gateways too, will have less bitcoins "locked", but I don't know by how much, 30% less?, 70%?, 95%?, I'm not sure, but I think it's probably better than last scenario. Nevertheless, no matter how good the LN gets, its inevitable that some bitcoins will indeed get locked, when any gateway spends all of its bitcoins then everybody else connected to that gateway cannot route payments through it, and unless they intend to pay directly to the "bankrupted" gateway, those bitcoins are indeed locked. I think no matter the scenario, LN reduces the need to transact onchain, and the better interconnected the economy is with the LN, more effective it is at doing so. So I think a better metric to follow is the #-of-onchain-bytes that were saved thanks to the LN Another thing to point out is that we are talking about the LN that is deployed today, we haven't taken into account future improvements that might come, like multiparty channels. I think the serious technical problems that the LN really has today, is that it's not that robust for gateways, I've heard it has DoS weaknesses, and privacy issues, and I'm not sure how solvable some of them are if the topology becomes centralized with just a few gateways
spiorf 5y ago
> Why is no one pointing out that, in order to receive bitcoins on the Lightning Network (LN), you need to lock bitcoins in a payment channel? Because it is false. To receive bitcoins on the LN you need to have a node. Other parties can open a channel with you to send you money. > lock up bitcoins in a payment channel which can only send bitcoins to that given merchant This is again false. The consumer can pay anyone on LN. The nodes you call "gateways" are just regular nodes, some with more funding than others. You can choose to run a regular node and keep it online and use it to route payments for other, or you can use a light wallet that opens a private channel and uses channel hints to route payments through his private channel to the network. Bitcoins "locked" in a channel are not locked at all, You can send them to whoever you can route to on LN, or get it back to a regular on-chain wallet. And nowadays a well connected node reaches every other node. > the gateway needs to know how many bitcoins the merchant will receive No, the gateway needs to manage cash flow like every other money-transacting entity. There just needs to be enough capacity, like you need enough cash in a cash register. You do not need to know in advance the sum. And you can replenish and empty channels with one on-chain tx, so no need to close and re-open channels. > the gateway needs to borrow this amount of bitcoins in the market and lock it up in a payment channel between it and the merchant. You got it wrong. First, gateways (that are just regular nodes, some running on raspberri pis) are already online, and with funding (https://1ml.com/ https://1ml.com/). Those are already denominated in btc, so price do not affects funding capability. Second, replace "gateway" with "the LN network". A gateway has some funding and locks it up in some channel to the LN network (meaning some other nodes) Third, those bitcoins are not really locked for anything, but let's keep using this word. So the "gateway" can be anyone with some bitcoins he might want to spend on LN (or not).

by runeks 5y ago

dylkil 5y ago

lightning network is a broken mess. It baffles me that so many people still pump resources into after all these years.

itsdsmurrell 5y ago
Correct, that's why many left and support Bitcoin Cash now.
- vivab0rg 5y ago
  WTF? Source?

pastech 5y ago

Is it really "locking" when putting bitcoins on LN actually make them easily spendable with very little fees? Imo, all of those are outdated claims. For consumers, it's easy to open outbound channels (e.g. to well connected nodes). For merchants, it's becoming easier as well. Remember that it's a network, merchants can have outbound channels and "pay themselves" to get back inbound liquidity (can also be automated). You're not limited to one "gateway" either. If liquidity is a problem on LN right now, you're already dealing with bigger amounts that can happen on-chain. I'm not saying it's perfect, but I find LN to be elegant as a payment system for Bitcoin.

runeks 5y ago
> Is it really "locking" when putting bitcoins on LN actually make them easily spendable with very little fees? Merchants don’t want to spend, they want to receive. Why should a merchant have to lock e.g. $100k worth of bitcoins at the beginning of the month (in a payment channel connected to a gateway) just in order to receive that amount from consumers during that month? No other payment system in the world requires this.
- pastech 5y ago
  Well if a merchant doesn't want to spend or lock anything, it doesn't have to. Consumers and gateways can open channels to the merchant and that's enough for them to pay the merchant. In the case of a merchant that doesn't want to participate much in the network, gateways have interest in opening to him to allow consumers to pay the merchant for a fee.
  - runeks 5y ago
    > Well if a merchant doesn't want to spend or lock anything, it doesn't have to. If the merchant wants to receive funds via the gateway then funds need to be locked in a payment channel between the gateway and the merchant. This is in addition to the funds locked in multiple payment channels between consumers and the gateway. Consider a super simple LN setup, consisting of (a) one thousand consumers, each with 0.001 BTC to spend, (b) a single gateway and (c) a single merchant. The consumers are connected to the gateway, the gateway is connected to the merchant. In order for the one thousand consumers to each send 0.001 BTC to the merchant there needs to exist a payment channel between the gateway and merchant with 1 BTC in it (assigned to the gateway), and every time 0.001 BTC is sent from the consumer to the merchant, 0.001 BTC moves from a consumer to the gateway (in one payment channel) and from gateway to merchant (in a separate payment channel). My concern here is that this is (1) expensive, and (2) inflexible. Expensive because the gateway needs to borrow 1 BTC to sit in a payment channel between it and the merchant, and inflexible because if another consumer connects to the gateway then the merchant cannot receive additional funds because it would require increasing the capacity of the channel between the gateway and merchant.

gregwebs 5y ago

From a quick reading (just spent a minute after seeing this article) lightning claims support for secure forwarding. So there might be an economic way for a payment app to operate the channel.

runeks 5y ago
Yes, the very basis of LN is secure forwarding between payment channels. Alice wants to send 1 BTC to Bob. Alice is connected — via a payment channel — to Mallory, and Mallory is connected to Bob. To do this Alice can send 1 BTC to Mallory, and then Mallory can send 1 BTC to Bob. This requires 1 BTC to be locked in both payment channels. The only thing LN guarantees is that the transfer is atomic, such that Mallory cannot refuse to forward the 1 BTC (received from Alice) to Bob.

madacol 5y ago

> Why is no one pointing out that, in order to receive bitcoins on the Lightning Network (LN), you need to lock bitcoins in a payment channel? I think lightning needs economy of scales in order to minimize the bitcoins "locked" perception, because once you can pay lots of your needs with lightning then those bitcoins are not "locked" anymore. Though that's assuming consumers run lightning nodes too, which need to be online 24/7, and have routing connections, which is unrealistic for average users. My guess is that average consumers will use some kind of (semi-)custodial lightning wallet

runeks 5y ago
> I think lightning needs economy of scales in order to minimize the bitcoins "locked" perception, because once you can pay lots of your needs with lightning then those bitcoins are not "locked" anymore. What do you base this assumption on? Once there’s a gateway between a consumer and a merchant, then sending e.g. 0.001 BTC from the consumer to the merchant happens by the consumer sending it to the gateway in one payment channel, and the gateway sending the same amount to the merchant in a separate payment channel. It’s atomic, so the funds are guaranteed to arrive, but it requires locking the amount that the merchant expects to receive in a payment channel between it and the gateway. This is how the LN protocol works.
- madacol 5y ago
  +1, AFAICT what you said is accurate (^.^) But LN is more productive in an interconnected economy Let me take your own example to the extreme case and let's assume every entity in the world has a channel opened to only one gateway. e e e \ | / gateway / | \ e e e With this topology, only this gateway has its bitcoin "locked" but earn fees routing, everybody else is free to move their bitcoin to whoever they want, as long as the gateway has enough bitcoins "locked" with the receiver. But keep in mind that the gateway can move x100 the volume of bitcoins they have locked, because money moves back and forth I think a more decentralized topology, where most entities are gateways too, will have less bitcoins "locked", but I don't know by how much, 30% less?, 70%?, 95%?, I'm not sure, but I think it's probably better than last scenario. Nevertheless, no matter how good the LN gets, its inevitable that some bitcoins will indeed get locked, when any gateway spends all of its bitcoins then everybody else connected to that gateway cannot route payments through it, and unless they intend to pay directly to the "bankrupted" gateway, those bitcoins are indeed locked. I think no matter the scenario, LN reduces the need to transact onchain, and the better interconnected the economy is with the LN, more effective it is at doing so. So I think a better metric to follow is the #-of-onchain-bytes that were saved thanks to the LN Another thing to point out is that we are talking about the LN that is deployed today, we haven't taken into account future improvements that might come, like multiparty channels. I think the serious technical problems that the LN really has today, is that it's not that robust for gateways, I've heard it has DoS weaknesses, and privacy issues, and I'm not sure how solvable some of them are if the topology becomes centralized with just a few gateways

spiorf 5y ago

> Why is no one pointing out that, in order to receive bitcoins on the Lightning Network (LN), you need to lock bitcoins in a payment channel? Because it is false. To receive bitcoins on the LN you need to have a node. Other parties can open a channel with you to send you money. > lock up bitcoins in a payment channel which can only send bitcoins to that given merchant This is again false. The consumer can pay anyone on LN. The nodes you call "gateways" are just regular nodes, some with more funding than others. You can choose to run a regular node and keep it online and use it to route payments for other, or you can use a light wallet that opens a private channel and uses channel hints to route payments through his private channel to the network. Bitcoins "locked" in a channel are not locked at all, You can send them to whoever you can route to on LN, or get it back to a regular on-chain wallet. And nowadays a well connected node reaches every other node. > the gateway needs to know how many bitcoins the merchant will receive No, the gateway needs to manage cash flow like every other money-transacting entity. There just needs to be enough capacity, like you need enough cash in a cash register. You do not need to know in advance the sum. And you can replenish and empty channels with one on-chain tx, so no need to close and re-open channels. > the gateway needs to borrow this amount of bitcoins in the market and lock it up in a payment channel between it and the merchant. You got it wrong. First, gateways (that are just regular nodes, some running on raspberri pis) are already online, and with funding (https://1ml.com/ https://1ml.com/). Those are already denominated in btc, so price do not affects funding capability. Second, replace "gateway" with "the LN network". A gateway has some funding and locks it up in some channel to the LN network (meaning some other nodes) Third, those bitcoins are not really locked for anything, but let's keep using this word. So the "gateway" can be anyone with some bitcoins he might want to spend on LN (or not).