@Silen Zara
cyberdyne.sh node operator
Relays (4)
- wss://filter.nostr.wine/ – read & write
- wss://inbox.nostr.wine/ – read
- wss://nostr.land/ – read & write
- wss://nostr.wine/ – read & write
Recent Notes
I have contacted nostr:nprofile1qqsvn0dkjt80raqrxd470c98n7zrdehmcvj6p5hgw3kyku6zyd8z0fqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3qamnwvaz7tmwdaehgu3wwa5kuegufe9k5 customer support about this same issue a n...
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.
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.
1❤️1
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.
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.
All our channels and feerates are public, anyone can see where we allocate liquidity and how much we charge for routing. This alone is extreme transparency. Unfortunately I'm not sure what else I can ...
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.
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.
1
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.
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.
2/1/2024 ANNOUNCEMENT: I’ve made the difficult decision to close down the node. Sometimes flowing with life’s changes means accepting that everything must eventually come to an end.
To my chann...
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.
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.
11❤️6🤙2♥️1🚀1
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...
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".
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".
1
Anyone try out the bimodal estimator yet?
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.
Haven't tweaked it's parameters yet but will try it soon.