@ -793,42 +793,42 @@ In the current design of the Lightning Network, it is more typical for users to
They will do so by opening a channel with another node, and more often they'll be able to spend Bitcoin before they can receive it.
There are three typical ways of getting inbound liquidity:
* Open a channel with outbound liquidity (i.e. local balance), and then spend some of those funds. Now the balance is on the other end of the channel, which means it can be used to send payments to you.
* Open a channel with outbound liquidity and then spend some of those funds. Now the balance is on the other end of the channel, which means that you can receive payments.
* Ask someone to open a channel to your node. Offer to reciprocate, so that both of your nodes become better connected and balanced.
* Use a submarine swap (e.g. Loop-Out) to transfer funds back on-chain and get inbound liquidity (i.e. remote balance) to your node in return.
* Use a _submarine swap_ (e.g. +Loop-In+) to exchange on-chain BTC for an inbound channel to your node.
* Pay a third party service to open a channel with you. Several such services exist, some charging a fee to provide liquidity, some for free.
* Pay a third party service to open a channel with you. Several such services exist. Some charge a fee to provide liquidity, some are free.
Here's a list of currently available liquidity providers who (for a fee) will open a channel to your node:
Here is a list of currently available liquidity providers who will open a channel to your node for a fee:
* Bitrefill's Thor service at https://www.bitrefill.com/thor-lightning-network-channels/
* Bitrefill's _Thor_ service at https://www.bitrefill.com/thor-lightning-network-channels/
* Lightning To Me at https://lightningto.me/
* _Lightning To Me_ at https://lightningto.me/
* LNBig at https://lnbig.com/
* _LNBig_ at https://lnbig.com/
* Lightning Conductor at https://lightningconductor.net/channels
* _Lightning Conductor_ at https://lightningconductor.net/channels
Creating inbound liquidity is challenging from both a practical and user experience perspective. Inbound liquidity does not happen automatically, so you have to find ways to build it for your node. This asymmetry of payment channels is also not intuitive - after all in most payment systems you get paid first (inbound) before you pay others (outbound).
Creating inbound liquidity is challenging from both a practical and user experience perspective. Inbound liquidity does not happen automatically, so you have to find ways to build it for your node. This asymmetry of payment channels is also not intuitive. In most other payment systems you get paid first (inbound) before you pay others (outbound).
The challenge of creating inbound liquidity is most noticeable if you are a merchant or sell your services for Lightning payments. In that case, you need to be vigilant to ensure that you have enough inbound liquidity to be able to continue to receive payments. What if there is a surge of buyers on your store, but they can't actually pay you because there's no more inbound capacity?
The challenge of creating inbound liquidity is most noticeable if you are a merchant or sell your services for Lightning payments. In that case, you need to be vigilant to ensure that you have enough inbound liquidity to be able to continue to receive payments. What if there is a surge of buyers on your store, but they can't actually pay you because there is no more inbound capacity?
In the future these challenges can be partially mitigated by the implementation of dual-funded channels, which are funded from both sides and offer balanced inbound and outbound capacity. This could also be mitigated by more sophisticated autopilot software, which could request and pay for inbound capacity as needed.
In the future these challenges can be partially mitigated by the implementation of dual-funded channels, which are funded from both sides and offer balanced inbound and outbound capacity. The burden could also be mitigated by more sophisticated autopilot software, which could request and pay for inbound capacity as needed.
Ultimately, however, Lightning users need to be strategic about channel management to ensure that sufficient inbound capacity is available to meet their needs.
Ultimately, Lightning users need to be strategic and proactive about channel management to ensure that sufficient inbound capacity is available to meet their needs.
==== Closing channels
As discussed earlier in the book, Mutual Close is the preferred way of closing a channel, however there are instances where a Force Close is neccessary.
As discussed earlier in the book, a _Mutual Close_ is the preferred way of closing a channel. However, there are instances where a _Force Close_ is neccessary.
Some examples:
* Your channel partner is offline and cannot be contacted to initiate a mutual close
* Your channel partner is online, but is not responding to requests to initiate a mutual close
* Your channel partner is online, and your nodes are negotiating a mutual close, but they become stuck and cannot reach a resolution.
* Your channel partner is offline and cannot be contacted to initiate a mutual close.
* Your channel partner is online, but is not responding to requests to initiate a mutual close.
* Your channel partner is online and your nodes are negotiating a mutual close, but they become stuck and cannot reach a resolution.
Andreas M. Antonopoulos
4 years ago
committed by
GitHub