Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Routing efficiency column #69

Open
rkfg opened this issue Jun 20, 2022 · 0 comments
Open

Routing efficiency column #69

rkfg opened this issue Jun 20, 2022 · 0 comments

Comments

@rkfg
Copy link
Contributor

rkfg commented Jun 20, 2022

After adding the NUPD column I often think about using it to rank the channels in order of their actual usefulness. NUPD represents the amount of attempts, not just successful forwards and it actually consumes disk space every time it increments. Though it's less of an issue in 0.15.0 after some great optimizations.

The main issue here is all the rebalancing or probing attempts, you can easily see them in the log as the amounts are very round (50/100/400k etc.) and 99.999% (use any amount of 9s lol) of them fail. So all they do is wasting your disk space. I don't think one should raise fees to prevent these from even going through the node, after all some of them succeed and earn you fees and you can't know beforehand which those are. But it's an interesting metric nevertheless as it represents how busy that particular channel is.

So I'm thinking about a formula that can represent the useful traffic share from the forwarded amounts and update count. The simplest would be (sent+received)/nupd in sats/update but it could be misleading compared to busier channels if nupd is low. The idea is to quickly locate inefficient channels that should be closed. If you only have a few dozens of channels it can be done manually just by sorting by NUPD and looking at the bottom but if there are many channels it becomes complicated. There are other tools like faraday (by Lightning Labs) but they don't have an UI and just spew a big JSON.

Another metric to consider might be the channel lifetime in blocks. So the result could be measured in sats/update/block or something like that. Maybe make two metrics, sats/block and sats/update. Some channels might have a lot of updates but only because they were opened long ago.

Ideas are welcome!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant