They are actually perfectly reachable at rates that are even lower than what they have been for the past few weeks. It's just that you can't reach them via the Strike node that indeed seems to suffer from outbound liquidity issues.
Strike (through the Zap nodes) are actually one of the few places that is still holding up during all the activity that has been going on for a while now.
It sucks what happened to your node but it's good to see you take it as an opportunity to start something new.
Good luck with the new node!
The only mechanism to earn on LN is from routing fees, so yes, you are technically correct. All earnings from LN fall under that umbrella.
What I'm talking about is what the driving force is behind your capacity to route. And that is very obviously the countless CashApp channels c= receives every day, which causes the inbound to be increased and then used as a pressure mechanism to enable the routing. The APR might not come directly from Block, but the liquidity to make it all work is.
It's the same as me setting up a separate node that I constantly feed with liquidity and then say I made a huge APR on that node because it routed a bunch.
But you may choose to call it APR from routing, and that's fine. I personally think c= categorically works in such a different way compared to any other node that something like APR does not really have meaning anymore and it becomes inappropriate.
It's pretty obvious what is driving the success of the c= node just by looking at the channel open/close history. Without the CashApp nodes feeding c= there is unlikely to be any routing at all since the fee structure does not support it at all. Only by carefully selecting peers to open channel to with the CashApp funds you are able to create a very well run "routing" machine.
You guys are obviously doing this very well but again, it's not possible without the unique position you are in with the CashApp nodes backing it up.
I also kinda agree therefor that it's a bit misleading to say the 10% APR is earned from routing while it's just clearly not. Pure routing is something very different than what your are doing. What you are doing is what I would personally call LN liquidity trading.
Liquidity trading is what many nodes do but for the rest of us the economics are very different because we actually have to pay to get the liquidity to where we need it.
I simplified my channel acceptance criteria a lot and updated my site with the new policies: https://cyberdyne.sh/
From now on, for all nodes:
- Minimum size: 10M sats
- Maximum size: 30M sats, but it scales up to 500M sats if the opening node has a lot of capacity. The actual max is about 10% of the requesting node's total public capacity.
The reject message is now much clearer about the problem and shows exactly the range of channel sizes you are allowed to open (if the requested size is out of that range).
I used to check for many things (available sockets, number of channels, terminal score, and latency) and even had a higher minimum size for large nodes, but all of that made things too complex and hard to explain.
From now on, just a simple channel size range and that's it.
My c= channel is routing fine, I do notice however that the node is often very slow to respond. I keep latency metrics and the 30d average is over 7000ms.
Thank you for always being a good peer to me. Lots of sats went through our channels. Good luck!
I often see my peers increasing their fee to me by a very small amount (5 ppm or less). To me this makes very little sense because you risk losing traffic due to FEE_INSUFFICIENT errors (until the update is propagated through the network) for only a very small gain in profit.
That's why I use a lower limit on my fee increases. A reasonable amount I personally use is to take the square root of the current fee and use that as a minimum. For (very) low fee rate channels you can override this minimum to something like 10 and for higher fee rate channels maybe something round 25.
It becomes even more important if you want to serve transaction from lightning users who are not online all the time and can have a very outdated view of the network.
So if you want to maximize your chances of getting routes through your node (which you should) then you've got to be considerate about how you do fee updates.
A solution for this "bloated" node problem is pairwise fees.
Graph centrality is an overrated metric for pure routing nodes if they want to optimize their capital efficiency.
With more peers it becomes increasingly difficult to make them all flow. If you want to optimize APY then it's often better to have smaller, more specialized nodes that have all channels working together "in the same flow".
I've used it for a few weeks now since the early rc's. I have a good experience with it so far, getting succes with some really long routes when rebalancing.
Haven't tweaked it's parameters yet but will try it soon.
There's a lot of information to be learned by observing the payments flowing through a routing node. By having eyes on every payment, over time you will build up intuition about which routes are important to your node.
Eventually you will spot patterns and then the fun starts in figuring out how to increase (or decrease!) the probability of those patterns occuring. It can be tricky to spot those patterns because cause and effect are not obvious and seem decoupled without the right intuitions.
This is the core concept of running a successful routing node.