<p>I would approach this problem a little bit differently as counting in general is pretty difficult and the assumption of being an average node is pretty strong (not to say as I lay down below probably wrong) My approach however uses also a strong (and also probably wrong) assumption though I think it is not as strong / wrong as yours. </p>

<p>In my video in which I lay out the <a href="https://youtu.be/L39IvFqTZk8" rel="nofollow noreferrer">math for optimizing routing fees / earnings on the lightning network</a> I start with a probability distribution to derive an expectation value for my routing fees that I want to optimize to gain maximum routing fees. </p>

<p>Instead of assuming your node is average I would ask about the likelihood of being on a path of a transaction between <em>two arbitrary</em> nodes? As I lay down in the video this boils down to the <a href="https://en.wikipedia.org/wiki/Betweenness_centrality" rel="nofollow noreferrer">betweeness centrality</a> of your node on the fee graph of the lightning network. The fee graph is the network you get when adding the routing fees as edgeweights (it is a little tricky as they dynamically depend on the payment amoun. You could start with just using the basefee). Generally your centrality raises with you lowering  your fees and maintaining more channels. In your case after computing your centrality you would divide the number of settled routing attempts by the centrality of your node to get an estimate of the overall payments made by the network. </p>

<p>As a datascientist I would say that even your data points (n=13 settled routing attempts) are statistically probably not sufficient. However larger nodes could probably use their data to make a pretty good guess. </p>

<p>Also as a disclaimer I should say that my result with the betweeness centrality depends on the relativly strong assumptions that the distribution of who pays whom is uniform so it would be equally likely that you pay any other node. This seems to be another very strong assumption but it is extremely hard to get a better a priori distribution for it. If it was available it could easily be weighted into the formula of the betweeness centrality. Also I assumed that payments all have the same amount to compute the betweeness centrality. This is also wrong but could also be modelled to the centrality measure if the amount distribution was known. </p>

CC BY-SA 4.0
2019-05-14T09:56:19.687Z
can't say i am satisfied with answer, but it seems correct..
baysx
CC BY-SA 4.0
2019-05-14T10:46:30.077Z
Why not satisfied? The fact that it can only be estimated and a lot of assumptions have to be put in? Or more my way of presenting it (with which I also was not too happy - but I thought I was overcritical)
Rene Pickhardt
CC BY-SA 4.0
2019-05-14T12:37:14.603Z
rather because  a lot of assumptions have to be put in.. i thought there is a way to get more accurate data with less effort. At some point that is good for privacy as it happens now, but makes hard to analyse network for random person.
baysx
CC BY-SA 4.0
2019-05-14T09:51:40.510Z
2019-05-14T10:51:47.950Z
2019-05-14T10:51:47.950Z
Rene Pickhardt
<p>I am running a LN node. Set up monitoring to collect stats. Now i am wondering, how can i get correct conclusions about what collected information actually is.</p>

<p><a href="https://i.sstatic.net/VZ5ky.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/VZ5ky.png" alt="Stats which i am collecting (last 24 hours)"></a>
My question is about forward (transaction?) count. According to my stats i had 14 settled forwards.</p>

<p>There are ~8350 nodes over there, my node according to 1ml.com is ~#450 in channel/capacity rank. so we can assume that i am average <strong><em>active</em></strong> node i think. so then 8350*14=116900 settled forwards over network?. i am not sure what this number mean and can we compare this to 409570 on-chain transactions for last 24 hours.</p>

<p>I had also some 2-3 offchain pay and 1 paid invoice which was my own node made, do i need to add the to calculation above or not?</p>

<p>If this completely incorrect way to count and compare transactions, please describe a correct one.</p>

CC BY-SA 4.0
2019-05-14T09:03:54.513Z
if someone interested in a monitoring solution i've used: https://github.com/reablaz/zabbix-clightning
baysx
CC BY-SA 4.0
2019-05-14T09:05:00.627Z
Tip: Stats are for last 24 hours
baysx
<transactions><lightning-network><lightning-routing><accounting>
What is correct way to count LN node stats
baysx
# What is correct way to count LN node stats

(Asked by: username_0 on 2019-05-14)

I am running a LN node. Set up monitoring to collect stats. Now i am wondering, how can i get correct conclusions about what collected information actually is.

[![Stats which i am collecting (last 24 hours)](https://i.sstatic.net/VZ5ky.png)](https://i.sstatic.net/VZ5ky.png)
My question is about forward (transaction?) count. According to my stats i had 14 settled forwards.

There are ~8350 nodes over there, my node according to 1ml.com is ~#450 in channel/capacity rank. so we can assume that i am average ***active*** node i think. so then 8350\*14=116900 settled forwards over network?. i am not sure what this number mean and can we compare this to 409570 on-chain transactions for last 24 hours.

I had also some 2-3 offchain pay and 1 paid invoice which was my own node made, do i need to add the to calculation above or not?

If this completely incorrect way to count and compare transactions, please describe a correct one.

**Tags:** transactions, lightning-network, lightning-routing, accounting

> **Comments:**
> **username_0**: if someone interested in a monitoring solution i've used: https://github.com/reablaz/zabbix-clightning  
> **username_0**: Tip: Stats are for last 24 hours  

---

## 1 answers

### Answer by username_1 on 2019-05-14. Score: 0 | Accepted answer

I would approach this problem a little bit differently as counting in general is pretty difficult and the assumption of being an average node is pretty strong (not to say as I lay down below probably wrong) My approach however uses also a strong (and also probably wrong) assumption though I think it is not as strong / wrong as yours.

In my video in which I lay out the [math for optimizing routing fees / earnings on the lightning network](https://youtu.be/L39IvFqTZk8) I start with a probability distribution to derive an expectation value for my routing fees that I want to optimize to gain maximum routing fees.

Instead of assuming your node is average I would ask about the likelihood of being on a path of a transaction between *two arbitrary* nodes? As I lay down in the video this boils down to the [betweeness centrality](https://en.wikipedia.org/wiki/Betweenness_centrality) of your node on the fee graph of the lightning network. The fee graph is the network you get when adding the routing fees as edgeweights (it is a little tricky as they dynamically depend on the payment amoun. You could start with just using the basefee). Generally your centrality raises with you lowering your fees and maintaining more channels. In your case after computing your centrality you would divide the number of settled routing attempts by the centrality of your node to get an estimate of the overall payments made by the network.

As a datascientist I would say that even your data points (n=13 settled routing attempts) are statistically probably not sufficient. However larger nodes could probably use their data to make a pretty good guess.

Also as a disclaimer I should say that my result with the betweeness centrality depends on the relativly strong assumptions that the distribution of who pays whom is uniform so it would be equally likely that you pay any other node. This seems to be another very strong assumption but it is extremely hard to get a better a priori distribution for it. If it was available it could easily be weighted into the formula of the betweeness centrality. Also I assumed that payments all have the same amount to compute the betweeness centrality. This is also wrong but could also be modelled to the centrality measure if the amount distribution was known.

> **Comments:**
> **username_0**: can't say i am satisfied with answer, but it seems correct..  
> **username_1**: Why not satisfied? The fact that it can only be estimated and a lot of assumptions have to be put in? Or more my way of presenting it (with which I also was not too happy - but I thought I was overcritical)  
> **username_0**: rather because  a lot of assumptions have to be put in.. i thought there is a way to get more accurate data with less effort. At some point that is good for privacy as it happens now, but makes hard to analyse network for random person.  

---

