We are in the last throws to finalize 0.5.0. As some may have noticed the release was delayed a bit and that was due to complications on CUDA-windows. The 0.5.0 release has major performance enhancements. This is great however, this is going to be a flag-day release. We ditched the old database format and replaced it with a harder/better/faster/stronger one meaning people will have to do an IBD. Good news is that we think this will be the last flag day before we hit 1.0. We do encourage everyone to update immediately once 0.5.0 drops so that we can get a lot of community runtime.
Yes, this is the real question. We need some real life usability to push the project further. What is the plan for the near future?
Yep, and I'm wondering how it would look like at present unstable peers (at least they are unstable on my site). I can just hope that network will not colapse when many users begin with IBD.
Any tests executed prior to release ? Some people (and myself) mentioned less stable clients and more memory hungry from 0.3.0 up.
updated from git, tested, error below was not present 3 weeks ago : Code: dcrctl help COMMAND Error creating a default config file: open /home/q/.dcrd/dcrd.conf: no such file or directory
This is not an issue; just unfortunate warning prints. There are a few things happening. You called dcrctl with a valid command (help) however, you don't have config files and certs setup. As dcrctl tries to execute the help command (remotely!) it figures that out and returns an error. Code: Error creating a default config file: open /home/marco/.dcrd/dcrd.conf: no such file or directory is really a warning and I will change that. Code: open /home/marco/.dcrd/rpc.cert: no such file or directory is the actual error.
Actually, after reading the code one more time this is accurate. Admittedly, it is a bit confusing but it accurately describes what is wrong. There is not ging to a code change.
We're currently looking into issues with peer connectivity. Hoping to include a fix for flapping in the new release. Still not clear what could be causing possible unstable peers.
This issue is very much non-trivial and unfortunately there is no clear answer on how to solve it. This means that you should not expect a fix soon for this. Debates are raging in the dev community but it simply hasn't settled yet. Stay tuned.
Well to add an addendum @moo1337's comment, @davecgh and others don't feel like it's necessarily a bug. Basically until we get multipeer support (which is months of work), the choice is between forcing disconnects to peers that don't respond in a timely fashion to some requests, or letting bad acting peers hang around forever. We are sticking with the former of the choices for now. But rest assured, the network is still stable even though you may see some more frequent peer disconnects.
I think you may have misunderstood me. I said the fix is non-trivial. Very much so hence we don't have a quick fix. We want to help but we can't at this time. I suspect that the version change in your case may not have been the catalyst and is circumstantial.
Understood. My solution was to set up cold voting wallet. Since than no more missing votes. No missing votes, no worries.
We really do want to fix this and we have thought through a potential workaround before we do a rewrite. You can track this issue at https://github.com/btcsuite/btcd/issues/776.
@davecgh Does this mean that we'll have to do something manually like deleting the Dcrd folder before updating to v0.5.0? Or will the dcrinstall - replacing dcrd.exe will do all the necessary so the next time we'll start dcrd it will start to download the blockchain from initial block? Will it be better if we remove everything and start fresh, even recreating wallet from seed? Anyway I am sure there will be notes with instructions if something with dcrinstall or replacing binary files with v0.5.0 changes.
dcrinstall replaces the binaries. That means that dcrd will favor new db format and redownload all blocks. It'll work fully automated however, the only thing that won't happen is deleting the old database. That is a manual task.
To expand on what @moo1337 said, the new database goes into a different directory as to not interfere with the old one. When dcrd starts up you'll see a message that looks like the following: So, you'll want to manually delete the old one. It is not automatically deleted.
Thank you for the answers. So for Windows since even ticketdb.gob won't be needed with v0.5.0, we'll be able to delete the entire x:\Users\"username"\AppData\Local\Dcrd\data\mainnet folder after updating to v0.5.0 if this folder location won't be used anymore. It's good to know that there will be no interference and it will be an automated database switch after updating to v0.5.0. Deleting the old one will free less than 800 MB of space on our SSD/HDD and I guess the new database will be about the same size(probably smaller) if someone wants to calculate how much time it will take for dcrd to completely sync.
The mainnet folder is still used. The database folder under it is different however. The current one is blocks_leveldb, the new one is blocks_ffldb. Windows The following is a list of files and folders that can be deleted after 0.5.0: Folder -- %LOCALAPPDATA%\dcrd\data\mainnet\blocks_leveldb File -- %LOCALAPPDATA%\dcrd\data\mainnet\blocks_leveldb.ver File -- %LOCALAPPDATA%\dcrd\data\mainnet\ticketdb.gob The remaining files and folders needed for 0.5.0 should be: Folder -- %LOCALAPPDATA%\dcrd\data\mainnet\blocks_ffldb File -- %LOCALAPPDATA%\dcrd\data\mainnet\peers.json Linux/BSD/POSIX The list is the same except %LOCALAPPDATA%\dcrd is ~/.dcrd instead: The following is a list of files and folders that can be deleted after 0.5.0: Folder -- ~/.dcrd/data/mainnet/blocks_leveldb File -- ~/.dcrd/data/mainnet/blocks_leveldb.ver File -- ~/.dcrd/data/mainnet/ticketdb.gob The remaining files and folders needed for 0.5.0 should be: Folder -- ~/.dcrd/data/mainnet/blocks_ffldb File -- ~/.dcrd/data/mainnet/peers.json EDIT: Made the different OS sections a little more obvious