Behaviour might be different based on OS, I am using Win7 64-bit with Bitcoin Core v0.12 64-bit.
The code I quoted is the same code regardless of OS (there isn't separate source code for the different OS versions). |
|
|
|
5. Start Bitcoin Core again, it will detect corrupt wallet.dat, rename it to wallet.(random numbers).bak and exit.
Those are not "random numbers" but instead the current time stamp (as you can see clearly in the code I posted previously). And Bitcoin Core does not delete this file anywhere (please show me the code where it does). So if you deleted the empty "wallet.dat" and renamed the "wallet.XXX.bak" back to "wallet.dat" and restarted you'd just end up with a new empty "wallet.dat" and now a new "wallet.YYY.bak" (because the file is still corrupted and can't work as a valid wallet). The file "wallet.XXX.bak" and "wallet.YYY.bak" would actually be identical (as it hasn't deleted anything). |
|
|
|
As explained - the wallet *is corrupt* and can't be used (you're behaving like someone whose car is broken down who just keeps on trying to restart the engine when you've been told it is broken down). You said you had an old backup so go and restore your old backup (and do that using a different machine as recommended by myself and others) and until you've done that I don't think you can expect any further assistance. EDIT: Interesting timing that this suddenly has appeared: https://bitcointalk.org/index.php?topic=1382650.msg3049193;topicseen#new(perhaps this topic is actually a marketing exercise) |
|
|
|
|
No - that is not what happens (please read the code and if you can't then take my word for it or ask another programmer to read it and explain it to you).
It is failing to correctly the open the "wallet.dat" file which is (most likely) due to it being corrupt (there may be other reasons I guess of course but they are very unlikely to be relevant to this situation) so it then renames it (once it has been renamed you no longer have a file called "wallet.dat" which is why it can then create a new one).
Once it has renamed the bad "wallet.dat" file it should have no problem in creating a new "wallet.dat" (it would only not be able to do that if the rename failed but you reported that it did rename as was recorded in your log file).
I'm not sure when this behaviour was introduced (older versions of Bitcoin Core would simply fail to start if the wallet was found to be corrupt).
|
|
|
|
|
So - it is not "sending your wallet somewhere"*** but renaming the corrupt wallet.dat to wallet.XXX.dat (as it can't open that wallet).
It then will create a new empty wallet and continue. Your old wallet is still there (just renamed to wallet.XXX.dat) but that file is corrupt - so if you rename it back to wallet.dat you are of course going to just go around in circles (as renaming isn't going to magically repair it).
You do get that this wallet "is corrupt" don't you?
***(perhaps you consider "renaming" to be "sending somewhere" in which case we have resolved that communication problem)
Before going any further I would recommend that you take a copy of the "wallet.XXX.dat" file.
|
|
|
|
Okay - so here is the relevant code to what is actually going on: bool CWallet::Verify(const string& walletFile, string& warningString, string& errorString)
{
if (!bitdb.Open(GetDataDir()))
{
// try moving the database env out of the way
boost::filesystem::path pathDatabase = GetDataDir() / "database";
boost::filesystem::path pathDatabaseBak = GetDataDir() / strprintf("database.%d.bak", GetTime());
try {
boost::filesystem::rename(pathDatabase, pathDatabaseBak);
LogPrintf("Moved old %s to %s. Retrying.\n", pathDatabase.string(), pathDatabaseBak.string());
} catch (const boost::filesystem::filesystem_error&) {
// failure is ok (well, not really, but it's not worse than what we started with)
}
// try again
if (!bitdb.Open(GetDataDir())) {
// if it still fails, it probably means we can't even create the database env
string msg = strprintf(_("Error initializing wallet database environment %s!"), GetDataDir());
errorString += msg;
return true;
}
}
if (GetBoolArg("-salvagewallet", false))
{
// Recover readable keypairs:
if (!CWalletDB::Recover(bitdb, walletFile, true))
return false;
}
if (boost::filesystem::exists(GetDataDir() / walletFile))
{
CDBEnv::VerifyResult r = bitdb.Verify(walletFile, CWalletDB::Recover);
if (r == CDBEnv::RECOVER_OK)
{
warningString += strprintf(_("Warning: wallet.dat corrupt, data salvaged!"
" Original wallet.dat saved as wallet.{timestamp}.bak in %s; if"
" your balance or transactions are incorrect you should"
" restore from a backup."), GetDataDir());
}
if (r == CDBEnv::RECOVER_FAIL)
errorString += _("wallet.dat corrupt, salvage failed");
}
return true;
}
That would seemingly indicate to me it had already found an invalid "wallet.dat" and so had renamed it (to allow you to try and recover it later) and started again with a new wallet. It never "sent" your wallet anywhere but the corrupt "wallet.dat" became the new file "wallet.XXX.dat" (where XXX was the time stamp when this occurred). |
|
|
|
but the system, send the file to somewhere and put a new wallet.dat in there.
It doesn't do that so I think you aren't going to find any help here whilst you keep on insisting that Bitcoin Core does things that it simply doesn't do. |
|
|
|
|
As Bitcoin Core does not "send wallets" anywhere either the OP is being purposely dense (or worse) or this whole topic is actually a joke (the fact that he doesn't even bother trying to restore his old backup suggests the latter to me).
|
|
|
|
Thanks! Though as a malicious vendor, can I not 'push' the transaction of my 'customer', by just copying the transaction and broadcast it to the network?
No because txs are unique (they cannot be copied in the way that you are thinking). A tx is not as simple as "pay X address Y amount". If you make two payments of 10 BTC to one vendor they are not identical at all and only the owner of the wallet that has funds can release those funds (by creating the tx that does so). |
|
|
|
Unless you made a backup, there is probably a low chance of recovering the coins.
He stated that he did have a backup (which even if old will probably have all the necessary keys assuming he doesn't do many txs). |
|
|
|
|
Surely whatever possible bug there might (or might not) be (as renaming wallet files is a very bad idea in general) what matters is that you recover your coins isn't it?
(so restore your backup wallet into a fresh installation on a separate computer and get your coins back first before worrying about other things or paying big bucks for help which you may not even need)
|
|
|
|
No, i did not safed the bak file before, i did not expect that the system will remove the renamed wallet.dat
and yes, i know the adress, i have a backup of the old wallet.
If you have a backup of the old wallet then you should be able to recover your BTC. Perhaps to avoid confusion use a new Bitcoin installation (on a different computer so you don't risk making anything worse) and then copy your backup wallet.dat into the app data directory before you start Bitcoin. It will of course need to catch up the blockchain before it will show any balance so don't be alarmed when it shows a zero balance when you first start it (and of course it might take a day or two to catch up to the point where your BTC will suddenly reappear). |
|
|
|
|
Surely you had taken (several) backups of your wallet (especially if it contained over 200 BTC)?
Renaming files (that are not just normal docs you have created) is really not something that you should be doing unless you really know what you're doing.
|
|
|
|
What if there are several unspent inputs that I want to send at once to a single address. What form do I need to use then?
You can add other inputs as per this: createrawtransaction
"[
{\"txid\":\"040a4aadd58794ab0360af01cd30112898371f46a6a8a96e4122102d21038d83\",\"vout\":0}.
{\"txid\":\"040a4aadd58794ab0360af01cd30112898371f46a6a8a96e4122102d21038d83\",\"vout\":1}.
{\"txid\":\"040a4aadd58794ab0360af01cd30112898371f46a6a8a96e4122102d21038d83\",\"vout\":2}
]"
"{\"1TtxVxWQwXCcdrbzXFQZGnrBP8oSVjYwP\":0.0348}"
(assuming that the same txid had three UTXOs with vout's 0, 1 and 2 that you owned - I think the format I've used above is correct but you should verify that with the createrawtransaction documentation) |
|
|
|
Oh i remember there was some attack a while ago that faked transactions to make look them double spend is it the same kind this time?
No - the current attack seems to be a huge amount of low-fee txs which have basically meant that the usual 0.0001 fee is not confirming quickly at all (and if the attack continues your tx may end up being dropped from the mempools). My guess is that this is coming from those that are trying to push for taking control of Bitcoin development (they have deep pockets and no conscience). |
|
|
|
Thanks a lot for the quick explanation :-)
You're welcome and I hope you don't get too bummed out with Bitcoin over this (there is a current *attack* going on to try and slow confirmations). |
|
|
|
But considering it does have a fee is there still a chance that it will be canceled?
As it is very high priority that is not so likely (at least for the next day or two and unfortunately such txs can get stuck in the mempool for as much as a week). What nodes do when their mempools fill up is drop the lowest priority txs (so yours would not be likely dropped unless there are no other lower priority txs left to drop). |
|
|
|
Well it's a payment from bitify.com
Perhaps you should report the situation to them (suggesting that they increase their fee although this won't help with this particular tx as it has already been sent). Your tx is going to stay in the mempool for now so there isn't anything much else that can be done (other than wait). |
|
|
|
|
Not sure what you are expecting anyone to do - but it is very high priority so I'd guess it will confirm in the next few hours at least (you didn't pay enough fee to ensure that it can get confirmed any faster so maybe next time consider increasing your fee to at least 0.0002).
|
|
|
|
|
I am pretty sure any such AV reports are "false positives" (i.e. not the actual virus but some bytes that the software has confused with the virus).
Understand that the blockchain files are not "executable" so you aren't really risking virus infection even if they did contain a virus.
IMO you'd be best to configure your AV software to "ignore" the blockchain files.
|
|
|
|
|
Show Posts
