Could you name just one risk, please. Really, I mean just one.
Chia team butchered syncing process, and around 200k farms suffer from slow syncing, at the same time the notion of “corrupt” or “poisoned” db is being floated or some need for decentralization. However, so far I have not heard one, I mean one reason what really could happen.
I mean, I live in California, and so far I was not attacked by any lions, and my friend is telling me that this is because I am waring pants. Sure, I go with that, but still those lions are not that much on my mind.
There was a bug in an earlier version in which the dB could get corrupted. This actually happened to me. As an experiment I CV onnectvtobthe dB and ran SQL commands to patch it. It seemed to work, but still I preferred to start from scratch and sync on a fast windows on.
I am running a pi now and don’t have these current sync problems
Again, there are about 170k nodes out there, and most are fully synced. Percentage of those that are trying to catch up is really small (say all of us go through this process a couple of times, that is about 0.5% of nodes at any time). Whether you have 10 or 80 peers, you will see just one such node. The node that syncs basically piggy backs to one node at a time and sucks a bunch of blocks from it, not really from all those connected peers at the same time. The connection speed when downloading those blocks is around 1-2Mbps, so basically any peer can do that. So, this is not really an issue.
The whole thing with those “low quality nodes” was invented during the first two dust storms, when people saw nodes with height 0, and no data exchanges. Those people assumed that all those nodes were “low quality” and refused to consider that basically their nodes couldn’t handle those dust storms. under those conditions, the strain on db is caused by data exchanges between peers, thus db strain. What it implies is when the number of nodes is reduced, the node has a bit more headroom, and start syncing properly, but as it gets more peers, it chokes again. Those people didn’t realize that the key was dropping any nodes, not those that looked bad. That is basically the origin of that “low quality” nodes story.
Corrupted db is not so much a risk, but rather an unfortunate event. I doubt that either of those two sources (one is pool, the other a guy that contributed a bit on this forum) would do that on purpose. So, the worst case if that happens is that it will take ~30 mins to download such db, and the node will complain that db is bad. Usually pinging the source may fix such issue, or spending another 30 mins to get it from the other source should fix that problem.
On the other hand, some people on the forum mentioned that they have tried to download those dbs, and it still didn’t work for him (not you). From what I saw, most of those people had other problems, not really related to db being corrupted.
For me on i9-10900 a sync from zero takes ~30 hours (v1 or v2, basically no difference). For the OP that is a week or more. Also, during the full sync, your box is maxing out power consumption, so IMO there is no point to go through this process, having download options.
Saying all that, as everyone suggested, keeping your own copy is potentially the best thing to do (even if it is a month or so old one - created when applying Win patches).
If what @Bones wrote does not work out for you, then you could create a symbolic link.
In Windows, the command is “mklink.exe”
Run:
mklink /?
for details.
I vaguely remember a post where someone commented that symbolic links do not work for this purpose. So keep that in mind. But if that was reported, I suspect the person might have made a mistake. I cannot see how a properly placed symbolic link would not work.
By the way, the symbolic link can be used on a file-by-file basis – or – you can create a link to point a directory to a different directory. It is the same command.
There is also a “junction” option. Frankly, to me, the “junction” and the “directory” links seem to do the same thing. Maybe there is a difference?
No, it’s not a built in changeable option.
But it’s the config.yaml that ultimately controls everything.
Any other things you change, just change the .yaml.
Edit.
There’s an actual guide linked in the thread I linked to earlier.
There’s also instructions on symlink within that thread i originally linked as @seymour.krelborn was mentioning.
Nice to see all of you getting involved in my issue.
I believe the original intention of Chia was to be able to use your old hardware and repurpose it so it could plot and harvest chia. But doesn’t this bloated DB defeat that purpose?
Now it seems that to be able to catch up i need to install more memory, get a faster CPU and a bigger HDD. And i am already running an i5 and glasfiber network.
The problem started when the DB got too large for my SSD. Considering the very low amount of rewards and the increased cost of energy (in Europe), i don’t think upgrading the system will be worth it at all.
Directory junction on Windows works. I had it before migrating to Linux.
After migrating to Linux, I use symlink from ~/.chia to the location where I mounted a dedicated SSD
You have to remember, you were walking, then somebody gave you a two seater car, then you chose to take 5 guys to the beach. Isn’t the same somewhat? It doesn’t matter that you have a glasfiber connection, if you want to transport 40 guys you need a bigger bus!
