<blockquote>
<p>he opens a &quot;channel&quot; to me, funds it with 1 BTC, and executes the transaction. Opening that channel costs him an on-chain transaction fee so he hasn't really saved any money yet by using Lightning Network</p>
</blockquote>
<p>Right, lightning channels are interesting in part because they allow users to send a huge number of payments over time, effectively amortizing the on-chain transaction fees over that huge number of payments. Opening a channel to make a single payment is wasteful.</p>
<blockquote>
<p>I can't use the 1 BTC received from my customer to contribute toward that purchase. That 1 BTC is all locked up. Unless I close that channel, the only thing I can do is send it back to my customer, or some other third party downstream from him, and only if the amount is less than 1 BTC, and only if every channel between the source and destination have 1 BTC of capacity. Is this correct?</p>
</blockquote>
<p>Not quite correct, for example '<a href="https://bitcoin.stackexchange.com/questions/tagged/atomic-multi-path-payments?tab=Votes">multi path payments</a>' allow a user to send a payment using the capacity in several different channels at once, atomically. So you could perhaps use some of that 1BTC channel to complete the payment, but of course you'll need other channels with capacity as well, and your node will need to find routes for each part of the payment.</p>
<blockquote>
<p>then it means to make LN viable, pretty much everyone needs to be connected to well-connected hubs, as opposed to just creating a bunch of highly specific customer-to-vendor channels</p>
</blockquote>
<p>The lightning network is constantly evolving, so it is tough to give a definitive answer for what it might look like in the future, but there seems to be some consensus around the idea that it is a good idea to look for certain attributes in a channel partner. Good connectivity to the network graph, good liquidity, and good uptime are examples of attributes you may look for when selecting someone to open a channel with. You don't necessarily even need to open channels directly to your customer/vendor, though in some cases it certainly may make sense to.</p>
<blockquote>
<p>I, as the service provider, would expect to open a channel to the hub with zero BTC. After all, I don't owe anyone anything. My goal is to receive. The hub presumably wouldn't be responsible for funding the channel either (would they?) since they have no part in the transaction</p>
</blockquote>
<p>There are several ideas already implemented to deal with this, for example check out <a href="https://pool.lightning.engineering/overview" rel="nofollow noreferrer">lightning pools</a>, which is a market that allows you to rent incoming liquidity from other lightning users. There are also several service providers operating in the space that offer this inbound liquidity rental service as well.</p>

CC BY-SA 4.0
2021-12-09T02:35:12.223Z
Looks like I'm neither allowed to upvote, nor mark as a correct answer (I create a new account for each StackExchange question; restriction has something to do with account age) but just want to thank you for the reply. This has pointed me in the right direction. Multipath payments sounds awesome and changes the whole ballgame. Love it. Looks like I've got some reading to do! Thanks again.
Third-rate Coder
CC BY-SA 4.0
2021-12-08T22:55:22.530Z
2021-12-08T22:55:22.530Z
chytrik
<p><strong>Background</strong></p>
<p>Long time Bitcoin holder and user, but exclusively on-chain. I'm completely new to the Lightning Network.</p>
<p>While waiting for my <a href="https://rads.stackoverflow.com/amzn/click/com/1492054860" rel="nofollow noreferrer" rel="nofollow noreferrer">Mastering Lightning Network</a> book to arrive, I'm just trying to pick up the basics via podcasts and articles. A particular podcast I listened to yesterday was one entitled <a href="https://www.coindesk.com/podcasts/coindesk-podcast-network/exploring-bitcoins-lightning-network/" rel="nofollow noreferrer">Exploring Bitcoin's Lightning Network</a>.</p>
<p>At one point the chick hosting the podcast asked something along the lines of, &quot;What if I don't want to send Bitcoin? What if I just want to <em>receive</em> it?&quot; It's a good question because that's the position a lot of vendors will be in. To which one of the experts replied something along the lines of: if you want the wallet provider to establish a channel with you, they'll charge a 1% commission. I've found a similar thread on Reddit complaining about this high wallet fee so I'd like to get to the bottom of it.</p>
<p><strong>Specific Questions</strong></p>
<p>A customer owes me 1 BTC for services rendered. We've never done business before. As I understand it, he opens a &quot;channel&quot; to me, funds it with 1 BTC, and executes the transaction. Opening that channel costs him an on-chain transaction fee so he hasn't really saved any money yet by using Lightning Network.</p>
<p>Now I want to spend 2 BTC to buy a gold-plated figurine of Dennis Rodman. If I understand the podcast and articles correctly, I can't use the 1 BTC received from my customer to contribute toward that purchase. That 1 BTC is all locked up. <strong>Unless I close that channel, the only thing I can do is send it back to my customer, or some other third party downstream from him, and only if the amount is less than 1 BTC, and only if every channel between the source and destination have 1 BTC of capacity. Is this correct?</strong></p>
<p>If this is correct, then it means to make LN viable, pretty much everyone needs to be connected to well-connected hubs, as opposed to just creating a bunch of highly specific customer-to-vendor channels. But that's where I get lost.</p>
<p>I, as the service provider, would expect to open a channel to the hub with zero BTC. After all, I don't owe anyone anything. My goal is to <em>receive.</em> The hub presumably wouldn't be responsible for funding the channel either (would they?) since they have no part in the transaction. But an empty channel can't conduct business.</p>
<p>So how does this work? <strong>It sounds almost like I'd have to front an amount of BTC equal to what I expect to receive from my customers over the long-term, fund the channel to the hub with it, keeping the BTC on the remote side of the channel which incurs counterparty risk, and then pay a fee to the hub/wallet 1% for the privilege</strong>. I hope I'm missing something. Is this indeed the way things work? <strong>If not, how should a vendor coordinate with his customers who want to pay via LN?</strong> How should the channels be established and funded, preferably in a way that bypasses the high wallet fees mentioned above?</p>

<lightning-network>
Basic Lightning Network Questions re: fees, channel management
Third-rate Coder
# Basic Lightning Network Questions re: fees, channel management

(Asked by: username_0 on 2021-12-08)

**Background**

Long time Bitcoin holder and user, but exclusively on-chain. I'm completely new to the Lightning Network.

While waiting for my [Mastering Lightning Network](https://rads.stackoverflow.com/amzn/click/com/1492054860) book to arrive, I'm just trying to pick up the basics via podcasts and articles. A particular podcast I listened to yesterday was one entitled [Exploring Bitcoin's Lightning Network](https://www.coindesk.com/podcasts/coindesk-podcast-network/exploring-bitcoins-lightning-network/).

At one point the chick hosting the podcast asked something along the lines of, "What if I don't want to send Bitcoin? What if I just want to *receive* it?" It's a good question because that's the position a lot of vendors will be in. To which one of the experts replied something along the lines of: if you want the wallet provider to establish a channel with you, they'll charge a 1% commission. I've found a similar thread on Reddit complaining about this high wallet fee so I'd like to get to the bottom of it.

**Specific Questions**

A customer owes me 1 BTC for services rendered. We've never done business before. As I understand it, he opens a "channel" to me, funds it with 1 BTC, and executes the transaction. Opening that channel costs him an on-chain transaction fee so he hasn't really saved any money yet by using Lightning Network.

Now I want to spend 2 BTC to buy a gold-plated figurine of Dennis Rodman. If I understand the podcast and articles correctly, I can't use the 1 BTC received from my customer to contribute toward that purchase. That 1 BTC is all locked up. **Unless I close that channel, the only thing I can do is send it back to my customer, or some other third party downstream from him, and only if the amount is less than 1 BTC, and only if every channel between the source and destination have 1 BTC of capacity. Is this correct?**

If this is correct, then it means to make LN viable, pretty much everyone needs to be connected to well-connected hubs, as opposed to just creating a bunch of highly specific customer-to-vendor channels. But that's where I get lost.

I, as the service provider, would expect to open a channel to the hub with zero BTC. After all, I don't owe anyone anything. My goal is to *receive.* The hub presumably wouldn't be responsible for funding the channel either (would they?) since they have no part in the transaction. But an empty channel can't conduct business.

So how does this work? **It sounds almost like I'd have to front an amount of BTC equal to what I expect to receive from my customers over the long-term, fund the channel to the hub with it, keeping the BTC on the remote side of the channel which incurs counterparty risk, and then pay a fee to the hub/wallet 1% for the privilege**. I hope I'm missing something. Is this indeed the way things work? **If not, how should a vendor coordinate with his customers who want to pay via LN?** How should the channels be established and funded, preferably in a way that bypasses the high wallet fees mentioned above?

**Tags:** lightning-network


---

## 1 answers

### Answer by username_1 on 2021-12-08. Score: 1

> he opens a "channel" to me, funds it with 1 BTC, and executes the transaction. Opening that channel costs him an on-chain transaction fee so he hasn't really saved any money yet by using Lightning Network

Right, lightning channels are interesting in part because they allow users to send a huge number of payments over time, effectively amortizing the on-chain transaction fees over that huge number of payments. Opening a channel to make a single payment is wasteful.

> I can't use the 1 BTC received from my customer to contribute toward that purchase. That 1 BTC is all locked up. Unless I close that channel, the only thing I can do is send it back to my customer, or some other third party downstream from him, and only if the amount is less than 1 BTC, and only if every channel between the source and destination have 1 BTC of capacity. Is this correct?

Not quite correct, for example '[multi path payments](https://bitcoin.stackexchange.com/questions/tagged/atomic-multi-path-payments?tab=Votes)' allow a user to send a payment using the capacity in several different channels at once, atomically. So you could perhaps use some of that 1BTC channel to complete the payment, but of course you'll need other channels with capacity as well, and your node will need to find routes for each part of the payment.

> then it means to make LN viable, pretty much everyone needs to be connected to well-connected hubs, as opposed to just creating a bunch of highly specific customer-to-vendor channels

The lightning network is constantly evolving, so it is tough to give a definitive answer for what it might look like in the future, but there seems to be some consensus around the idea that it is a good idea to look for certain attributes in a channel partner. Good connectivity to the network graph, good liquidity, and good uptime are examples of attributes you may look for when selecting someone to open a channel with. You don't necessarily even need to open channels directly to your customer/vendor, though in some cases it certainly may make sense to.

> I, as the service provider, would expect to open a channel to the hub with zero BTC. After all, I don't owe anyone anything. My goal is to receive. The hub presumably wouldn't be responsible for funding the channel either (would they?) since they have no part in the transaction

There are several ideas already implemented to deal with this, for example check out [lightning pools](https://pool.lightning.engineering/overview), which is a market that allows you to rent incoming liquidity from other lightning users. There are also several service providers operating in the space that offer this inbound liquidity rental service as well.

> **Comments:**
> **username_0**: Looks like I'm neither allowed to upvote, nor mark as a correct answer (I create a new account for each StackExchange question; restriction has something to do with account age) but just want to thank you for the reply. This has pointed me in the right direction. Multipath payments sounds awesome and changes the whole ballgame. Love it. Looks like I've got some reading to do! Thanks again.  

---

