Ok… I’ve had a read up on Electrum and Sparrow. Both seem more aligned to where I want to go by way learning and establishing Lightning Channels, connecting to my Knots node, connecting to my CLN node, understanding Bitcoin technically and taking steps to using terminals.
Hi Paul- thanks so much for taking the time to record your tutorials and moderate this site. It’s very much appreciated!
I have a Start9 server, along with a Bitaxe, and was able to follow your tutorial for Knots and installing CLN. I moved 500,000 sats to CLN in the Bitcoin wallet, opened a channel to PaulsCode for 100,000 sats, which is now confirmed (it’s been over 24 hours now). Now i’m trying to get some inbound liquidity, but i cannot seem to send a payment out. I’m trying to send to my Strike lightning wallet, amounts of 5000 or 10,000 sats, but i get a “Sending Payment…” message with spinning arrow that never sends. Any ideas? Thanks in advance!
This is the most common complaint that I have gotten from folks using my node. There are two problems going on, but the main one is that the fee to send the transaction is higher than your max fee rate is set for CLN. I have the fee rate set unusually high on my node, and no doubt some custodial services also have additional fees they add on top. That means the total fess for the route are probably over what your node is configured to accept. Unfortunately the Core Lightning service on Start9 does not expose the config option in CLN to increase this, so if fees go past a certain amount, sends will consistently fail to find a suitable route. The other problem is with Core Lightning routing in general (discussed further here in this thread on the Start9 forum) The two problems compound each other, where you end up having to shut down your node, clear the gossip store, turn it back on, and wait several hours for it to re-populate. That doesn’t resolve the fee problem though.
The reason I have the fees set high, for anyone curious, is because of a problem that BTC Sessions ran into which cost him a lot of sats to recover from. He had the default fee rate on his node set to the default low settings, and he reduced his minimum channel size very low (like I did on mine) to encourage his viewers to start experimenting with lightning by connecting to his node. What ended up happening, though, is that scores of people opened small channels to his node (for mining), sent the sats to his side of the channel (like I showed in my video here) to create inbound liquidity to receive payouts. The net result of this was to sap all of BTC Session’s inbound liquidity from his main channels with the broader network, because all of the users were opening only one single channel, just to him, and sending the sats to his side. This meant that everybody routed all traffic through his main channels rather than participating themselves in the routing by having many other channels of their own. He could not re-balance either (since there were no routes through any of the small channels to circular re-balance) He ended up having to close all of the channels (which cost him more in base layer transaction fees then what he got from routing) and bump up his minimum channel capacity to prevent people from swarming his node again.
To avoid making the same mistake he did, I didn’t just set my minimum channel capacity very low (10K sats) but I also bumped up my routing fee to 1K stas per million (or 0.1%) with a minimum routing fee of 1 sat. This means if someone opens a 10K sat channel and sends all of the liquidity to my side, the fees I collect are 11 sats. If 100 people swarm my node, and each send out 10K sats, They will consume 1M sats of my inbound liquidity, but I will have collected 1.1K sats in fees (which is enough to do a base layer transaction to add more liquidity to my node). That way I don’t have to close anybody’s channels, and I can continue to collect transaction fees from them as they receive their mining payouts until they are ready to close their channels themselves.
But, unfortunately that led to the problem that you are now encountering. The issue doesn’t affect LND (since you can easily increase your acceptable fees), but Core Lighting is required for Ocean mining, since LND doesn’t yet support Lightning Offers. One way you can get around the problem (though it is a bit technical, unfortunately) is you can open both a Core Lightning node and a LND node on your server. From the LND node, open a channel with a good well-connected node (you can start with mine if you want to begin with a small channel – I recommend using my “PaulsCode LND” node, though, which is easier for me to re-balance, but you can use either). You’ll be able to send from it no problem (using Ride the Lighting, you can specify your max fee rate) to create inbound liquidity. Then open a channel from your LND node back to your Core Lightning node. That channel will be inbound liquidity on the Core Lightning side, so you will be able to start receiving payouts right away. When it eventually fills up on the Core Lightning side, you can just create an invoice from your LND node, and pay it from your Core Lightning node (for zero fees, since it is a direct connection), freeing your inbound liquidity back up.
1 Like
Thank you for that explanation. It makes much more sense to me now. I had also watched BTC Sessions tutorial, and understand now why there’s an issue here. I also saw your Boltz Exchange action- would that help in this case? Or could I put more BTC into my CLN and open a larger channel to a larger partner?
Yes, that is another option if you have the sats to spend. A good node to connect with is ACINQ, which last I checked has a minimum channel capacity of 1 million sats. If you open a channel with them, you would then send most of the 1M sats (minus the minimum balance) back to cold storage via Boltz. Depending on ACINQ’s liquidity, you might have to break it into multiple pieces (such as two 500K chunks or four 250K chunks) if they aren’t able to route the full 1 million in a single bite.
If a million is a bit high for you to put into lightning now, I can also set up a virtual meeting to walk you through setting up a Core Lightning to LND link if you’d rather go that route. It would probably be easier than reading my wall of text above, haha.
1 Like
One other thought- could i send/gift you, for example, 10,000 sats directly? Would that avoid routing fee issue and give me some inbound liquidity? If not, I’m not opposed to the 1M sat option you mentioned above, and yes, I realize i’m going through a lot to just mine a few sats on a Bitaxe with Ocean. But the lightning fees and gifted sats are a small price to pay to learn and teach my kids about the future of money.
1 Like
I can open a channel with you (which will show up as 100% inbound liquidity on your side). No need for the 10K sat payment (I’ll collect routing fees over time if it works). What is the name of your node?
My Node ID is 03e7d6e4507881cb416194cb0cf76b9bebbea52f5083af1e44c998a33cdb8a2146@5e56sfil45v3wyvtnbwgtsygnra3djp2qrgcwmroa5auybs3pbt7h6id.onion:9735
Is that what you need?
1 Like
Channel should be active.
Excellent- I do see it in my CLN connections now. Thank you!
I’m guessing it will also benefit you and us if we open a number of public channels between us thus generally contributing to Lightning payments routing and specifically earning fees alongside Ocean hashing payouts
Yes, in general, the more channels there are on Lightning, the stronger and more reliable and decentralized the network becomes. You do have to weigh that with the fact that a Lightning node is essentially a hot wallet. Being on a dedicated server with a niche OS like Start9 helps of course, but you should always approach it from the perspective that you do not want to have more sats tied up in Lightning than you are able to lose in the worst case scenario of your keys being hacked.
Since Core Lightning has routing issues in general, though, I would recommend actually not putting too much effort into building out your Core Lightning channels (at least for now, until they improve their software). LND is way more reliable, and is where I would recommend focusing as you start to build your expertise in Lightning, presence on the network, and using Bitcoin as a medium of exchange. One way you could have the best of both worlds, though, would be once you have your LND node up and well connected, set up a channel from it back to your Core Lightning node. The more folks who are able to eventually reach that level, the less pressure there will be on my main channels. Like I mentioned, though, I’ve got the fee rate high enough for it to be manageable, so this is certainly not any sort of imperative.
1 Like
Ok. As mentioned I’m running the Umbrel Home off the shelf server so can load LND from their App Store. Just checked to confirm it can run on Knots. I’ll aim to set up 3 x 25,000 sat channel. Also I’ve got a 200k ‘private’ channel open with ACINQ on CLN. Seems like a waste of a route sitting there for use with Ocean Bolt 12 payouts for Bitaxe hash which won’t touch the sides of it. Can’t see how to make the channel public. I’m guessing it will be a case of closing it as and when I’m confident with LND?
Yes, that is what I would do. Get things going well with LND, then close the channel. Once the closure finalizes after a number of confirmations, you’ll be able to move the funds from that channel out of the base layer wallet for other purposes.
Ok. Also I had a look at Electrum and Sparrow. I’ve loaded Sparrow but not set it up as yet. If I’m going with LND, should I just focus on their Lightning wallet?
Hi Paul- I’m looking in CLN, and I see that on May 29, I had a withdrawl from my Bitcoin wallet of 100,369 sats, and on June 13th, a deposit of 99,849 sats, and now the channel with PaulsCode is not there (which I had established with 100,000 sats). Did you close it, or did something on my end cause it to close? No worries if you needed to close it- just trying to understand the mechanics of all this. I still see my connection to PaulsCode LND, and i’m still able to receive the Ocean payouts.
Yes, I am in the process of migrating over to use my LND node only (it is more stable and easier to manage). I posted another thread about it here, for more information: Decommissioning Lightning node PaulsCode [migrating to LND]
Excuse my ignorance. In the client list of the Datum gateway there is a column called RemHost. My brain says Remote Host but not sure. I see other examples from screen/video that the filed is an external IP outside local network. My gateways has these characters in front of the IP:… ::ffff: while others don’t.
The gateway works as expected but what are those characters?
You are correct, RemHost = “Remote Host”
That column is simply showing you the IP (or hostname) of the client that’s connected.
The ::ffff: prefix is the IPv6 “IPv4-mapped” notation. Modern TCP/IP stacks often speak IPv6 internally, even when clients connect over IPv4. To represent an IPv4 address in an IPv6-only API, they put the IPv4 bits in the low 32 bits of an IPv6 address, with the high 96 bits all zero except for a 0:0:0:0:0:ffff marker.
So if you see something like:
::ffff:203.0.113.47
that’s really just the IPv4 address 203.0.113.47 “wrapped” in IPv6.
:: is shorthand for “lots of zeros” in an IPv6 address
ffff: flags that the next 32 bits are actually an embedded IPv4 address
the dotted-quad that follows is the original IPv4
No need to worry - your gateway is still talking IPv4, it’s just reporting it via the IPv6 API. Technically, there is probably a way to force the daemon to listen only on an IPv4 socket, but functionally there’s no difference here.
1 Like
Thank you very much Paul. 