Hacker News Reader

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

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.

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

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.

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

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.

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

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

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

https://lightning.engineering/pool/

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

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

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

Correct, that's why many left and support Bitcoin Cash now.

WTF? Source?

> 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

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

+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

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.

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.