[runeks]

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

[spiorf]

You have a wrong understanding of how LN works. You are conflating inbound and outbound liquidity. To receive 1 btc a merchant does not have to open a 1 btc channel. Another node has to open a channel with him. He can buy 1 btc of incoming liquidity for a few cents. Some nodes offer incoming liquidity for free (it costs them almost nothing to keep their btc in a channel for a while).

And your super simple setup is completely isolated from the rest of the economic world. It wouldn't even work with cash because every merchant would need to manage a cash reserve in every store, manage transfers of cash back and forth, and the associated risk. It would be expensive and inflexible.

[runeks]

> He can buy 1 btc of incoming liquidity for a few cents.

I’m very interested. Where can I buy this?

[madacol]

https://lightning.engineering/pool/

more here: https://medium.com/lightningto-me/practical-solutions-to-inb...

[spiorf]

https://lnbig.com/#/ for example, or just search for "How to get inbound liquidity on LN"

[pastech]

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

If I keep the scenario where the merchant doesn't want to lock anything in the LN, then the gateway can do it, and charge a fee for transacting through it. It's the gateway's choice to open such a channel or not. The "expensive" part is compensated by the fee which is chosen by the gateway operator.

If the merchant chooses to "lock" a bit to participate in LN, it's easier to rebalance his channels once 1000 people depleted the channel, eliminating the "inflexible". Besides, after all the fees saved by not using the Bitcoin blockchain for 1000 transactions, one can open a new channel to deal with that as well.

And again, nothing is ever "locked" in the LN, at any moment anyone (e.g. the merchant) can send everything back to on-chain or even to exchanges that use LN. There is no reason to believe that on-chain is less "locked". As such, it's not expensive nor inflexible, or in any case, less than Bitcoin itself.

Of course it would be easier if there was nothing to think about, but centralized solutions all have their set of problems as well, and that's another debate. In the mean time, LN works well at its scale and push back like yours feels like a "perfect is the enemy of good" kind of situation.