Bitcoin-Qt / bitcoind version 0.8.0 release candidate 1

[wtfvanity]

This release no longer maintains a full index of historical transaction ids
by default, so looking up an arbitrary transaction using the getrawtransaction
RPC call will not work. If you need that functionality, you must run once
with -txindex=1 -reindex=1 to rebuild block-chain indices (see below for more
details).

Quick question regarding this. Does importprivkey still work? It rescans the block chain to see if it has been used, would this still work with the way it stores the historical transaction ids? Or would I need to use the txindex=1 if I plan on importing keys?


I've tested on a couple of set up of windows:
Windows XP New install, download block chain: Works okay. Much faster than previous versions on downloading.
Windows 7 New install, download block chain: Works okay. Much faster than previous versions on downloading.

Windows XP block chain was at about 190,000 never finished downloading because it took too long for what this used to be used for. Took about an hour minutes to reindex what it had then it downloaded the rest nice and quickly. This was an older P4 machine.

Windows 7, had full block chain. It reindexed fine nice and fast in about an hour. I did notice during the first 3/4 of the block chain it didn't really use extra CPU. It's near the end when it started to crank up the engine. This machine was a more modern machine multiple cores and I set the dbcache to 2000.

[1715675332]

1715675332

[1715675332]

1715675332

[1715675332]

1715675332

[1715675332]

1715675332

[1715675332]

1715675332

[Pieter Wuille]

Quick question regarding this. Does importprivkey still work? It rescans the block chain to see if it has been used, would this still work with the way it stores the historical transaction ids? Or would I need to use the txindex=1 if I plan on importing keys?

No problem - rescan just goes through all old blocks again, one by one. Those are still available in 0.8. The only thing that changes is that no information in the index is kept about spent transactions, so without txindex, it's impossible to find a transaction given just its txid. In practice, really the only thing affected is the getrawtransaction RPC.

[wtfvanity]

Quick question regarding this. Does importprivkey still work? It rescans the block chain to see if it has been used, would this still work with the way it stores the historical transaction ids? Or would I need to use the txindex=1 if I plan on importing keys?

No problem - rescan just goes through all old blocks again, one by one. Those are still available in 0.8. The only thing that changes is that no information in the index is kept about spent transactions, so without txindex, it's impossible to find a transaction given just its txid. In practice, really the only thing affected is the getrawtransaction RPC.

Oh duh, I knew that. I've read what we are doing here and also about light nodes. I mistook the spent tx as creation of a light node. My mistake. I understand now. The bloom feature is groundwork for a light node. I'm going to test on another windows machine and a linux machine later. But so far I love what I see.

This really opens up the, hey, download bitcoin and try it out I'll send you some coins instead of; hey, check out bitcoin, but get an alternate client because of the official one takes too long.

[rini17]

I ran bitcoind 0.8rc provided 64bit linux binary (with -dbcache=1000), it synced in just 1 hour using single connection to locally running bitcoind 0.7, while being responsive to RPC queries all the time. I like it

[Andreas Schildbach]

It works for me, self-compiled bitcoin-qt v0.8.0-rc1 from git on Ubuntu 12.10 64bit.

I tested migration by re-indexing once and also completely downloading the block chain once. Also a couple of payments both directions.

Specifically, tested Bloom Filtering a lot, in combination with Bitcoin Wallet for Android (bloom enabled previews can be downloaded here).

I can say that bitcoin-qt is a lot faster, I'd even say it jumped from unusable to very well usable. Good work everyone!

[LightRider]

Successfully updated on Win7x64. Reindexing took a couple of hours, and the last 5000 blocks or so pegged the cpu. Also brought up testnet from scratch in under 12 minutes. Well done everyone!

[Akka]

Please test!  Even an "it works for me" report is useful (just make sure to include your OS version and other helpful details in your "it works" post...)

In the spirit of this:

Deleted complete blockchain, upgraded: Blockchain downloaded in under 4 Hours

Send / receive works fine.

No Bugs seen so far.

Awesome Work.

OS: Win 7

Edit:

Testers:

Another good, simple test:  leave it running for 24+ hours, especially on Windows.

This helps verify longer term stability, and verifies that it keeps up with the network.

There had been some crash reports early in development, on Windows.  Pretty sure those are solved, but extra testing through normal use cannot hurt.

My PC runs 24/7. I will post if I have any crashes. (None so far)

[hazek]

Successfully updated on Win7x64. Reindexing took a 7 hours or so, did it with -dbcache=2000, after it was finished I closed it without a problem and I have since ran it again without that command and it works. I haven't tried sending or receiving anything.


I'd still like to get an answer when, if at all, will there be an option to enter a username and password for a proxy server?

[jgarzik]

Testers:

Another good, simple test:  leave it running for 24+ hours, especially on Windows.

This helps verify longer term stability, and verifies that it keeps up with the network.

There had been some crash reports early in development, on Windows.  Pretty sure those are solved, but extra testing through normal use cannot hurt.

[Technomage]

My PC: Windows 7 with an old Intel Quad-Core. 4 GB memory. 7200 RPM regular hard drive. Decent computer.

First impressions: the reindexing is fairly fast. I've now been at it for a little more than 1,5 hours and there are only 2800 blocks left. However, at around the 5000 blocks left mark, my PC started lagging big time. I checked that CPU usage (with a quad-core OC'd to 3 ghz) was pretty much 100% and there was 0 memory free. Low usability of the computer, barely usable.

That's it for now, I will keep it running for a good while to see how it works.

Edit: The last few thousand blocks went fairly quickly as well. Total reindex took 2hrs approx. Now I'll just keep it running.

[jonathan]

bitcoind 0.8.0rc1 64bit on debian squeeze. Started a fresh download of the blockchain, came back five hours later, it was downloaded up to the present block. No hitches to report. Sweet!

[Raoul Duke]

The *nix x64 binary works wonderfully on Ubuntu 12.04 64bits.
It even solved the status bar icon/menus not showing problem.

Downloaded and verified the complete blockchain in less than 5 hours on a 2.2GHz Pentium dual-core laptop with 4GB RAM.

[wtfvanity]

All four of the first machines are running just fine.

I did another test on a more recent CPU plenty of ram running Windows 7. I let it run overnight and download the whole blockchain. This morning I ran windows updates that were pending and prepared for a reboot. The block chain had not finished downloading all of the way yet (I used add IP from a local node for all these, probably why my results were faster than most others posted here)

I did a file exit on Bitcoin-qt and got this exception:

Code:

A fatal error occurred. Bitcoin can no longer continue safely and will quit.

Exception: St9pad_alloc
std:bad_alloc
C:\Program Files\Bitcoin\bitcoin-qt.exe in Runaway exception

These are the last entries in the debug log

Code:

SetBestChain: new best=000000000000018829028b3af6d47eac9dab3f4b233c77aff1ee2262fcd0faaa  height=214069  work=687730958631335352866  tx=10451422  date=2012-12-28 19:24:59
SetBestChain: new best=000000000000002aeab1c5b9fc27e14f759ab16a3e4cde600d98718b93e50416  height=214070  work=687743756268435510981  tx=10451918  date=2012-12-28 19:35:21
SetBestChain: new best=000000000000057d76f8d7a62f3de9a874055874614c6423fce82f60b0177d9a  height=214071  work=687756553905535669096  tx=10452418  date=2012-12-28 19:40:47

I opened Bitcoin back up and it pegged all cores of the CPU for a while. I had some stuff minimizing and maximizing so I'm not sure what the splash screen said that it was doing. This was much longer by a significant amount vs. the other machines when I close Bitcoin and open them back up. In fact, it is still not open now after about 10 minutes and after it opens I'll post more details. But for now, there is a crash on RC1 with Windows 7. It did not crash until I asked it to shut down. I checked the resource usage, Bitcoin-qt was using about a gig of ram, machine has 8 GB and wasn't even at 50% utilization for ram.

[hxtop]

nice work

[kalleguld]

Running great here.
Linux nas1 2.6.33-rc6-00219-gf5c72e7-svn #8 PREEMPT Tue Feb 9 16:38:20 CET 2010 armv5tel GNU/Linux

Wanted to setup an electrum server, did not notice that I downloaded the 0.8.0 source until I recognized the dbcache parameter in this topic.

tl;dr bitcoind with electrum-patch runs fine on armv5 and old kernel

[mmortal03]

Am testing it now, completely fresh install on a netbook, Windows 8 64-bit, AMD E-350, 6 GB of RAM, 5400 rpm hard drive, using -dbcache=2000.

Will report back once it's done.

[wtfvanity]

All four of the first machines are running just fine.

I did another test on a more recent CPU plenty of ram running Windows 7. I let it run overnight and download the whole blockchain. This morning I ran windows updates that were pending and prepared for a reboot. The block chain had not finished downloading all of the way yet (I used add IP from a local node for all these, probably why my results were faster than most others posted here)

I did a file exit on Bitcoin-qt and got this exception:

Code:

A fatal error occurred. Bitcoin can no longer continue safely and will quit.

Exception: St9pad_alloc
std:bad_alloc
C:\Program Files\Bitcoin\bitcoin-qt.exe in Runaway exception

These are the last entries in the debug log

Code:

SetBestChain: new best=000000000000018829028b3af6d47eac9dab3f4b233c77aff1ee2262fcd0faaa  height=214069  work=687730958631335352866  tx=10451422  date=2012-12-28 19:24:59
SetBestChain: new best=000000000000002aeab1c5b9fc27e14f759ab16a3e4cde600d98718b93e50416  height=214070  work=687743756268435510981  tx=10451918  date=2012-12-28 19:35:21
SetBestChain: new best=000000000000057d76f8d7a62f3de9a874055874614c6423fce82f60b0177d9a  height=214071  work=687756553905535669096  tx=10452418  date=2012-12-28 19:40:47

I opened Bitcoin back up and it pegged all cores of the CPU for a while. I had some stuff minimizing and maximizing so I'm not sure what the splash screen said that it was doing. This was much longer by a significant amount vs. the other machines when I close Bitcoin and open them back up. In fact, it is still not open now after about 10 minutes and after it opens I'll post more details. But for now, there is a crash on RC1 with Windows 7. It did not crash until I asked it to shut down. I checked the resource usage, Bitcoin-qt was using about a gig of ram, machine has 8 GB and wasn't even at 50% utilization for ram.

45 minutes later it starts up and finishes the block chain very quickly. I closed it down and opened it back up just fine nice and fast. Not sure what other information I can provide about this but it seems that everything is okay now.

[jl2012]

Does it work with Armory?

[Gavin Andresen]

The crash-on-exit bug could be this issue:  https://github.com/bitcoin/bitcoin/issues/2204

We may have to live with it for the 0.8 release, and fix it in the next release, because there is a high risk that fixing it will cause more problems than it solves.

[xxjs]

Ubuntu 12.04 64bit I7 12GB
Empty wallet behind Armory 0.87-beta

Works great. CPU load while reindexing blocks is 600%, around 10 MB/s disk io. Fans revv up. Nice to put all the horses before the cart.