~5mbit on my side took 3 minutes for zip (80+mb) version....Yes,
but I was talking about the windows download so slow...
The linux, ok no problem all good... but waiting for the maternode start and windows download take hours... (I edit the link in my first post to put the good version )
wget https://www.dashpay.io/binaries/dash-0.11.2.16-linux.tar.gz --no-check-certificate
tar zxvf dash-0.11.2.16-linux.tar.gz
cp dash-0.11.2.16-linux/bin/64/dashd .
./darkcoind stop
sleep 6
rm darkcoind
mv .darkcoin .dash
mv .dash/darkcoin.conf .dash/dash.conf
rm .dash/peers.dat
./dashd
So I must have herpa-derped something and receiving this error "Incorrect or no genesis block found. Wrong datadir for network?" after I attempt ./dashd. The thing is, I changed the name on .darkcoin and darkcoin.conf to their respective dash names, and I was able to get my other MN updated no problem. I did experience a corrupted blockchain and that could be the root of it. Has anyone else found this error? Unsure how to redownload the blockchain when I can't even get the daemon to run.
Ahh... I guess I know... To explain this we need to go back in history a bit Not so long ago first round was actually a "dirty" mixing - it was a process of creation denoms during that first round. So logic to count rounds was "hey, I found a denom in that tx - that's a mixing". And then we moved to preliminary creation of denominations so that only denominations were legit to enter even first round of mixing. But logic behind round calculation stayed the same and that was ok for that time. New wallet however has a lot more strict rules to that: it count each input independently and do not count them at all if there was even a single nondenom input in that tx. So these "dirty" rounds are completely ignored now. This should be more accurate and secure but you will need to mix a bit more though.
I was looking in the threads to find at what version this became the rule. Was it v.11.1.x ?Ahh... I guess I know... To explain this we need to go back in history a bit Not so long ago first round was actually a "dirty" mixing - it was a process of creation denoms during that first round. So logic to count rounds was "hey, I found a denom in that tx - that's a mixing". And then we moved to preliminary creation of denominations so that only denominations was legit to enter even first round of mixing. But logic behind round calculation stayed the same and that was ok for that time. New wallet however has a lot more strict rules to that: it count each input independently and do not count them at all if there was even a single nondenom input in that tx. So these "dirty" rounds are completely ignored now. This should be more accurate and secure but you will need to mix a bit more though.
You are amazing sir!! TY!I messed up everything like you, this is what I executed:
./dashd stop
cp .dash/dash.conf ~/
rm -rf .dash
mkdir .dash
cp dash.conf ~/.dash/
chmod 444 .dash/dash.conf
./dashd
Wait for the blockchain to be downloaded.
If we are talking about preliminary denominations then I believe you are right https://github.com/darkcoin/darkcoin/blob/v0.11.1.x/src/darksend.cpp#L1699I was looking in the threads to find at what version this became the rule. Was it v.11.1.x ?
Just tried to load the wallet. It was fully sync'd and all good to go. I encrypted the wallet and then the got the payment request error. I closed the error and tried to open the wallet then had the no wallet loaded.Is that with some custom shortcut/cmdline?
I worked it out. Closed everything. Shut down my laptop. Threw it in the trunk of the car, drove over a bumpy road, come home restarted it and it all works fine now.:grin:Just tried to load the wallet. It was fully sync'd and all good to go. I encrypted the wallet and then the got the payment request error. I closed the error and tried to open the wallet then had the no wallet loaded.
I still can't open the wallet, it gives the message that it is already running. Still get the payment request error.
I got the "masternode vote" crash without litemode. But, when I restarted dash, I no longer have the high CPU load I reported earlier.another bug found when using -litemode switch.
"dash-qt.exe -reindex -litemode" causes near immediate crash of win-qt.
also, caused a crash when I ran 'masternode vote' in a -litemode wallet debug window. (that I forgot was in litemode)
...also, caused a crash when I ran 'masternode vote' in a -litemode wallet debug window. (that I forgot was in litemode)