All Bitcoind / Bitcoin-qt nodes failing to come up. Workaround inside!

[gmaxwell]

Due to a bug introduced in Bitcoind/-qt introduced in v0.8.0 nodes may fail to come up after restart, reporting:

": *** coin database inconsistencies found"
and/or
"Do you want to rebuild the block database now?"

Reindexing will not solve the problem (so I do not recommend you do so, at it will just waste your time).

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

The problem that an inconsistency in the transaction database has been caused by some unusual whos version cannot be represented in the database. This inconsistency is correctly detected by the agressive database sanity-checks on startup.  Because this inconsistency happens to be in a field we currently do not use for anything, it is safe to ignore it for now. Lowering the checklevel skips these and other checks and allows the node to proceed as usual.

The issue may resolve itself within another 200 blocks or so if no more of the trigger transactions are added to the blockchain after the triggering block falls out of the window used for consistency checking, but because it could easily happen again a longer term fix is required and has been submitted for review.

UPDATE: 0.8.5 is now out and fixes this issue.

Walkthrough in OSX:
Open a terminal and type
open /Applications/Bitcoin-Qt.app --args -checklevel=2

Walkthrough in Windows:

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

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

Then click Apply, then execute.

[1715263187]

1715263187

[1715263187]

1715263187

[1715263187]

1715263187

[btcsql]

amazing work, most appreciated. Thank you.

[favdesu]

so it'd be better to wait until this is fixed if I don't need bitcoin-qt asap?

[fpgaminer]

gmaxwell, I'm curious about a discrepancy between the wiki's Protocol Specification page, and the Bitcoin-QT client's CTransaction class.  The wiki says nVersion is uint32.  CTransaction says int.  Which is correct?  Should the wiki be updated?  Seems to me like versions should never be negative, and uint32 is thus more appropriate.

[gmaxwell]

gmaxwell, I'm curious about a discrepancy between the wiki's Protocol Specification page, and the Bitcoin-QT client's CTransaction class.  The wiki says nVersion is uint32.  CTransaction says int.  Which is correct?  Should the wiki be updated?  Seems to me like versions should never be negative, and uint32 is thus more appropriate.

The "protocol specification" page is just some page on the wiki. It has some useful things, but I wouldn't be shocked if it had some flaming errors. (The 'protocol rules' page certainly has some humming omissions).  Right now the version is meaningless: all values should work in blocks.  The issue here is not really uint32 vs int32.

[goodbc]

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

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

Then click Apply, then execute.

[fpgaminer]

Right now the version is meaningless: all values should work in blocks.  The issue here is not really uint32 vs int32.

Well, if the Satoshi client had used uint32 ...

all values should work in blocks.

Except now nVersion == 0 or with the high bit set is non-standard

Anyway, thank you for the response!  I was just curious, and wanted to make sure there weren't going to be any other weird bugs cropping up because of it.

[gmaxwell]

all values should work in blocks.

Except now nVersion == 0 or with the high bit set is non-standard

Which has nothing to do with them working in blocks.  >1 was already non-standard, the other values not being was an omission. Discouraging the casual use of these fields is important for having them be viable upgrade mechanisms: E.g. if in the future the community wants to do a soft-fork to enforce some kind of coin-value-in-scriptsig, say, we'd use a version=2 to trigger making sure the inputs values matched after some height... but we couldn't do that if some implementations were putting random numbers in the version field just for fun.

I was just curious, and wanted to make sure there weren't going to be any other weird bugs cropping up because of it.

Always bet on more bugs. I suspect we'll ultimately make the version field unsigned, but I can't say for sure until I've actually gone and done it and seen how disruptive it'll be to the codebase.

[goldlyre]

I've put all my coin in Armory which requires Bitcoin-qt working properly first. 

[omehenk]

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

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

Then click Apply, then execute.

This worked for me - thx U.   

Henk

[bitcoindigi]

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

worked, thanks!!

[FrankDizapo]

Thanks this works for me!

[samson]

Is this bug present in the latest 0.8.4 version released on September 3rd ?

Does anyone have any idea of the timescale until the full fix is released in a new version that new users can download and start using without using the workaround ?