Topic: Version 0.6 release candidate 1 (Read 13469 times)
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.
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://bitcointalksearch.org/topic/--74447) 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...
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
is 0.6.0 still on track for release today?
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
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
Sadly I am using rc4 and I am still stuck at 170059.
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?
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?
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.
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.
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?:
My debug.log (paste) when errors start in 0.6rc1
Error fun from reverting to 0.5.2
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
Thanks mcorlett I'll give it a try...
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.
v0.6.0rc2 built from master branch still stuck at block 170059 :-( Tried -rescan and -paytoscripthashtime ... any thoughts?
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.
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.
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.
I have implemented a potential fix for this problem, but it is hard to find test cases.
Thank you.
Upgrading to rc2 isn't enough to fix this. Pain. So far running with a new -paytoscripthash time and -rescan didn't fix it either .... seems Bitcoin stashed the fact that the next best block is invalid somewhere and now won't download it again.
Does anyone know what the fix is?
Does anyone know what the fix is?
Can you upload your blkindex.dat and blk0001.dat somewhere? I'd like to see why it's stuck there...
Upgrading to rc2 isn't enough to fix this. Pain. So far running with a new -paytoscripthash time and -rescan didn't fix it either .... seems Bitcoin stashed the fact that the next best block is invalid somewhere and now won't download it again.
Does anyone know what the fix is?
Does anyone know what the fix is?
I upgraded from rc1 to rc2 and bitcoin is still stuck at 170059.
Did you use the windows installer to upgrade to rc2? If so, download the zip file and use that instead. The installer .exe for rc2 is broken.
I upgraded from rc1 to rc2 and bitcoin is still stuck at 170059.
Someone exploited the fact that BIP 16 isn't active to steal 0.004 BTC from someone who tried to use it. rc1 is enforcing BIP 16 unless you use -pushtoscripthashtime (see some other thread for what to set it to). In short, this problem is because 0.6.0rc* includes BIP 16 support before it is accepted by the Bitcoin network (as an attempt to force BIP 16 despite objections).
Disclaimer: BIP 17 would have the same problem if it were included in the client before network acceptance.
Disclaimer: BIP 17 would have the same problem if it were included in the client before network acceptance.
Got it. This thread. It appears to be correct in rc2, but if there is another delay (unlikely), we'll need to adjust again.
Code:
-paytoscripthashtime=1333238400
Jump to: