cyberdyne.sh node operator
Silen Zara @Silen Zara - 23d
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!
Silen Zara @Silen Zara - 1mo
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.
Silen Zara @Silen Zara - 2y
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.
