Version 0.6 release candidate 1

[Pieter Wuille]

Anyone who used 0.6.0rc1, got stuck on block 170059, upgraded to 0.6.0rc2, and is still stuck: can you please contact me?

I have implemented a potential fix for this problem, but it is hard to find test cases.

Thank you.

[1714167371]

1714167371

[1714167371]

1714167371

[1714167371]

1714167371

[1714167371]

1714167371

[Pieter Wuille]

Anyone who used 0.6.0rc1, got stuck on block 170059, upgraded to 0.6.0rc2, and is still stuck: can you please contact me?

I have implemented a potential fix for this problem, but it is hard to find test cases.

Thanks to mcorlett and kish for helping. It seems my fix works.

[br00t]

v0.6.0rc2 built from master branch still stuck at block 170059 :-( Tried -rescan and -paytoscripthashtime ... any thoughts?

[mcorlett]

v0.6.0rc2 built from master branch still stuck at block 170059 :-( Tried -rescan and -paytoscripthashtime ... any thoughts?

Pieter instructed me to run his minireorg branch, and it seems to be working. I assume it's this commit.

It has also been made into a pull request for the mainline client: https://github.com/bitcoin/bitcoin/pull/930.

[br00t]

Thanks mcorlett I'll give it a try...

[deepceleron]

I fired up 0.6rc1 after a week, and got the same problem, stuck at 170059, also with the "WARNING: Displayed transactions may not be correct!" Reinstalling bitcoin-0.5.2 over it did not fix the problem, so whatever problem it had is left behind in the wallet or blockchain. I'll replace the blockchain with my block 165000 download and see if it gets past, otherwise we've got a wallet problem.

So this transaction messed up everybody then?:
http://blockexplorer.com/tx/6a26d2ecb67f27d1fa5524763b49029d7106e91e3cc05743073461a719776192

We basically got a in-the-wild example of this?:

The problem [as I understand it] is if somebody purposely creates a transaction that is valid under the old rules, invalid under the new ones.  If an old client creates a block with that transaction, the majority of the network will not acknowledge it because of the invalid transaction, so eventually the network will orphan that block with one that does not contain the invalid transaction.

My debug.log (paste) when errors start in 0.6rc1

received block 000000000000047e131d
SetBestChain: new best=000000000000047e131d  height=170058  work=256371172561403830047
ProcessBlock: ACCEPTED
received block 00000000000003bd2bf5
SetBestChain: new best=00000000000003bd2bf5  height=170059  work=256377602133619763100
ProcessBlock: ACCEPTED
received block 00000000000002dc756e
ERROR: ConnectInputs() : 6a26d2ecb6 VerifySignature failed
InvalidChainFound: invalid block=00000000000002dc756e  height=170060  work=256384031705835696153
InvalidChainFound:  current best=00000000000003bd2bf5  height=170059  work=256377602133619763100
ERROR: SetBestChain() : ConnectBlock failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED
received block 0000000000000abd377c
REORGANIZE
ERROR: ConnectInputs() : 6a26d2ecb6 VerifySignature failed
ERROR: Reorganize() : ConnectBlock failed
InvalidChainFound: invalid block=0000000000000abd377c  height=170061  work=256390461278051629206
InvalidChainFound:  current best=00000000000003bd2bf5  height=170059  work=256377602133619763100
ERROR: SetBestChain() : Reorganize failed
ERROR: AcceptBlock() : AddToBlockIndex failed
ERROR: ProcessBlock() : AcceptBlock FAILED

Error fun from reverting to 0.5.2

askfor tx acb6e1fa6b8e3d0ab5d7   0
sending getdata: tx acb6e1fa6b8e3d0ab5d7
ERROR: ConnectInputs() : acb6e1fa6b mapTransactions prev not found 0c76b20c0e
ERROR: AcceptToMemoryPool() : ConnectInputs failed acb6e1fa6b
storing orphan tx acb6e1fa6b
askfor tx 65ec6b3d1f63bd125040   0
sending getdata: tx 65ec6b3d1f63bd125040
AcceptToMemoryPool(): accepted 65ec6b3d1f
askfor tx d6b2b4c5b4fe3f9f6b58   0
sending getdata: tx d6b2b4c5b4fe3f9f6b58
ERROR: ConnectInputs() : d6b2b4c5b4 mapTransactions prev not found e24d802c1a
ERROR: AcceptToMemoryPool() : ConnectInputs failed d6b2b4c5b4
storing orphan tx d6b2b4c5b4

[Pieter Wuille]

That is exactly what happened.

Someone mined an invalid BIP16 transaction in block 170060. However, BIP16 was delayed by one month, so to anyone running something before  or after 0.6.0rc1, the transaction was just a weird but valid spend-to-hash. For users of 0.6.0rc1, it was an invalid spend.

If you had run 0.6.0rc1 for a long time, your database would contain a very long apparently-invalid chain. When upgrading or downgrading, that chain suddenly becomes valid, and a huge reorganization is attempted. However, apparently this is such a massive database operation that many users hit some arbitrary limits in the database library.

[deepceleron]

I fired up 0.6rc1 after a week, and got the same problem, stuck at 170059, also with the "WARNING: Displayed transactions may not be correct!" Reinstalling bitcoin-0.5.2 over it did not fix the problem, so whatever problem it had is left behind in the wallet or blockchain. I'll replace the blockchain with my block 165000 download and see if it gets past, otherwise we've got a wallet problem.

The blockchain replacement and resync with 0.5.2 worked. Maybe restarting worked right after this block, but yes, it looks like 0.5.2 can't deal after hundreds more blocks that were "invalid" are in the blockchain db and do a reorg starting back that far. Looks like we have a bugfix for 0.5.3?

[tsupp4]

I fired up 0.6rc1 after a week, and got the same problem, stuck at 170059, also with the "WARNING: Displayed transactions may not be correct!" Reinstalling bitcoin-0.5.2 over it did not fix the problem, so whatever problem it had is left behind in the wallet or blockchain. I'll replace the blockchain with my block 165000 download and see if it gets past, otherwise we've got a wallet problem.

The blockchain replacement and resync with 0.5.2 worked. Maybe restarting worked right after this block, but yes, it looks like 0.5.2 can't deal after hundreds more blocks that were "invalid" are in the blockchain db and do a reorg starting back that far. Looks like we have a bugfix for 0.5.3?

Thank you for this solution.

[Ferroh]

Sadly I am using rc4 and I am still stuck at 170059.

[Aggro]

We just started testing rc5 and noticed the following:

When you try to import a private key into an encrypted wallet that hasn't been unlocked, you receive the following error:

error: {"code":-4,"message":"Error adding key to wallet"}

I believe that the message that should be returned is that the wallet needs to be unlocked, similarly than when you try to use sendtoaddress without unlocking the wallet. I tried the same private key with the wallet unlocked and the import was successful.

So far everything works great. I am still downloading the blockchain and will report if it gets stuck.

Thanks!
Roberto

[bitcoinsarefun]

is 0.6.0 still on track for release today?

[Diapolo]

is 0.6.0 still on track for release today?

At least there were no new commits merged on github, but that is no definite answer for your question, sorry.

Dia

[Gavin Andresen]

is 0.6.0 still on track for release today?

We might re-spin the release with just updated translations.

There is one serious issue affecting a few people (https://bitcointalk.org/index.php?topic=74447.0) but because it is a one-time problem when you upgrade from an older release and has a pretty simple workaround (remove your addr.dat file and re-run), we may release with it as a Known Issue.

If there are any Berkeley DB database experts reading this we could use your help figuring out what the heck is going on...

[redditorrex]

Hey, I just grabbed the master from https://github.com/bitcoin/bitcoin and just hit this wall. I cant bring any new nodes online, all my trees stop at 170 also.