I’m very good for testing. I’m causing a little disaster
In this CSV you can see many forks caused by me. I think the problem is my very bad (but very cheap) Internet Service Provider. I can’t have incoming connections. This is my connection scheme:
185.39.43.132 (Public IP) -> 10.242.22.14 (Router WAN IP, it’s a private IP!) -> 192.168.1.x (LAN IP)
I have double NAT, my service provider have a private LAN and there is my LAN too, so I can’t open ports.
Is there any solution to that or is it better I don’t compute blocks?
I remember the classical « LowID » in eMule: permanent TCP connections to the server and other clients connect to me through the server. Can be implemented in this software a similar solution, some peers aiding others can’t have incoming connections?
How did you manage to see the forks? Also, what do you call a fork?
I mean: if you fork lonely, that’s not a big deal. I think you speak about that case.
With duniter 0.81.0 your computer regularly pulls the network for new blocks, to make your node aware of new blocks and compute a valid next block. But the longer your node is UP, the longer becomes the interval between 2 pulls.
So a possible solution right now for your would be to stop & restart your node every day. A more long term solution would be that we add an option “keep short pulling intervals”.
Anyway, looking at Remuniter I can see that you still compute blocks, so yes, that’s better you continue computing blocks. This introduces hardness for other members computation, and secure the whole currency.
I’ve obtained this info from the local database in the Odroid (ARM) device: $HOME/.config/duniter/duniter_default/duniter.db using this SQL query:
Select fork, number, issuer From block Where fork=1
But now, I’m looking at the PC and there aren’t forks, so it seems I’m forking lonely. Ohh, that’s not a big deal, I thought it was more serious.
There’s another problem, with my ISP I can’t receive incoming connections. I can’t offer blocks, but I can pull it and compute new blocks. My cooperation is not complete but is good.