Ok I’m waiting patiently for light wallets, but I have 2 questions left.
- Will I see correct balances for my old accounts if I don’t download old blocks?
- Is it really technically impossible to continue download from some valid point and not re-download full chain of blocks in case of “corrupted” block somewhere in the end of chain?
Actually I asked this second question multiple times already but still haven’t got an answer. Just Is it technically possible or not?
I’am not the top expert but my opinion is:
1.) If you use the dumpprivkey and importprivkey code it should show ALL transactions for the given adresses you do this.
2.) You could maybe try to bypass this by downloading a bootstrap. This would replace all blocks you have on your hdd with a full chain, but it would need a re-sync than if i remember right.
I tested than back the first or second release and it synced within 2-3 hours fully on my end than back.
I will give it again a try now to see how fast it syncs today and trying to give some feedback in case something unusual happens.
1 Like
Did you open any special ports to get more connections ?
no. I didn’t change anything, just a full normal wallet install like it would do the average joe, no import, no bootstrap, no nothing, just as it was.
There’s a benchmark here for the initial download though I’m not exactly sure how this is generated: https://speed.z.cash/timeline/?exe=1%2C2&base=1%2B9&ben=initialblockdownload-time&env=1&revs=50&equid=off&quarts=on&extr=on
This puts it at 27168 seconds so that’s circa 7.5 hours.
These are 8 outbound connections. You can open up port 8233 and allow incoming connections to increase your connection count (and help the network) but it isn’t going to help the speed of the initial download. It’s not only downloading blocks but validating as it goes, which is time consuming. This is similar to Bitcoin so there are lots of discussions around this e.g. first one I found: How I can increase a outbound connections? · Issue #9217 · bitcoin/bitcoin · GitHub
My download is full on for over 24 hours now, and I am at 42.34%.
My disk is SSD, my Cpu is Quad Core 3,4 Ghz, 16 GB RAM DDR3 1833, and GPU GTX 1070 OC. I would say its not my configuration that is slowing the download, nor is my internet speed. I can say that benchmark must be wrong 100%.
After 2.5 hours i’am at 21%.
I’am doing a full stress test for this task this time. 100% cpu mining, 3 other wallets open and lot of other tasks. Installing everything NOT on a SSD disk but an older one (including the data folder!).
So far i would say under these circumstances and load the wallet is syncing perfectly.
We are downloading on the same wallet right ?

Then what sorcery is this, how is it syncing so much faster for you ?
I’am not sure: It could be better internet connection and for sure that i have more RAM with my 64GB at 2666. Pretty sure it’s the RAM that helps me a lot here.
My internet speed is 30/3, which isn’t bad and I don’t think is a bottleneck.
The number of zaddrs in the wallet makes a big difference, each one needs a separate scan of the blockchain.
Did you start with an empty/blank/new wallet or have you imported any keys?
Empty wallet, i just wanted to download it to test it.
One suggestion, maybe the foundation can post blockchain copy on torrent, which we would download fast and just place where its supposed to go. This is painfully slow.
I also have other proposals, but includes mentioning some other coins.
Its a good thought, but you’d still need to validate it somehow.
One last idea - at the top of the debug.log file there will be a message about ‘dbcache’
I’m betting its bigger on boxalex’ machine as he has more RAM & would explain the difference.
1 Like
you mean this?
2019-05-09 18:18:44 Cache configuration:
2019-05-09 18:18:44 * Using 2.0MiB for block index database
2019-05-09 18:18:44 * Using 120.0MiB for chain state database
2019-05-09 18:18:44 * Using 328.0MiB for in-memory UTXO set
This debug.log file is getting pretty big, 47MB after 39% syncing process…
Yup, thats the one…curious to see what it is for @Spiral1990
1 Like
Wouldn’t this default to 450MB on both if not explicitly set and that’s what is shown above? Actually setting this to a larger value presumably may help though?
-dbcache=
Set database cache size in megabytes (4 to 16384, default: 450)
1 Like