Hey Paul
Now that the mess I caused on my LND node by setting things I misunderstood is fixed. Could you show how to set them so in the future we my not run into a rebalancing problem because of channel size and fee settings. I would like to set both CL and LND nodes so I don’t get a problem in the future by having them.
Thanks
Ok, sure. I will admit that I am new to Lightning myself, so I think the way to do this will be to record a series of videos on Lightning, which will give me a chance to improve my own knowledge along the way as I am preparing to record them. This is something I have been planning to do anyway.
I would just say that the thing I have learned in my own experience, is that the minimum channel capacity and the fee rate are important to consider when you are ready to expand beyond just the basic two-node, two-channel setup that I described on the other tread recently. It depends on how you want to use your node.
In my case, I wanted my node to have a reliable, liquid connection to the Lightning network, with a low minimum channel capacity so that beginners who are getting their toes wet with Lightning (or just wanting to start mining for Ocean) can get started without breaking the bank. What this means in practice is that I was opening myself up to dozens of people opening channels to my node, where that was (at least for some time) going to be their only channel, and where they would push most of the sats to my side in order to open inbound liquidity for mining payouts.
The reality of that setup is that a lot of sats get locked up in many small channels on my side, which cannot be rebalanced because those users do not have any other channels with the larger Lightning network. As a result, each new user from my node’s perspective would borrow outbound liquidity from my big, liquid channels with the Lightning network (ACINQ, Voltage, Wallet of Satoshi, etc). That outbound liquidty, having moved into many small channels, would be locked there and illiquid. This meant that, over time, my main channels would need to have more BTC swapped in, and more and more BTC would be inaccessible for me to use as it became locked up in the new users’ channels.
On top of that, many new users, after experimenting for a while, simply drop off the network and never return, leaving the sats they locked up on their channel stranded. Over time, this means more and more sats get locked up in my node and unable to be moved by me on the Lightning network. The result? I need to make a lot more base-layer transactions to maintain my node for the purpose that I want to use it (supporting new Lightning users). This includes swapping in liquidity to my main channels and force-closing channels that have been abandoned.
The base-layer transaction fees for this extra maintanance can get expensive, and so to counter that, I set my fee-rate high. Which then created a problem for Core Lightning users (which are most of them, since the majority of them are getting into Lightning for Ocean mining payouts). So, yeh, this is something that I am still figuring out myself…
Im kinda understanding. So you need to increase fee rate to like 150000 or higher?
On my node, I set my routing fee rate at 1% (which in LND, that is confutred in sats per million, so 10000) so that I collect enough in fees to pay for the more frequent base-layer transactions that I have to do to maintian my node (for the above-mentioned reasons).
The problem this causes for users is that 1% fee rate is larger than the default max fee rate for Core Lightning (which is needed for mining payouts from Ocean), so when they open a channel with my node from Core Lightntning then try to send most of the sats out to open up inbound liquiidity for Ocean payouts to come in over, they are faced with a message about unable to find a route.
Sadly, there is no interface in Core Lightning to increase the max fee rate. The only workaround that I have found is for the user to create two nodes. On Start9, that means installing Core Lightning, LND, and Ride The Lightning (which is an interface for LND). Then from LND, open a small channel (around 60,000 sats) from the LND node to the Core Lightning node. This is where the Ocean mining payouts will come in over. From LND, open a larger channel to the broader Lightning network (you can use my node for this if you want to start small and don’t mind the 1% routing fee). And finally, send sats to another wallet (or back to cold storage via boltz.exchange) from LND, increasing the max fee rate so that a route can be found.
With this setup, Ocean payouts will come in over your LND node, and from there will route into your Core Lightning node via the small channel. In the future, once the Core Lightning side of the channel starts to fill up with mining payouts, you can move them over to your LND node by creating an invoice from LND and paying it to yourself from you Core Lightning node. Rinse and repeat.
I’m almost blind yet to how this is all working but I can see the my counter part has to re-balance more often since my payouts from OCEAN are larger. Sounds like I might need to open up a larger channel between LND and Core so he doesn’t have to re-balance as often.
I still have your PaulsCode LND over on Core which helps keep my inbound around 28k. That is the reason I haven’t closed the channel. I gotta really get my head wrapped around this more. @Fletcher has a better handle on this than I do I think so I’m going to pick his brain more and see what his thoughts are on the matter.
Thanks
Um…I dunno but maybe using RTL with LND and ThunderHub with Core might be a solution to Core’s pitfalls and circular re-balancing. Just stabbing in the dark here. What you think Paul?
Increasing your channel between your LND node and your Core Lightning node (assuming there are not other channels out from your Core Lightning node that would come into play here) would not do anything for your channel with Fletcher’s node.
I wish there was a good way to visualize this thing (generative AI wasn’t helpful). The closest thing I’ve come up with for visualizing it is to use an abicus, but those tend to have parallel lines. They at least capture the idea of a channel (rod) where the sats (beads) can move from one end to the other. A better visualization would be multiple hubs (nodes) that have the rods comeing out like spokes, connecting to other hubs (nodes). The spokes would still be like the rods on the abicus with beads that can move to one end or the other.
When you say open a small channel from LND what do you mean? And to the CL, are are talking about is this my current active node?
Yes. So you have your CLN node. Leave it as is.
Next, create an LND node (install LND and Ride the Lightning)
Then from RTL, create an address and send bitcoin to it.
Once the Bitcoin is there, use (for example) 60,000 sats to open one channel to your CLN node.
From RTL open a second channel to a well-connected node.
Once the two channels are activated, you can close the old channel you created from your CLN node to my node (you won’t be using it anymore).
Last step, from RTL, move sats to somewhere else (another wallet, cold storage, etc) to open up inbound liquidity with the larger Lightning network.
Once everything finalizes, you should now have just two active channels: one between CLN and LND (with the liquidity mostly on the LND side) and one from LND to another node (mine for example) with inbound liquidity for mining payouts to come in over.
This is the simplest setup for mining if you are connecting to a node with higher fee rates like mine. The way I showed in the video only works if you can connect to a node with a low fee rate and you are not using something that adds additional high fees at some step such as Aqua wallet.
1 Like
Paul knows what he’s talking about, he has guided a number of us through CLN/LND and Lightning 
You might want to consider opening a channel to megalith.me (small channels) for your well-connected node. You can open a 150k sat channel and it’s linked directly to the bigger megalith node so routing is quick and reliable. You do have to sort out the rebalancing yourself, though, but start with a large local to remote ratio which will enable you to send and receive payments (e.g. do not make the balance 50:50 in the beginning).
1 Like
Does having a private channel and not a public as only one matter going back to the CL from ur LND?
The channel between CLN and LND should be a public channel, not a private one. Otherwise, I do not believe a third party on the Lightning network (such as Ocean) will be able to send payments to the CLN node, since the only channel that such payments could be routed over is private (and thus unknown by the third party).
That said, there is a config parameter in CLN “exposeprivatechannels” which, if set to True, will add “hints” for its private channels to its invoices (maybe also applies to offers, not sure). This parameter is not exposed in StartOS though, so I don’t know if it is True or False behind the scenes.
Has anyone on here successfully received a payout from Ocean that they can confirm came in over a private channel (and not a public one)?
I don’t think so. My first channel of Core was private but I think the payment route was thru your PaulsCode CL channel.