Search results

No... there is always going to be a wallet.dat file generated when the daemon is run if there isn't one already there. In a cold/remote setup, the wallet.dat file on the remote masternode (the VPS) is unfunded and 0. It doesn't matter if your server is comprised because there is essentially...

What are you talking about?

Sure looks like your update went fine. If you're tied out with the block explorers in terms of height, you're good to go. :)

Even at 4 rounds, it's 1 in 81. Not without reasonable doubt...

Your probabilities are 3^# of rounds. You tell me if you can prove without a reasonable doubt who sent what and where. Focus on >8 rounds.

If you didn't initially delete your peers.dat file before reindexing, there is a chance you will get that error. Always delete the peers.dat file before reindexing to get fresh peers.

Give it time to populate on the site. Check again in an hour or two. It also might be the case that they sent their coins to an exchange or elsewhere and the masternode is still in the process of dropping off the list.

Yes, download from the link, go to your datafolder (generally the same location as where your wallet.dat file resides) and delete peers.dat. Then replace the exe/binary with the newly downloaded client and run. BTW, if your wallet.dat file isn't 61000 (use getinfo in the console to find out)...

I think that makes sense to prompt a user the ability to specify where they want their datadir and/or wallet.dat file saved at. The default could be as normal but being able to specify could help prevent these sorts of losses.

Forward thinking since it's on github ready to pull and compile.

Chances are if you specified your datadir somewhere off the live drive that allowed the written files to be saved in the event the live environment crashed, you would have your coins still. The decision to keep the datadir enclosed in the live environment when DS creates new addresses to the...

Live environment or not, maintaining backups on an external disk that isn't live is good practice. It just seems it was a poor timing for your live environment to crash without you having a recent backup after all the new addresses were added to the wallet.dat file.

If you are running a hot wallet on your server, yes. If it is cold/remote where the masternode doesn't contain the 1k on server, then no.

If you started DS, your wallet will be generating new addresses for the coins to go to. If you do not have a wallet.dat file backed up containing these addresses, your coins are lost. Live environments are dangerous in this regard.

Want a really good explanation and the only explanation? Greed. There is no other way to spin it other than greed.

The fact that a large pool though is gaming the system means even after this is fixed, that hash should spread to fair pools. Would love to see the DCT pool get that hash. I hope the 2-3 days worth of payments is enough to cover the backlash from all this.

Only works when enforcement is off (granted, it has been off for a while now)...

I think it was more of a point to show where it is at. If you can find your data folder, it should be in there unless you have arguments telling to look in a different location (or for a different file name). Further, you should still be able to obtain a backup from inside the client by using...

Then the reconverge with the spork is working network wide. There were explorers stuck on block 218963 that have since caught up and are on track again.

So just to clarify, your steps for reindex are: ./darkcoind stop rm peers.dat from the data folder ./darkcoind --reindex Correct?