Pages:
Author

Topic: All Bitcoind / Bitcoin-qt nodes failing to come up. Workaround inside! - page 2. (Read 17439 times)

donator
Activity: 213
Merit: 100
Just got this message with Qt: "Corrupted Blockchain Detected do you want to rebuild".  Advice please.  TIA

Click "Abort" and upgrade to Bitcoin-Qt 0.8.5 before restarting the app. That sorted the problem for me.
newbie
Activity: 46
Merit: 0
Just got this message with Qt: "Corrupted Blockchain Detected do you want to rebuild".  Advice please.  TIA
legendary
Activity: 1500
Merit: 1022
I advocate the Zeitgeist Movement & Venus Project.
But what I want to know is why does (approx) 96% of the blockchain reload in about an hour and the last 4% take several hours?

The checkpoint.
full member
Activity: 182
Merit: 100
Provider of Bitcoin products and services
I didn't install the update the other day when the bug surfaced but after reloading the blockchain (it took 20hours) everything worked fine.

I have used the client to carry out many transactions since then with no problem. But this afternoon it "crashed" again and I am currently having to reload again. A pain in the arse and I will try to do everything correctly next time.

But what I want to know is why does (approx) 96% of the blockchain reload in about an hour and the last 4% take several hours?
staff
Activity: 4242
Merit: 8672
On my side reindexing fixed the problem. I'm using v0.8.3 Coin Control client on WinXP SP3.
It will, sort of, if the problem transactions are not in the last 100-288 blocks or so and you leave it up after the rescan long enough catch up. But no need to now as 0.8.5 is out which fixes it.

This means that each experiment (SX wallet,mastercoin...etc)touch Tx can corrupted thousand users databases in Bitcoin-Qt?
Thats why unusual transactions are normally filtered out by the network, but permitted on the separate testnet.  The corruption in this case was inconsequential, but tripped up the start-time sanity checking.

This particular issue is fixed now.
hero member
Activity: 743
Merit: 500
Is it known who submitted these transactions, and with what client?
SX wallet software
This means that each experiment (SX wallet,mastercoin...etc)touch Tx can corrupted thousand users databases in Bitcoin-Qt?
staff
Activity: 4242
Merit: 8672
Is this the bug I reported back in March?
No, absolutely not.  Your database was corrupted and needed reindexing.  If you are on a mac, your issue may have been fixed in 0.8.4.

newbie
Activity: 39
Merit: 0
Thanks for the post, it's very helpful~
hero member
Activity: 900
Merit: 1014
advocate of a cryptographic attack on the globe
full member
Activity: 368
Merit: 100
Seems there are those taking advantage of the FUD produced by this glitch:

https://www.youtube.com/watch?v=MUGgdov5P6g

staff
Activity: 4242
Merit: 8672
Is it known who submitted these transactions, and with what client?
I do. They were created by Genjix and his SX wallet software. Looks like it was due to a failure to initialize the version numbers in transactions. I was able to determine this because they spent funds send to the well known and oft reused libbitcoin donation address two hops back, so I sent Genjix an email to ask and he confirmed and tracked down his bug.
 
hero member
Activity: 868
Merit: 1002
Is it known who submitted these transactions, and with what client?
staff
Activity: 4242
Merit: 8672
I encountered this problem this morning before I was aware of this thread, but in my case reindexing, although it took all day, was successful.
Indeed, reindexing will now work if after the reindex you leave the node running long enough to process the trigger block and the next ~100 blocks. However if more of these transactions get mined it will break again.

It's ~mostly harmless to have the check level down, it just changes the checking at startup. ... it means _if_ you suffer disk corruption your node may eventually produce a bad block if mining or get stuck processing the chain in the future.  That said, after this we may rename the checklevel knob in the next version just to turn it back to the normal level for people who've stuck in this workaround.

Sorry for silly question, but would it not be better to release 0.8.5 version with this bug fixed, than to give instructions for workaround? Version 0.8.3 also had just one fix added, so why not do the same?
0.8.4 had three-ish changes, but they also had at least three weeks of testing (more much more for some of them). Partially this was possible because we were able to keep the bug that triggered the release a secret until publishing the fixed version.  Because of the workaround is basically as good as the fix and factors mentioned above getting a fixed version out is slightly less urgent than it was for the first day after the issue happened, and I'm not inclined to rush out a version which isn't thoroughly tested.

The fix for this is now merged in the git development branch. There will be an updated release soon.
full member
Activity: 120
Merit: 100
Sorry for silly question, but would it not be better to release 0.8.5 version with this bug fixed, than to give instructions for workaround? Version 0.8.3 also had just one fix added, so why not do the same?
member
Activity: 68
Merit: 10
I encountered this problem this morning before I was aware of this thread, but in my case reindexing, although it took all day, was successful.
I have now added the suggested line to my bitcoin.conf file, and when I tried it again, it started up correctly.
Lowering the checklevel can't be good for security, so hopefully we will be informed when the extra line may no longer be needed?
staff
Activity: 4242
Merit: 8672
Why this resulted in bitcoin failure to come up?  With security model in place should have resulted in a chain fork, yes?
There is no network rule that does anything with the transaction versions currently, there is no fork because the consensus algorithm doesn't care if its consistent. The startup database validation cares if the database is correct, however.
legendary
Activity: 924
Merit: 1132
Why this resulted in bitcoin failure to come up?  With security model in place should have resulted in a chain fork, yes?
newbie
Activity: 56
Merit: 0

You can workaround this issue by adding -checklevel=2 to your command-line arguments or checklevel=2 to your configuration file.


That worked perfectly!

Thanks!
member
Activity: 105
Merit: 11
In Windows, locate the file bitcoin-qt.exe
Usually is to be found in C:\Program Files (x86)\Bitcoin\ (on 64 bit version) or C:\Program Files\Bitcoin\

Right click on the file bitcoin-qt.exe  and select Create Shortcut. On the new file that appeared (bitcoin-qt.exe - Shortcut or bitcoin-qt.lnk) right click and select Properties.
add to Target line
-checklevel=2

as in this picture

http://i.imgur.com/8P1rnRA.png

Then click Apply, then execute.
donator
Activity: 406
Merit: 252
Study the past, if you would divine the future.
i dont have that file inside the bitcoin folder

That's okay, you can just create it and add the line gmaxwell mentioned.

https://en.bitcoin.it/wiki/Running_Bitcoin#Bitcoin.conf_Configuration_File


How exactly? I'm not a techie and that link doesn't make sense to me...(I have a Mac)


dont worry about the link just create a new file and add "checklevel=2" inside that file as text and then save as bitcoin.conf.



Thanks! That worked perfectly! What a great community!




awesome! Smiley

this community is great, just remember to help others that dont know much too so that when you ever need help someone can help you out
Pages:
Jump to: