|
Title: Version 0.6 release candidate 1 Post by: Gavin Andresen on February 09, 2012, 01:35:41 AM Re-posted from the bitcoin-development mailing list:
I'd like version 0.6 to get lots of review, "soak time" and testing, so please download and run release candidate 1 from: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/ You can review the code changes using github's compare feature: https://github.com/bitcoin/bitcoin/compare/v0.5.2...v0.6.0rc1 Please report bugs using the github issue tracker. Release notes: NEW FEATURES SINCE BITCOIN VERSION 0.5 -------------------------------------- Bitcoin-Qt can display and save QR codes for sending and receiving addresses. New context menu on addresses to copy/edit/delete them. New Sign Message dialog that allows you to prove that you own a bitcoin address by creating a digital signature. Wallets created with this version of bitcoin will use 33-byte 'compressed' public keys instead of 65-byte public keys, resulting in smaller transactions and less traffic on the bitcoin network. The shorter keys are completely compatible with older versions. New command-line argument -blocknotify=<command> that will spawn a shell process to run <command> when a new block is accepted. validateaddress JSON-RPC api command output includes two new fields for addresses in the wallet: pubkey : hexadecimal public key iscompressed : true if pubkey is a short 33-byte key New JSON-RPC api commands for dumping/importing private keys from the wallet (dumprivkey, importprivkey). New JSON-RPC api command for getting information about blocks (getblock, getblockhash). New JSON-RPC api command for getting extra information related to mining (getmininginfo). NOTABLE CHANGES --------------- The -nolisten, -noupnp and -nodnsseed command-line options were renamed to -listen, -upnp and -dnsseed, with a default value of 1. The old names are still supported for compatibility (so specifying -nolisten is automatically interpreted as -listen=0; every boolean argument can now be specified as either -foo or -nofoo). The -noirc command-line options was renamed to -irc, with a default value of 0. Run -irc=1 to get the old behavior. PRELIMINARY SUPPORT FOR MULTISIGNATURE TRANSACTIONS --------------------------------------------------- This release has preliminary support for multisignature transactions-- transactions that require authorization from more than one person or device before they will be accepted by the bitcoin network. Prior to this release, multisignature transactions were considered 'non-standard' and were ignored; with this release multisignature transactions are considered standard and will start to be relayed and accepted into blocks. It is expected that future releases of Bitcoin-Qt will support the creation of multisignature transactions, once enough of the network has upgraded so relaying and validating them is robust. For this release, creation and testing of multisignature transactions is limited to the bitcoin test network using the "addmultisigaddress" JSON-RPC api call. Short multisignature address support is included in this release, as specified in BIP 16. Run with -bip16=0 to turn off support for BIP 16. Title: Re: Version 0.6 release candidate 1 Post by: finway on February 09, 2012, 01:56:11 AM Looking good. Finalized Chinese Translation (Simplified)， hope get in rc2. :)
Title: Re: Version 0.6 release candidate 1 Post by: fornit on February 09, 2012, 03:59:02 AM I'd like version 0.6 to get lots of review, "soak time" and testing, so please download and run release candidate 1 from: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/ testing started :) Quote NEW FEATURES SINCE BITCOIN VERSION 0.5 -------------------------------------- Bitcoin-Qt can display and save QR codes for sending and receiving addresses. New context menu on addresses to copy/edit/delete them. New Sign Message dialog that allows you to prove that you own a bitcoin address by creating a digital signature. Wallets created with this version of bitcoin will use 33-byte 'compressed' public keys instead of 65-byte public keys, resulting in smaller transactions and less traffic on the bitcoin network. The shorter keys are completely compatible with older versions. sounds good! Title: Re: Version 0.6 release candidate 1 Post by: slothbag on February 09, 2012, 09:48:31 AM I'm not using the proxy option, but the new GUI is showing some strange IPv6 looking address in the proxy field.
e.g. a9b1:0:f2:v532:200:0:0:0 Once I change it, its all good. Unchecking UPnP ports doesnt seem to save me selection. Great job on all the new features! Title: Re: Version 0.6 release candidate 1 Post by: mcorlett on February 09, 2012, 10:32:07 AM Do these builds use a gitian-like build process?
Title: Re: Version 0.6 release candidate 1 Post by: Gavin Andresen on February 09, 2012, 02:46:10 PM Do these builds use a gitian-like build process? Yes, thanks for reminding me: I just uploaded gitian signatures for the win32 and linux 0.6rc1 builds to:https://github.com/bitcoin/gitian.sigs The win32 build was not deterministic, though. There's a pull request to fix that. The OSX binary is not gitian-built. Title: Re: Version 0.6 release candidate 1 Post by: pc on February 09, 2012, 04:19:56 PM While I have only the vaguest of understanding of EC cryptography, the "compressed public keys" bullet point there looks… interesting. I tried searching the boards and didn't see anything other than this post, so I guess I'm asking here:
• Is there discussion of this elsewhere that you could point me to? • Does this form a new type of address/public/private-key pairing in the wallet.dat? • How far is this "complete compatibility" with older versions? Can I move a wallet.dat from this new release that's created these new keys to an older release and have it still work? • Has testing so far included sending transactions between old and new versions, and between old wallets that have been upgraded to the new version, and probably more permutations on things like that? Or are these the kinds of things that are being asked to test thoroughly? Is there a test plan of some sort, or should we just be doing whatever we can think of on testnet to see what happens? Title: Re: Version 0.6 release candidate 1 Post by: mcorlett on February 09, 2012, 04:24:24 PM • Is there discussion of this elsewhere that you could point me to? https://github.com/bitcoin/bitcoin/pull/649https://github.com/sipa/bitcoin/commit/11529c6e4f7288d8a64c488a726ee3821c7adefe (no discussion) Title: Re: Version 0.6 release candidate 1 Post by: piuk on February 09, 2012, 05:31:59 PM It is expected that future releases of Bitcoin-Qt will support the creation of multi signature transactions. Gavin, will Btcoin-QT support plain M-Of-N transactions and P2SH transactions or will it be etiher-or? Title: Re: Version 0.6 release candidate 1 Post by: btc_artist on February 09, 2012, 05:44:15 PM Nice list of improvements
Title: Re: Version 0.6 release candidate 1 Post by: kwukduck on February 09, 2012, 06:51:36 PM so far all seems good.
signing a message with a key is nice, now we need an easy way to verify a message with an address aswell... signing only works if the signature can be interpreted by somebody i think Title: Re: Version 0.6 release candidate 1 Post by: Gavin Andresen on February 09, 2012, 07:04:43 PM Or are these the kinds of things that are being asked to test thoroughly? Is there a test plan of some sort, or should we just be doing whatever we can think of on testnet to see what happens? You are the Quality Assurance department. A test plan is an excellent idea, could you write one up and post it on the wiki and ask for volunteers to help test? Gavin, will Btcoin-QT support plain M-Of-N transactions and P2SH transactions or will it be etiher-or? I don't know, the GUI for multisignature transactions hasn't been designed yet. But I imagine it will be simpler to always produce P2SH transactions, just as the client always produces OP_HASH160 transactions and has no option to produce plain OP_CHECKSIG transactions. I assume that both forms will be supported for multisig payments into your wallet (but detailed discussion on how to support multisig in the GUI should happen somewhere other than this thread). Title: Re: Version 0.6 release candidate 1 Post by: dvide on February 09, 2012, 09:35:44 PM New Sign Message dialog that allows you to prove that you Oh that's nice :)own a bitcoin address by creating a digital signature. Title: Re: Version 0.6 release candidate 1 Post by: Pieter Wuille on February 10, 2012, 12:10:27 AM While I have only the vaguest of understanding of EC cryptography, the "compressed public keys" bullet point there looks… interesting. I tried searching the boards and didn't see anything other than this post, so I guess I'm asking here: • Is there discussion of this elsewhere that you could point me to? I mailed about it to the -dev mailing list (http://sourceforge.net/mailarchive/forum.php?thread_name=20111121114819.GB7261%40ulyssis.org&forum_name=bitcoin-development), without much response though. Quote • Does this form a new type of address/public/private-key pairing in the wallet.dat? Yes and no. The same private key now corresponds to two different pubkey/address pairs. Which one is used is determined at generation time. Since the wallet stores both pubkey and private key, the length of the pubkey is used to determined which pair is intended. Quote • How far is this "complete compatibility" with older versions? Can I move a wallet.dat from this new release that's created these new keys to an older release and have it still work? Good point. It will probably work, but the compressed pubkeys will be considered non-compressed ones by older versions, so they will probably miss transactions. Over time, the ledger seen by older clients and newer clients may diverge. I'll try to fix this before 0.6.0 final is released. Quote • Has testing so far included sending transactions between old and new versions, and between old wallets that have been upgraded to the new version, and probably more permutations on things like that? Sending from and to old and new addresses has been tested, and between old and new clients. As mentioned, I didn't test downgrading. Quote Or are these the kinds of things that are being asked to test thoroughly? Is there a test plan of some sort, or should we just be doing whatever we can think of on testnet to see what happens? All testing is welcome, of course... Title: Re: Version 0.6 release candidate 1 Post by: ripper234 on February 10, 2012, 12:54:12 AM Quote Thanks to Bitclockers, Bitlc.net, Bitcoin.cz, BitMinter, pool.itzod.ru, BTC Guild and ozco.in for supporting BIP 16 What about slush? Title: Re: Version 0.6 release candidate 1 Post by: dree12 on February 10, 2012, 01:03:48 AM Quote Thanks to Bitclockers, Bitlc.net, Bitcoin.cz, BitMinter, pool.itzod.ru, BTC Guild and ozco.in for supporting BIP 16 What about slush? Title: Re: Version 0.6 release candidate 1 Post by: ripper234 on February 10, 2012, 07:16:17 AM Quote Thanks to Bitclockers, Bitlc.net, Bitcoin.cz, BitMinter, pool.itzod.ru, BTC Guild and ozco.in for supporting BIP 16 What about slush? Ah, I didn't know Bitcoin.cz = slush. Tnx. Title: Re: Version 0.6 release candidate 1 Post by: splatster on February 11, 2012, 04:38:22 AM I tried out Bitcoin-QT 0.6 RC1 but had to go back to 0.5.2 after Bitcoin-QT was using 98% CPU.
It wasn't doing anything, not downloading a block, not sending a TX. After switching back to 0.5.2, CPU usage is back to normal. Title: Re: Version 0.6 release candidate 1 Post by: cnbtcnews on February 11, 2012, 02:48:05 PM Looking good. Finalized Chinese Translation (Simplified)， hope get in rc2. :) good work!Title: Re: Version 0.6 release candidate 1 Post by: ThiagoCMC on February 12, 2012, 02:24:02 AM Looking good. Finalized Chinese Translation (Simplified)， hope get in rc2. :) good work!I can't wait to buy stuffs from China using Bitcoins!! When only 1 China store accepts Bitcoins, it is over for fiat! ^^ Title: Re: Version 0.6 release candidate 1 Post by: dunand on February 12, 2012, 05:49:15 AM On ubuntu 11.10 x64 I have this error when trying to run ./bitcoind -daemon
I was on 0.5.2 before. EXCEPTION: 22DbRunRecoveryException DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery bitcoin in AppInit() terminate called after throwing an instance of 'DbRunRecoveryException' what(): DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery Title: Re: Version 0.6 release candidate 1 Post by: slothbag on February 12, 2012, 10:56:44 AM I have a wallet.dat file I have been using since v0.3.2, after trying v0.6rc1 using the same wallet.dat file I can no longer run v0.5.2, it crashes on startup. The new version must have made some changes to the wallet.dat that previous versions are not handling.
Not a big issue cause I have backups, but thought it might be worth mentioning. Title: Re: Version 0.6 release candidate 1 Post by: 1Pakis on February 12, 2012, 03:56:45 PM On ubuntu 11.10 x64 I have this error when trying to run ./bitcoind -daemon I get this error too on xubuntu 11.04I was on 0.5.2 before. EXCEPTION: 22DbRunRecoveryException DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery bitcoin in AppInit() terminate called after throwing an instance of 'DbRunRecoveryException' what(): DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery Title: Re: Version 0.6 release candidate 1 Post by: kjj on February 13, 2012, 06:35:16 PM I just used importprivkey to import a key, and the whole thing hung up for several minutes. Is that normal?
The import appears to have been successful though. Title: Re: Version 0.6 release candidate 1 Post by: kwukduck on February 16, 2012, 08:23:41 AM Yesterday my pc crashed for no aparent reason (just went like what seemed to be standby, then after 10 seconds rebooted). When i started bitcoin client it took about 2-3 minutes to load before the gui popped up.
After the gui shows it just freezes, can't click anything, task manager claims it's not responding, also RPC doesnt reply to commands. I did a chkdsk but all seems fine there... Also, all seems good when reverting back to 0.5.2. Can't really explain it or reproduce the crash exactly, all i know is that 0.6rc1 now freezes whenever i start it. Used to work just fine before. Title: Re: Version 0.6 release candidate 1 Post by: blueadept on February 16, 2012, 02:27:21 PM I just used importprivkey to import a key, and the whole thing hung up for several minutes. Is that normal? The import appears to have been successful though. Yes, the entire blockchain is rescanned for transactions to the key you imported. Title: Re: Version 0.6 release candidate 1 Post by: viper1092 on February 18, 2012, 10:19:15 PM *Drool* :o
Some nice looking features here in oh6RC1. Soon as I'm back to my MBP I'm gonna test. Title: Re: Version 0.6 release candidate 1 Post by: Pieter Wuille on February 20, 2012, 03:33:35 PM Quote • How far is this "complete compatibility" with older versions? Can I move a wallet.dat from this new release that's created these new keys to an older release and have it still work? Good point. It will probably work, but the compressed pubkeys will be considered non-compressed ones by older versions, so they will probably miss transactions. Over time, the ledger seen by older clients and newer clients may diverge. I'll try to fix this before 0.6.0 final is released. This was fixed in commit 38067c1 (https://github.com/bitcoin/bitcoin/commit/38067c18f8b54c7121643fa3291ffe81b6eefef1). Title: Re: Version 0.6 release candidate 1 Post by: Wordlet on February 20, 2012, 05:18:29 PM I just used importprivkey to import a key, and the whole thing hung up for several minutes. Is that normal? The import appears to have been successful though. Yes, the entire blockchain is rescanned for transactions to the key you imported. Does it make the UI unresponsive with no indication as to what is happening? Sounds like a bug to me. Title: Re: Version 0.6 release candidate 1 Post by: Diapolo on February 25, 2012, 06:09:01 PM I had one strange observation with this RC1 on Windows, which I can't reproduce but perhaps the info is important.
My system has Win7 x64 uses CGMINER for mining and runs the Bitcoin client while I mine. Yesterday I had a bluescreen ... rebooted and tried to start the BC client. I saw the loading screen and thought everything was good, but the GUI simple froze and did not recover from that state. I had the impression the database was corrupt, so I restored a wallet.dat backup and tried to restart the client another time. And again it froze after the loading screen ... interesting fact, I saw via ProcessExplorer, that there were threads working and my data directory grew, so it was in fact re-downloading the block-chain. But no chance, the GUI keept freezing. So I reverted back to the latest stable release 0.5.2 and now everything is fine again. A further important info I have to give is, I use Microsoft EMET 2.1, which implements some security concepts for applications, which don't support them out of the box via a kind of additional layer, alternatively minimizes attack vectors, so that let's say a buffer-overflow is harder to use for an attack on the application or the host system. I disabled EMET for the BC client the same time I switched back to 0.5.2, so I can't really say if it was a bug with 0.6 or a problem with the bluescreen crash + EMET usage and a database problem. After the re-download of the blockchain I re-activated EMET, so that it's now again active and works without any problems (and it did that for 0.6 before that bluescreen, too ...). Dia Title: Re: Version 0.6 release candidate 1 Post by: Diapolo on February 25, 2012, 06:17:38 PM Wallets created with this version of bitcoin will use 33-byte 'compressed' public keys instead of 65-byte public keys, resulting in smaller transactions and less traffic on the bitcoin network. The shorter keys are completely compatible with older versions. Will older wallets (the wallet.dat?) get converted to the new format or can this be done somehow without a data-loss? Dia Title: Re: Version 0.6 release candidate 1 Post by: Pieter Wuille on February 25, 2012, 06:25:06 PM Will older wallets (the wallet.dat?) get converted to the new format or can this be done somehow without a data-loss? Dia Yes; in fact, the wallet format remains compatible as long as no new-style keys are generated. As soon as a new key in generated in 0.6.0 onwards, the wallet will not be compatible anymore with pre-0.6.0 clients. Note that 0.6.0rc1 does not yet prevent old clients from opening such a new wallet, potentially corrupting the wallet. The next release candidates will do so. Title: Re: Version 0.6 release candidate 1 Post by: Diapolo on February 28, 2012, 05:16:46 PM I again tried to switch to 0.6 RC1 and GUI still freezes, even with EMET disabled for the BC client :-/.
Reverting to 0.5.2 instantly restores usability ... any ideas, how I can help to debug this? Or when will RC2 be release, so I can see if that one got fixed? Dia Title: Re: Version 0.6 release candidate 1 Post by: Prayer on February 29, 2012, 02:53:06 PM Working on setting up a new home server on Ubuntu 11.10, and wanted to build bitcoind from source. Ended up with the 0.6 code (didn't realize this until later). Anyways, had fun playing with the import feature (I was banging my head about how to do this in 0.5.2).
As mentioned by another user, the import took a while. Would it be worth considering threading this off in order to make the user experience a little nicer? There seems to be something crossed in the getaccountaddress and getnewaddress RPC calls. I generated a throwaway address at bitcionaddress.com for this demonstration (and masked it to keep anyone from accidentally using it): Code: Bitcoin Address: 1XXXXX7zMGHrs7oc1hCSwkNCmmfT8m2mSQ Then, I imported it, then got the list of accounts. It's there! Code: me@chewy:~$ bitcoind importprivkey 5JMn6mZwW69NXXXXXXXXXXXXXXXXEgzyjD9NvywV3CzuVUT18wq Garbage However, when I tried to verify the address on the imported key, it seems to have generated a new key/address pair: Code: me@chewy:~$ bitcoind getaccountaddress Garbage Subsequent calls to getaccountaddress return the same address (no new addresses are generated). However, you can verify that the 'account' now has two addresses associated with it: Code: me@chewy:~$ bitcoind getaddressesbyaccount Garbage Having an extra address generated isn't a big deal, but I never asked for a new address to be generated. I started looking into the code, but I'm not familiar enough yet to figure out what's going on. I may play around with it tonight and see if I can figure out a fix, but it's been years since I've even looked at c++ and even then it wasn't much. Also, if I may... shouldn't the client be able to refresh the wallet when a key has been imported? It's rather annoying to have to stop/restart when importing a key before it shows up in the GUI. Maybe this would be an argument for splitting server & client functionality, and use the GUI only to make RPC calls against the server. Now, if my observations are worth anything, the address in my sig is valid. I only have like .14 BTC now and want a bit more to play with =D. Title: Re: Version 0.6 release candidate 1 Post by: Pieter Wuille on February 29, 2012, 02:58:49 PM However, when I tried to verify the address on the imported key, it seems to have generated a new key/address pair: Code: me@chewy:~$ bitcoind getaccountaddress Garbage Good point, I don't recall updating the account info when importing. I'll try to do that still before 0.6.0's release. Quote Also, if I may... shouldn't the client be able to refresh the wallet when a key has been imported? It's rather annoying to have to stop/restart when importing a key before it shows up in the GUI. Maybe this would be an argument for splitting server & client functionality, and use the GUI only to make RPC calls against the server. Yes, that's a known issue, see the issue page (https://github.com/bitcoin/bitcoin/issues/835). I'm not familiar with the GUI code, however. Title: Re: Version 0.6 release candidate 1 Post by: Diapolo on February 29, 2012, 03:29:08 PM Yesterday my pc crashed for no aparent reason (just went like what seemed to be standby, then after 10 seconds rebooted). When i started bitcoin client it took about 2-3 minutes to load before the gui popped up. After the gui shows it just freezes, can't click anything, task manager claims it's not responding, also RPC doesnt reply to commands. I did a chkdsk but all seems fine there... Also, all seems good when reverting back to 0.5.2. Can't really explain it or reproduce the crash exactly, all i know is that 0.6rc1 now freezes whenever i start it. Used to work just fine before. I should have read this thread from the beginning, as this is the behaviour I observed, too! Any info on this? Dia Title: Re: Version 0.6 release candidate 1 Post by: D.H. on February 29, 2012, 04:29:05 PM It would be great if someone could create a windows installer for release candidates, like Luke-Jr did with the next-test branch here (https://bitcointalk.org/index.php?topic=66556.0). Would bring in a lot more testers I'm sure.
Title: Re: Version 0.6 release candidate 1 Post by: mcorlett on February 29, 2012, 04:39:14 PM It would be great if someone could create a windows installer for release candidates, like Luke-Jr did with the next-test branch here (https://bitcointalk.org/index.php?topic=66556.0). Would bring in a lot more testers I'm sure. Is this not satisfactory?http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/ Title: Re: Version 0.6 release candidate 1 Post by: Pieter Wuille on February 29, 2012, 04:49:36 PM I should have read this thread from the beginning, as this is the behaviour I observed, too! Any info on this? Unfortunately, no. There have been a rather large number of bugfixes since 0.6.0rc1 however, and 0.6.0rc2 will be created very soon. I hope this problem is fixed by now. Title: Re: Version 0.6 release candidate 1 Post by: D.H. on February 29, 2012, 04:52:05 PM It would be great if someone could create a windows installer for release candidates, like Luke-Jr did with the next-test branch here (https://bitcointalk.org/index.php?topic=66556.0). Would bring in a lot more testers I'm sure. Is this not satisfactory?http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/ Oops, sorry about that. I read through the first post a bit too quickly. Title: Re: Version 0.6 release candidate 1 Post by: Diapolo on February 29, 2012, 05:47:19 PM I should have read this thread from the beginning, as this is the behaviour I observed, too! Any info on this? Unfortunately, no. There have been a rather large number of bugfixes since 0.6.0rc1 however, and 0.6.0rc2 will be created very soon. I hope this problem is fixed by now. If not I will help debugging it for sure! Dia Title: Re: Version 0.6 release candidate 1 Post by: Diapolo on March 02, 2012, 09:20:25 AM Possible fix for GUI freezing on Windows after a crash:
I started an in depth investigation and used Sysinternals Procmon.exe for this. I wanted to know which files or registry keys the client processes and one folder came to my attention. C:\ProgramData\boost_interprocess\Select LastBootUpTime from Win32_OperatingSystem This one contained 2 files, 1 which consisted of 32 "random" characters and looks like a hash and a BitcoinURL file of size 0. The files were still there after "killing" the client! I'm working in IT, so call it luck or experience ... I deleted the whole C:\ProgramData\boost_interprocess folder, restarted the client, removed the database logs from the datadir and now everything works again :)! After I shutdown 0.6 RC2 these files disappear, so perhaps the former bluescreen with 0.6 RC1 made these files persistent, which freezes GUI after a Client re-start, because these 2 files can not be written to. I'm not sure, if 0.5.2 had this files, too ... so perhaps that's why 0.5.2 always worked! Perhaps others should try this and perhaps this one is solved. But can any developer shed some light in here, what these folder or files have to do with the BC client? Dia Title: Re: Version 0.6 release candidate 1 Post by: viboracecata on March 02, 2012, 09:23:39 AM thanks for your great job.
Title: Re: Version 0.6 release candidate 1 Post by: Diapolo on March 02, 2012, 09:26:11 AM thanks for your great job. If it works I'm happy that I invested some hours into it :). Dia Title: Re: Version 0.6 release candidate 1 Post by: Diapolo on March 02, 2012, 10:45:37 AM By the way, is the IRC method for finding peers "deprecated" and should not be used anymore or what were the reasons to default that switch to 0.
Dia Title: Re: Version 0.6 release candidate 1 Post by: Gavin Andresen on March 02, 2012, 06:30:01 PM Possible fix for GUI freezing on Windows after a crash: Nice! Thank you very much for looking deeply into this; it looks like the inter-process-communication doo-hickey bitcoin uses to handle bitcoin: URLs was left behind when you blue-screened, and that's making startup fail the next time around.I started an in depth investigation and used Sysinternals Procmon.exe for this. I wanted to know which files or registry keys the client processes and one folder came to my attention. Title: Re: Version 0.6 release candidate 1 Post by: kjj on March 07, 2012, 06:54:25 PM So, every single one of my rc1 nodes is stuck on block 170,059 and refuse to move forward. While I'm compiling rc2, does anyone know if this is a known problem?
Title: Re: Version 0.6 release candidate 1 Post by: P_Shep on March 07, 2012, 07:09:26 PM So, every single one of my rc1 nodes is stuck on block 170,059 and refuse to move forward. While I'm compiling rc2, does anyone know if this is a known problem? Ditto. Just shut it down, and restarting it. Title: Re: Version 0.6 release candidate 1 Post by: P_Shep on March 07, 2012, 07:11:53 PM Restarted bitcoin-qt 0.6.0-rc1, still stuck on 170059.
Gonna re-install 0.5.2. Title: Re: Version 0.6 release candidate 1 Post by: zvs on March 07, 2012, 07:21:56 PM Can't get past 170059.
Title: Re: Version 0.6 release candidate 1 Post by: mcorlett on March 07, 2012, 07:24:56 PM Also stuck on 170059.
Title: Re: Version 0.6 release candidate 1 Post by: P_Shep on March 07, 2012, 07:26:28 PM 0.5.2 works fine.
Title: Re: Version 0.6 release candidate 1 Post by: mcorlett on March 07, 2012, 07:37:29 PM Code: received block 000000000000047e131d Title: Re: Version 0.6 release candidate 1 Post by: kjj on March 07, 2012, 07:39:07 PM rc2 works so far.
Title: Re: Version 0.6 release candidate 1 Post by: Luke-Jr on March 07, 2012, 07:44:52 PM 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. Edit: To clarify, the person who lost 0.004 BTC in this exploit must have intentionally modified his client to allow him to create such an insecure transaction. Title: Re: Version 0.6 release candidate 1 Post by: kjj on March 07, 2012, 08:41:08 PM 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. Got it. This thread (https://bitcointalk.org/index.php?topic=66514.0). It appears to be correct in rc2, but if there is another delay (unlikely), we'll need to adjust again. Code: -paytoscripthashtime=1333238400 Title: Re: Version 0.6 release candidate 1 Post by: broken on March 08, 2012, 11:16:25 AM I upgraded from rc1 to rc2 and bitcoin is still stuck at 170059.
Title: Re: Version 0.6 release candidate 1 Post by: stevegee58 on March 08, 2012, 11:27:58 AM 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. Title: Re: Version 0.6 release candidate 1 Post by: Mike Hearn on March 10, 2012, 02:21:31 PM 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? Title: Re: Version 0.6 release candidate 1 Post by: Pieter Wuille on March 10, 2012, 03:22:20 PM 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? Can you upload your blkindex.dat and blk0001.dat somewhere? I'd like to see why it's stuck there... Title: Re: Version 0.6 release candidate 1 Post by: Pieter Wuille on March 10, 2012, 10:20:36 PM 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. Title: Re: Version 0.6 release candidate 1 Post by: Pieter Wuille on March 11, 2012, 02:11:27 AM 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. Title: Re: Version 0.6 release candidate 1 Post by: br00t on March 11, 2012, 08:17:31 PM v0.6.0rc2 built from master branch still stuck at block 170059 :-( Tried -rescan and -paytoscripthashtime ... any thoughts?
Title: Re: Version 0.6 release candidate 1 Post by: mcorlett on March 11, 2012, 08:21:51 PM 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 (https://github.com/sipa/bitcoin/tree/minireorg) branch, and it seems to be working. I assume it's this commit (https://github.com/sipa/bitcoin/commit/15dc624936f3921d93b79a79fb5200350ea903bb).It has also been made into a pull request for the mainline client: https://github.com/bitcoin/bitcoin/pull/930. Title: Re: Version 0.6 release candidate 1 Post by: br00t on March 11, 2012, 08:29:55 PM Thanks mcorlett I'll give it a try...
Title: Re: Version 0.6 release candidate 1 Post by: deepceleron on March 12, 2012, 02:28:17 AM 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 (https://bitcointalk.org/index.php?topic=51456) 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) (http://jine.be/512958) when errors start in 0.6rc1 received block 000000000000047e131d Error fun from reverting to 0.5.2 askfor tx acb6e1fa6b8e3d0ab5d7 0 Title: Re: Version 0.6 release candidate 1 Post by: Pieter Wuille on March 12, 2012, 04:42:55 AM 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. Title: Re: Version 0.6 release candidate 1 Post by: deepceleron on March 12, 2012, 11:09:53 AM 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 (https://bitcointalk.org/index.php?topic=51456) 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?Title: Re: Version 0.6 release candidate 1 Post by: tsupp4 on March 12, 2012, 07:38:06 PM 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 (https://bitcointalk.org/index.php?topic=51456) 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?Title: Re: Version 0.6 release candidate 1 Post by: Ferroh on March 21, 2012, 04:45:49 AM Sadly I am using rc4 and I am still stuck at 170059.
Title: Re: Version 0.6 release candidate 1 Post by: Aggro on March 27, 2012, 05:25:09 PM 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 Title: Re: Version 0.6 release candidate 1 Post by: bitcoinsarefun on March 28, 2012, 01:19:25 PM is 0.6.0 still on track for release today?
Title: Re: Version 0.6 release candidate 1 Post by: Diapolo on March 28, 2012, 01:24:57 PM 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 Title: Re: Version 0.6 release candidate 1 Post by: Gavin Andresen on March 28, 2012, 04:55:52 PM 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... Title: Re: Version 0.6 release candidate 1 Post by: redditorrex on April 28, 2012, 07:18:05 PM 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.
|