There are 3 buttons to export the logs from the UI.
I understand that but what can happen is that the node rejects new connections. The problem I have with having preferred peers is privacy. We should not encourage users to trust a certain list of peers, what we need to do is let users do whatever at their own risk. This is, of course, a temporary patch until PIBD is deployed and nodes supporting the feature take over the network, which will take time.
People’s nodes will connect to slow and inefficient peers, there’s not much we can do about that in terms of coding. The only thing we can do to help is to deploy reliable nodes everywhere. Let me expand on this a bit, because it’s a source of a lot of confusion in general.
Now, users report from time to time having to wait a long time to do an initial sync, they see it as a problem of the wallet, in my case Grin++. The answer to this is: slow connections are not a problem of the wallet itself. So, some users will say, “but I close it and open it again and it’s still slow”, and the answer to that is, “because you’re probably in the same batch of slow peers”, that’s why cleaning the peers database usually helps. The node will randomly try to connect to a certain amount of peers, and that’s what we want, we don’t want nodes to filter peers by latency or anything like that. And one of the reasons is that, for example, a government could deploy super-fast nodes and then monitor citizens’ behavior. The downside is that the network must then have a good number of nodes run by independent, non-compressed community members, which is not easy, but is the healthiest thing to do.
I understand that this is frustrating for many users, that’s why I took the initiative to help people deploy nodes by doing the technical work by myself. I hope more people follow the example, the CC could actually promote Linux Installation Parties like but for public nodes, but that’s another topic. Been said that, let’s clarify these concepts:
Utility = whether it provides the features you need.
Usability = how easy & pleasant these features are to use.
Useful = usability + utility .
I can say that Grin++ is more focused on bringing an easy and pleasant experience for regular users than the Rust node, but there are many things that are out of our (grin-node and Grin++) domains, and the “slow” synchronization due to slow peers is one of them. I found Grin++ syncronization faster than the rust node, but only when you are not connected to slow peers, I haven’t take a look into the Rust code in deep, so I can only say that this might be perception. After v1.2.7 the only reported problem in Grin++ regarding the synchronization process is this, but I confess I only experienced it once and it was running Grin++ on an Android phone. Still, I want to take a look because I want to make synchronization easy and pleasant for everyone but without compromising privacy and security.
To improve usability we are doing things like statically compiling dependencies, so you don’t have to deal with that 99% of the time, we are shipping Grin++ with the Tor binary signed by the Tor Project, we also check if your wallet is accessible or not. The next step is then to guide users to set up Tor bridges themselves, and help them avoid censorship and make their wallets reachable. Also, to facilitate the initial synchronization if the user is constantly connecting to slow peers, I believe that having the ability to connect to peers will help them go through the process of downloading 2GB of information.
I personally want to make things as easy and pleasant as possible for Grin++ users, but we also have to work to offer more privacy, and I see that the possibility of generating a new address helps, it’s not a big deal, but it helps.
This is very good, Snowflake proxies looks like a good option, I will have to double check how this affects hidden services, if the locally started hidden service is not affected in any way, I don’t see why not to use it. Thanks for the link.