I’m feeling somewhat embarrassed…
Embarrassed… again. All feels very school boy error stuff on my part
Much thanks and will do
No worries. The UX for lightning still has a lot of room for improvement. It is a bit of a learning curve initially, but it will make more sense when you start using it more.
The next thing you should look into is the process for backing up your nodes in case something goes wrong with your server in the future. I don’t recall if you are using Start9, but if so then the general backup process for Start9 will include backups for your lightning nodes. Otherwise, look up the process for your OS that you are using.
Ta… all confirmed.
Should I mirror your Remote Fee Policy
Should I be able to send out of LND to create inbound
Do I play a part in creating liquidity on your channel
You shouldn’t need to do any additional configuration for now. Since I opened the channel, it is all outbound on my side, and inbound on your side. So you currently will not be able to send any sats. As you receive payouts from Ocean, then sats will move from my side of the channel to your side, and you’ll be able to send sats at that point.
1 Like
So… I jumped back in yesterday; created what I thought was a Bolt12 offer via CLN and signed via Sparrow. All appeared to be accepted Ocean end. However the following is showing on my CLN Lightning wallet:
Along with this on RTL there is no sat value and it’s formatted as Bolt11
This is accompanied by the following error message on Ocean:
I’m guessing I’ve created the wrong offer type?
I don’t have RTL connected to my CLN node (I use it to manage my LND node, and it can only be pointed to one or the other), so not famialiar with the interface you are showing there. In any case, I’m not aware of different types of offers (and the Core Lightning UI only creates one type anyway). Bolt12 referrs to the update that implemented Offers, and Bolt11 refers to the update that implemented Invoices, LNURLs, etc. I don’t know what the “Type” column is referring to in that RTL interface TBH.
In any case, the error message in Ocean is fairly clear – no route could be found without excessive cost. I don’t know what logic Ocean applies to define “excessive”, but if it is based on number of sats (rather than percentage of transaction amount), then then maybe the fee rate on my node (1%) would trip it for larger payout amounts. Hopefully others on the forum have run across that message and have some insights into how they fixed it. I recall someone seeing this same error in Ocean a while back, but don’t recall if a solution was posted.
Actually, I just realized that in CLN you can create a zero-amount invoice (which would be Bolt11) if you accidentlly forgot to click on the Offer radio button:
This used to not be possible, but I just tested, and it generates a valid invoice (albeit a pointless one since one cannot technically “pay” zero sats). Perhaps you signed a zero-amount invoice instead of a zero-amount offer? I haven’t tried that before, but maybe Ocean doesn’t have a check for that. It would explain the different “Type” (since Bolt11 is related to Invoices, and Bolt12 is related to Offers)
1 Like
Much thanks. Jumping in again. Hoping to swim cleanly to shore!
So… still no joy on my part.
Ocean messages
Got a number of active multi use offer pilling up on CLN
Along with numerous Bolt12 invoices mounting up on RTL. All appear to have the correct details but none are settled
What are the liquidity numbers on your channels currently?
Should be plenty of room to receive the ~50k sats. I do see my lightning payouts (mine are much smaller, ~5K) have been failing since 3/27. Sometimes restarting my server seems to resolve that. I’ll do that later when I have some time.
That’s what I thought. Will try restarting as well.
My server is restarted now. Will watch for the next Ocean payout to see if it is still blocked.
1 Like
After pointing a large amount of hash rate at my node with Braiins, I also now see the message “Failed: Could not find route without excessive cost”. My theory is that Ocean is using static fee thresholds rather than percentage thresholds. This would explain larger payouts failing the threshold, while lower payouts make it through.
To test this, I’ve temporarily lowered the fee rate on my node to see if the next payout goes through. If so, I may end up having to increase the minimum channel capacity on my node (since low minimum channel capacity coupled with low fee rate is too costly in base layer fees to manage)
2 Likes
Although I have had large payment issues in the paste that were resolved via OCEAN’s routing I got a new one today. This one has to do directly with my node. Payout currently sits at 186396 sats.
Failed: could not route or connect directly to (My node ID): {“code”:401,“message”:"All addresses failed: Error connecting to (my node URI).onion: Tor server reply: TTL expired. (my node URI).onion:9735: Connection establishment: Connection refused. "}, data=map`
Encountered at: 2026-04-12 03:37:41 UTC
To check- I can still move sats from Core to Alby (LND). Going to have to ponder this further…
EDIT: Attached
This might explain the error from OCEAN although I cant match timestamps from the error vs the log? Date is correct but timestamp different.
NOPE: This is a repeating issue…currently the log shows that error 3 times since I posted it here. This particular post is irrelevant to the large payouts from OCEAN. I apologize.
1 Like
Looking forward to your analysis.
EDIT:
Back when I first ask you about payouts exceeding my channels capacity you mentioned I could simply open another channel from LND to Core which I did. I have 3 channels totally 380,000 coming from LND. Cured the large payout issues. Could the fix be as simple as that other than fees? I’m sure I have the exact same setup as your channels as far as fees because I copied what you had suggested.
Watching this space Gents. Will hold off from any further attempts at payouts for the mo.