Separate names with a comma.
Discussion in 'Development Dispatches' started by moo1337, Jul 25, 2016.
Progress on staking, should be done soon.
I'd suggest a pool list/presets dialog or tab that can be used to auto-fill the relevant fields. This would obviously make pool use easier in general, but also it would make it reasonable to spread tickets around between pools, and avoid errors with mismatching addresses/fees.
Another capability that might be good if the above happened is a fee supplement/donation percent that would increase pool fees above the required minimum.
Any way to reduce the time taken for dcrd to sync from the beginning to the latest block?
It is running at 20blocks every 10secs. How to fasten it?
@Ayush It's a major TODO for the developers. But a solution I use is to keep a zipped copy of the mainnet/data folder with the block chain synced up to a point shared online. When making a new dcrd setup, I just download it and start from there.
What if the files are corrupted? DCRD doesn't check that, i suppose. What happens then?
Well, why would they be corrupted? If I myself zip them, and the zip integrity holds...
If the devs get time they could implement ur idea. And possibly in the future dcrd would download the zip on its own and sync to latest block in a jiffy.
In Bitcoin there is talk (or maybe completed actions) about essentially clipping old transactions involving only used outputs, or something along those lines, those reducing the burden of syncing the blockchain. I'm no blockchain expect, so I definitely explained that wrong and I don't know if it applies to Decred.
Regarding a raw download as a real a solution, I'm quite sure that's out if the question for a variety of reasons.
There are several things that can be done and are planned in regards to speeding up the initial sync.
For one, there is current work underway to make use of my major overhaul of the database and blockchain package from the upstream btcd which will make a rather large difference once it is finished being integrated into dcrd.
After that, the plan is to convert the ticket database to use the new much faster database along with the atomic transactions it provides in order to completely avoid the need for the whole ticket sync/resync on restart that is required with the code today due to it being stored as a separate entity that is gob-encoded.
Another area that will ultimately make its way into Decred after it is completed and deployed upstream is multi-sync which will provide a more robust and faster download of the data itself along with opening the door for more parallel processing and simultaneous usage of CPU and storage.
From a more theoretical standpoint on a longer time scale, there are also many, many more things that can be done. For a few examples of some of these possibilities, there are opportunities such as implementing standard and stake utxo caching, transmission of compressed and/or partial blocks, rolling checkpoints, and utxoset commitments with fraud proofs.
I should also note that all of these aforementioned things (and several others) can be done without even needing to change consensus rules. What's really neat about the underlying Decred tech though is it allows the consensus rules to be changed via majority community consensus (PoS votes), so that opens the door for significantly more advanced scalability possibilities that would not be possible without the ability to seamlessly hard fork.
Transactions might be corrupted. Actually, it's one of the main reasons why I didn't release the cross-platform GUI wallet yet.
There is absolutely no way for this "rebuild from seed" stuff in GUI wallets but I don't know other solutions.
The first transaction ("pending") actually was sent 11 days ago and was successfully mined. But dcrwallet for some reason doesn't know about this. The same problem is with expired in the mempool tickets. Sometimes they are cached and the only solution is resync from blockchain.
I was using the installer and I ran ./dcrd and had it sync to the latest block, then when I tried to run ./dcrwallet with my usual -u xxx -P xxx --walletpass xxx --dcrdusername=......
I ended up with
RPCS: RPC authentication failure from 127.0.0.1:37062
shown in dcrd. What's the problem? How to fix this?
We're talking about the blockchain data here. Not the wallet.db. I'm absolutely not advising to zip and upload that.
What do you mean by the transactions might be corrupted? Are you saying that dcrd does not work properly (e.g. non-deterministically) when processing the blocks? As long as you close down dcrd gracefully, the data in blocks_leveldb and ticketdb.gob is fine. The wallet is another story, I acknowledge, as it has been very sensitive and prone to breakage.
dcrd is apparently expecting different credentials. check dcrd.conf or the command line used for dcrd.
Is there a github issue for this?
But I don't see how mempool relates to blockchain corruption. If you close dcrd, that clears out your mempool...
Kind of an issue: Dcrinstall v0.2.0 crashes on install on 32-bit Windows 7.
Blank command window hangs there for 10 seconds and closes. Nothing apparently happens.
(Upgrade still possible by manually replacing the binaries.)
EDIT: Please ignore. It works fine! User error.
Thanks for the report, Nimrod. It would be ideal if you could report these issues in their corresponding GitHub repo:
@Nimrod, it sounds like it actually may have worked. By default, dcrinstall does not have any output. Have a look at %HOMEPATH%\decred\dcrinstaller.log and see what it did. Chances are the install worked and that all the relevant binaries are also in %HOMEPATH%\decred\.
If that is not the case please write this issue up in github with a detailed description on how you ran it. It would be helpful if you could provide the log file as well.
Yes! It's working. You are correct. I was expecting some kind of response.
I have 65 decred unlocked.
In my "default" account. But when I try to buy tickets it comes as insufficient funds available to construct transaction. Y might have this happened?
I even tried consolidating my wallet. But still same result.
Any help please.
Your report does not contain any information to help debug this. I suggest starting a github issue in the appropriate repo so that we can get this resolved.
Things to add to the report: version of software, non-default settings, commands run etc.