I am working on an ecommerce site that accepts lightning payments and was curious about how to "cash out" to pay vendors without closing channels to customers. I was planning to run two LN LND nodes and have two channels between them. One node for personal use highly connected and one running on BTCPay Server. Since not all my vendors accept bitcoin, I was working through the best way to be able to "cash out" my bitcoin to fiat (by closing one of my channels between my personal node and my BTCPay Server business node) to pay my vendors while still having an open channel to the world through which individuals who did not have an open channel with me could route payment. Rather than having my store (BTCPay Server business node) close channels to customers to "cash out" to pay vendors, I thought I would send LN payments from my store node to my personal node and close one of the two channels between my store node and my personal node. My thoughts may be convoluted and unnecessary and I would welcome any suggestions.
4 Answers
This will get easier in the future as exchanges will be implementing deposits and withdrawals via LN.
At this time, if you need to deposit BTC and the exchange does not support LN deposits, I'm afraid you are stuck with closing channels for now.
Perhaps there will be a way soon to rebalance the channels to minimize the number of closures required. Basically, push back funds on channels from customers 1-4, to pull the funds onto the customer 5 channel, and close only the one customer 5 channel.
You can "loop out" using loop by lightning labs. It allows you to convert offchain funds into onchain funds by doing a reverse submarine swap. You can check the fees beforehand and specify which channel you want to drain.
Closing channels alone is not an adequate solution to rebalancing because all it does is shift the problem around.
Consider the following scenario: You have a node A, which is a store-front, and a personal node B, which is private. You have private channels i and j between the two nodes. There are some channels you have open on your store front, 1, 2, and 3, each of which has channels open with x, y, z respectively. Also, your personal node has channels open with w and v.
I'll use = to indicate the outbound capacity your merchant node has, and - to indicate the inbound capacity.
(x)----|====(1)----|==== ====|---- ====|----(w)
\ / i \ /
(y)----|====(2)----|==== (A) (B) ====|----(v)
/ \ j /
(z)----|====(3)----|==== ====|----
Assuming all channels have a capacity of 8ksat above, and are all evenly balanced, lets see what happens if z makes a payment of 4ksat.
(x)----|====(1)----|==== ====|---- ====|----(w)
\ / i \ /
(y)----|====(2)----|==== (A) (B) ====|----(v)
/ \ j /
(z)|========(3)|======== ====|----
The inbound capacities of the channels between z, 3 and your merchant node A are now exhausted and you will not be able to receive payments through it. To rebalance this, you need to make a payment through 3 and z, to be received via w or v. Lets say we split this into two payments via both w and v.
2ksat: A -> 3 -> z -> ... -> w -> B(i)-> A
2ksat: A -> 3 -> z -> ... -> v -> B(i)-> A
(x)----|====(1)----|==== ========| ======|--(w)
\ / i \ /
(y)----|====(2)----|==== (A) (B) ======|--(v)
/ \ j /
(z)----|====(3)----|==== ====|----
Channel i is now exhausted, so we can close it to cash out on chain. However, we need something to replace it. We need a new channel k, with the same capacity of 8ksat.
(x)----|====(1)----|==== |-------- ======|--(w)
\ / k \ /
(y)----|====(2)----|==== (A) (B) ======|--(v)
/ \ j /
(z)----|====(3)----|==== ====|----
Notice that We've not actually gained anything "on-chain", because we've had to reuse those funds to establish the replacement channel, although we still own the money, it is tied up in the channel.
Assume that now x makes a payment of 4ksat, and we repeat the process above, but using j instead of i as the channel we're going to cash out with.
(x)|========(1)|======== |-------- ======|--(w)
\ / k \ /
(y)----|====(2)----|==== (A) (B) ======|--(v)
/ \ j /
(z)----|====(3)----|==== ====|----
2ksat: A -> 1 -> x -> ... -> w -> B(j)-> A
2ksat: A -> 1 -> x -> ... -> v -> B(j)-> A
(x)----|====(1)----|==== |-------- ========|(w)
\ / k \ /
(y)----|====(2)----|==== (A) (B) ========|(v)
/ \ j /
(z)----|====(3)----|==== ========|
We can cash out j and create l in its place, but we have the issue that the channels B had with w and v are now completely exhausted of incoming capacity. We won't be able to rebalance anything else if y makes the same payment.
(x)----|====(1)----|==== |-------- ========|(w)
\ / k \ /
(y)|========(2)|======== (A) (B) ========|(v)
/ \ l /
(z)----|====(3)----|==== |--------
So unless B is actively spending on the lightning network, through w and v, those channels are not going to be reusable for rebalancing. It isn't possible to spend from B back to A via these channels, as that would exhaust the inbound capacities of its other channels it has open to customers.
In practice, you will probably have more channels open, and each node will be routing payments for other people, so you may have some other rebalancing going on. You might discover that certain paths are used more frequently one direction than another, which would make it ideal for use as a rebalancing path.
However, the end goal is eventually to not need to cash out - but to make your purchases directly on the network. Likewise, you should be able to get paid over the network, and rebalancing will become less of an issue as the number of channels increases, and liquidity increases.
There are a number of services which can be used to "refill" channels, in return for direct on-chain payments. I guess there is a market for the opposite of such service too - to offload payment channels in return for the on-chain payment. There have been some proposals for liquidity markets to be developed directly on the Lightning Network layer so that some of this can be automated in future.
Perhaps the correct thing to do, is not to attempt to rebalance unless absolutely necessary for yourself though. In the above scenario, when z first paid, instead of trying to rebalance the channel A has open with 3, you could just close this channel and cash out. If z wants to make another payment to you, they must either do it through 1 or 2, or some other channel which might be created with incoming capacity in your direction. The problem then is not your's, but z's. If you are a useful routing node, then people will probably want to open more channels with you with inbound capacity to you also.
1, 2, and 3 are not necessarily your customers. Your customers are x, y and z, and the direct channels you have open just facilitate those payments.
You can use a lightning-enabled exchange to "exchange" your BTC locked in lightning channels to on-chain BTC. Afterwards you can use any usual exchange to sell your on-chain BTC for a preferred fiat currency.
A couple of lightning-enabled exchanges from this post are zigzag.io, sideshift.ai, southxchange.com, btcduke.com and coinplaza.it.
However please do your own research before using these: the services are all new and require your trust for the time they hold your funds. Also beware that the fees can be relatively high.
